Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (686)
Games in Android Showcase (198)
games submitted by our members
Games in WIP (758)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: 1 ... 6 7 [8] 9 10
 on: 2016-08-25 16:20:02 
Started by philjord - Last post by Ecumene
philjord's stuff is impressive  Grin

It's so weird to never hear about these huge projects, then they pop up and roll out all this ridiculous tech...
It'll probably be picked up by some journal and blow up soon!

 on: 2016-08-25 16:04:51 
Started by Ecumene - Last post by Ecumene
Final Voting Round!!

The jam begins tomorrow, good luck to everyone!

 on: 2016-08-25 16:00:03 
Started by TumultuousSys - Last post by TumultuousSys
Thank you for your compliments.

Current way to see what they are good for is to watch which resource text (the number you have of it when you're in a planet) is colored green.

In the next updates, I will try to make the tutorial shows the icons corresponding to the tutorial text by enlightening or another way. Also I'll try to make the game easier to understand.

 on: 2016-08-25 14:58:23 
Started by TumultuousSys - Last post by Gjallar
Thank you. And wow there's a lot of stuff in there, I'm impressed!

It's great that you made a tutorial because I would have been completely lost without it, but the problem is I was still kinda lost. It's a great start but I think you have to go a bit more into detail with your explanations. For example you wrote something like "Don't forget to select a model for you building before you can place it" without actually explaining how to do that. Took me a while to figure out that I had to click on the little rectangle in the bottom right of the building selection.

Also what confused me a lot is that i have no idea what the buildings I'm placing actually do. Clicking on them doesn't do anything so how do I figure out what they are good for?

Besides the fact that it's a little overwhelming because there is so much stuff in your game, I think this has a lot of potential! Especially that you can design your own buildings is a pretty cool idea.

 on: 2016-08-25 14:26:39 
Started by Spasi - Last post by Spasi
Modular maven artifacts are now available in the snapshot repository. More details and a request for feedback, here (you may also reply in this thread if you prefer).

 on: 2016-08-25 14:24:26 
Started by TumultuousSys - Last post by TumultuousSys
I've removed them. When I put them, I knew it wasn't the best idea, yet I wanted to try the idea but your comment confirmed me that it was a bad idea.

 on: 2016-08-25 10:05:50 
Started by theagentd - Last post by theagentd
Hello, everyone!

As you may have seen in the "What I did today"-thread, I recently worked a bit with normal maps. I finally managed to exactly replicate the standard inputs and algorithm of 3D modeling programs, normal map baking software and all major engines out there, allowing me to use generated (baked) normal maps. My test object is a cube with smoothed normals, which uses a normal map to get back its blockiness with just some smoothed edges and corners. It all looks good...  at a distance. Zoom in and you get this:

Ouch. The 8-bit normal map simply doesn't have enough precision to exactly "unsmooth" the smoothed normal back to a flat surface, causing that blocking artifact. This is even with bilinear filtering enabled! The problem is simply that the gradient stored in the normal map to counteract the smoothness simply doesn't have good enough precision, causing aliasing (adjacent pixels get rounded to the same value), so even filtering doesn't even help if the input is already aliased.

The only real solution here is to generate a 16-bit normal map and upload it to VRAM at 16-bit precision too. That's a massive cost though. I'm currently using RGTC/BC5, which allows you to store two channels (X and Y) of the normal map compressed to half the size, with Z reconstructed as sqrt(1 - x^2 + y^2). BC5 compresses a block of 16 pixels to just 16 bytes, meaning that each normal map texel only uses 1 byte! This is a massive saving, allowing me to have more normal maps and/or higher resolution normal maps in memory. Going to 16-bit normal map precision (using the same compression trick as above) would force me to drop the compression as there is no 16-bit compression formats (at least not on OGL3 level hardware), meaning I'd need 4 times as much memory for a normal map. That instantly cuts off the first mipmap level if I want to stay at about the same memory usage as before. That's not really something I can afford. However, I read somewhere it it is possible to cram out some extra precision out of BC5, so I decided to run some experiments.

Let's first go through some theory about how BC4 and BC5 work. BC5 is just the two-channel version of the single-channel BC4, so I will be using BC4 for this example. BC4 divides the texture into 4x4 texel blocks. It then stores two 8-bit reference values in each block and 3-bit indices for each texel. BC5 is then decoded using some special logic depending on the order of the reference values. If the first value is bigger than the second one, the index describes a linear blend between the two values. If the first value is smaller, the index is partly used as a blending factor, but can also represent the constants 0.0 and 1.0. Here's some pseudo code:
index = <value between 0 and 7>
if(reference1 > reference2){
    result = (index*reference1 + (7-index)*reference2) / 7.0f;
    result = (index*reference1 + (5-index)*reference2) / 5.0f;
    if(index == 6) result = 0.0f;
    if(index == 7) result = 1.0f;

NOTE: This is not the exact algorithm used! The indices don't linearly map to values exactly like this! See for exact info on the specification!

This is the basis for how we can gain more precision out of a BC4 and BC5 than 8 bits in some special cases. If we look at the exact math done here, we see that in the first case we blend together the two reference values based on a 3-bit blending factor. This gives us 8 possible colors: one of the two original colors or one of six values evenly spaced between them. So in theory, even if the reference values themselves are only stored at 8-bit precision, since we can access 6 values inbetween the two reference values we can actually get a result that has a higher than 8-bit precision in some cases, up to something inbetween 10 and 11 bits. This would be a pretty major gain for absolutely zero cost!

However, this makes one grave assumption: When a compressed texture is read, the uncompressed result is stored in the GPU's hardware texture cache. The specification of BC4 and BC5 do not require the decompressed result to be stored at float precision, meaning that the GPU is technically allowed to simply decompress to 8-bit values, throwing away any the extra precision. However, when ATI came up with BC5 it was specifically tailored for normal map compression, and they explicitly stated that they stored the decompressed values at 16-bit precision, more than enough to accurately store the decompressed 11-bit-ish result!

I decided to try check out how Nvidia had implemented using a simple trick. If decompressed values are only stored in 8-bit precision, the resulting values when sampling the BC5 compressed texture will be exactly n/255f. Hence, I disabled all texture filtering and wrote a tiny shader that calculated textureColor*255.0, and checked how far that was from a multiple of 255. If all values are exact multiples of 255 the precision would only be 8 bits, but during testing I found that certain parts of my compressed normal map had values that were completely different from multiples of 255! So, it seems Nvidia too stores the decompressed result at higher-than-8-bit precision, which is exactly what I was hoping for! However, when I tried to upload 16-bit texture data to a BC5 texture I was unable to gain any extra precision. It seems like the driver's texture compressor converts the 16-bit inputs to 8-bit inputs before compressing the texture, so it can't be relied on for this. Drats!

I plan on writing a small offline texture compressor that brute forces the best reference values and indices for each block in the texture to create an optimally compressed normal map. I have a feeling that this will improve the quality a lot, especially for gradients like the ones my test cube has.

 on: 2016-08-25 08:32:49 
Started by philjord - Last post by Hydroque

I am definitely interested in this. I will play it when time comes Cheesy

 on: 2016-08-25 06:55:47 
Started by leSpace - Last post by leSpace
Quote from: thedanisaur
Hopefully I didn't miss something but, for what it's worth, assuming solid geometry, each point must have exactly two line segments that are edges. Once you've found a single edge you can find all other edges.
Well then how would you do that ? I mean that's true, but once i have an edge, the two points are linked to other line segments ( more than one ) so how would you select the next edge among them ?

Quote from: Archive
This is a tougher problem than I originally thought.. However I dont think that the polygon that I drew could exist in your instance because you're doing a convex hull, which by definition doesnt allow these types of jagged edges, for example, this polygon would have a line going across the crests of the spikes rather than a line going down into it.
You are wrong, as you said earlier, your first idea with the planes would have worked with a convex hull. But the polygon you drew is actually possible, this is why it is a tough problem.

 on: 2016-08-25 04:51:39 
Started by BurntPizza - Last post by philfrei
I got some good debugging done for something I'm calling an "Allanspace Sound Generator". It makes a continuous, spacey collection of sine waves, with some controls for the generation rate, the envelopes, the number of tones per cluster and basic pitch spread and pan spread. There is also a weird gizmo called a "flibber" which basically intermixes tracks rather than mixing them. This gizmo was an attempt to recreate a faulty version made unintentionally that had some bizarre multi-threading issues and is very glitchy sounding.

At this point the GUI is totally placeholder, making use of a single slider tool that only shows a label and outputs a normal (0..1). AND IT HAS NOT BEEN GIVEN MUCH TESTING and will crash (turn non-functional) if you just hit "Start" without moving ALL the sliders first. If you want to give it a try, I recommend first putting all the sliders near the middle and working from there. Or wait until I figure out a reasonable GUI.
GUI is now more informative if not particularly friendly. Now has reasonable initial settings so can just hit play and get something. One highly intermittent known bug remains, though.

I am a bit fried and will give it the GUI more work as a side priority over the next week or two, probably. It potentially could also be run from the jar via an api, if you have a need for some spacey atmospherics.

Sounds pretty cool: get two running at the same time, and have one "flibber" and the other straight. I want to expose some controls over the "flibber" parameters, and investigate adding various forms of lfo modulation to the sines.


Did some research on, for rain and wind-in-trees, for candidates effects to use in Vangard. I think I have found a couple improvements over the first wind-in-trees attempt. In the next while, I'll be expanding the api to allow ags1 to directly trigger audio events that are part of the sound-scapes. Right now she can only manipulate the volumes, not the trigger events or control the stochastic timing algos. A future api will allow the ability to control the stochastic timings as well. For the first pass (built over the last few weeks), I just wanted to get something that would work, sound decent, and could be a placeholder for a while. (The jar is 1MB and runs solo at about 1% cpu on my PC.)


So what I really wanted to get to today was this:

> downloaded LWJGL
> set up a project in Eclipse
> got the red block "HelloWorld" program to run (with some fussing, trying to figure out what they meant when referring to "your natives" and how to specify launch arguments which I hadn't done before)

The hello world program didn't run on my laptop (GLFW_API_UNAVAILABLE error. but it IS running on my desktop. Yay!

Also gathered up locations of documents for study including an example of audio playback via OpenAL. The goal is to be able to output my audio over OpenAL, via LWJGL.

Pages: 1 ... 6 7 [8] 9 10
roseslayer (507 views)
2016-08-06 11:43:29

roseslayer (465 views)
2016-08-06 09:43:11

xTheGamerCodes (538 views)
2016-08-04 15:40:59

xTheGamerCodes (532 views)
2016-08-04 15:40:24

orrenravid (878 views)
2016-07-16 03:57:23

theagentd (957 views)
2016-07-11 14:28:54

Hydroque (1053 views)
2016-07-06 05:56:57

Hydroque (1036 views)
2016-07-03 08:52:54

GrandCastle (851 views)
2016-07-01 09:13:47

GrandCastle (643 views)
2016-07-01 09:09:45
Rendering resources
by Roquen
2016-08-08 05:55:21

Rendering resources
by Roquen
2016-08-08 05:52:42

Rendering resources
by Roquen
2016-08-08 05:50:38

Rendering resources
by Roquen
2016-08-08 05:49:53

Rendering resources
by Roquen
2016-08-08 05:32:39

Making a Dynamic Plugin System
by Hydroque
2016-06-25 00:13:25

Java Data structures
by BinaryMonkL
2016-06-13 21:22:09

Java Data structures
by BinaryMonkL
2016-06-13 21:20:42 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!