i started making a game about alien blobs for a java game jam.
installed apache squid git scm-manager nexus-oss and mumble on my new root server \o/
Thank you! But yeah, that was a design choice, Iād find it incredibly tedious to have to hand-code every aspect of a game to build on top of it. The goal for this is that the editor should be the completely self-contained authoring tool, but users should be able to override default code with custom implementations - for example, dialogue/sentence renders can be implemented and assigned to the dialogue manager. Game loops have base code to take care of timing and core updates but they can be extended to have custom update and render loops on top of this.
Played around with cabinet projection. Itās not actually 3D, itās just three quads rendered like that because Iām scared of touching libgdxās 3D API.
Today in the IRC we were discussing the JGO stats and noticed some interesting things.
In the last couple of years:
- User count has stayed pretty much the same.
- The number of posts and topics made have dropped off significantly.
- New account activations have dropped off
- New account abandonments have dropped off.
From this it seems that it means that weāve got fewer new people but more people sticking around, which by an extension of such logic would mean that overall our community is becoming more experienced, which is nice 
It also means that the people who are here are posting less.
A personal observation is that the quality of projects here has risen significantly in the last while, so my theory is that while we are getting fewer posts, we are getting higher quality ones (thanks to the likes of theagentd).
Or maybe Iām totally wrong. Iām sure that Riven will inform me if the latter is correct.
The thrill of user interfaces. What a faff coding them is. Just getting all that windowy stuff working was a royal pain. Nearly finished with this lot now.
c1NmkwK83R8
Cas
Fog changes with time of day
Update to GWT-AL, we can now set the properties AL_POSITION, AL_LOOPING, AL_PITCH, AL_SOURCE_RELATIVE, AL_VELOCITY, and AL_BUFFER. I have updated the example to support all these properties.
Also that the example logs OpenAL errors if any to the console.
I guess this will be completed in a few more weeks. Time to work on the listener. See you soon with more updates.
Been working on a voxel renderer for a while now, and itās been a fun learning experience. Today I added trees, and now my landscape looks much nicer.
http://i.imgur.com/zQMMZIM.png
If youāre interested in how fast it runs, I am standing at about the center of a 1056x1056 block world and have a frame time of about 4-5 milliseconds on a GTX 770.
That looks awesome 
Are you going to turn it into a game?
Added circular bars (by davedes) to the eXo interface, displaying infrastructure development level and ship building progress. That was really easy to integrate!
Also altered the redirect mechanism: ships can now be redirected along multiple stars, making it much easier to maintain a supply chain.
Found out a long lasting bug in my AABB/ray intersection tests that I was also using in a stackless kd-tree traversal GLSL compute shader. Turned out that the simple ābranchlessā Ray/Bounds intersection test that is flying around all over the internet (like here: https://tavianator.com/fast-branchless-raybounding-box-intersections/) is complete bogus, because it does not handle corner cases correctly, where the ray direction is negative along one of the three coordinate systemās base axes and/or also cuts along one of the AABBās edges/sides.
Switched to using http://people.csail.mit.edu/amy/papers/box-jgt.pdf, which also needed a tiny modification to handle all cases.
Complete working solution for a Ray/AABB intersection method that handles ALL cases except for degenerate rays and degenerate boxes is here: http://pastebin.java-gaming.org/6f9f65b0b4c19
added a simple story:
added eye lazer mining to the blob game ;D
Little demo. Re using a lot of old code, but completely changing a lot too. Planning on adding a background skybox thatās just kind of some raycasted fog and some other random somewhat trippy effects (metaballs and the like).
tXwVG8YRH1A
Hey, sorry I havenāt managed to respond earlier. Iāve been at a convention over the weekend.
Hmm. Depth peeling isnāt too useful in practice since it can only handle a fixed number of layers, plus requiring one (or at least half a) pass per layer of transparency to capture, which scales very badly. Pretty much all recent techniques are based on Weighted Blended Order-Independent Transparency (WBOIT). In essence, you just compute a weighted sum of values, which can be computed in an order-independent manner. The key here is that any transparent shadow map technique can be used as weighting function, since they compute a function of alpha over the depth of a pixel, which can be used as the weighting function.
Depth peeling
- Constant memory.
- High quality result identical to sorted blending.
- Slow in general.
- Canāt handle a big amount of overdraw without big performance impact from lots of layers.
- Canāt handle volumetric effects very well (sudden order switch between two smoke particles).
Stochastic
- Constant memory.
- OGL3 compatible, only requires 16-bit float textures.
- With enough samples identical result to sorted blending.
- Can modify depths of samples to give volumetric smooth blending between volumetric effects (two particles that change order smoothly fade through each other instead of suddenly switching order).
- Only 2 passes over the geometry.
- In general very similar result to adaptive OIT.
- Very noisy with only 32 samples maximum (8xRGBA16F), especially with HDR effects.
- 8x 8-byte textures @ 1080p = 126MBs, lots of bandwidth and memory required.
Fourer opacity mapped OIT
- Constant memory.
- OGL3 compatible, only requires 16-bit float textures.
- Smooth blending/fading when two objects change order, looks good for volumetric effects.
- Only 2 passes over the geometry.
- Can compute visibility function at low resolution and upscale using hardware bilinear filtering for massive performance and memory gains.
- Can have very good quality and performance when its limitations are avoided.
- Blurry result.
- Self occlusion in the visibility function can cause color bleeding over to background objects.
- Low res visibility functions only look good with smooth effects like fire or smoke. Edge artifacts on sharp objects.
- Even sharp transparent objects are smoothly blended together on order changes/intersections.
- Occlusion quality strongly depends on the depth range of the scene, so with a high far plane distance the result becomes very bad making it impractical to use in many games.
Adaptive
- The holy grail of OIT.
- Identical quality to sorted blending with 20 samples or more in essentially all cases.
- Bandwidth usage (and therefore performance) generally lower than stochastic or FOMOIT.
- Requires atomic counters, only available in OGL4.2.
- Using linked list means that you have to allocate a huge fragment buffer.
- Developed by Intel, but compiling AOIT shaders crashes the Intel entire driver during glLinkProgram().
Most of this had to do with JGO registration emails being blocked (or marked as spam) by mail-servers. In the end of december I changed the registration procedure to not require activation. Since then we have quite a significant influx of newbies, which are hopefully going to change the stats significantly over the coming year. So, yeah, anti-spam measures ādistilledā JGO user-base to maturity, which was rather terrifying (well, you saw the stats plummeting)
This is probably my favorite thread Iāve ever seen. I donāt belong here in terms of just saying I finished rendering my tilemap, fixing my sprite and orthogonal matrix issue, and working on fonts now
Donāt worry, itās absolutely fine 
I use it as base comparison since it is the one that generates the exact image at the fragment level.
Anyway, it can absolutely render all the transparent levels there are, although you have to pay (a lot of) time for thatā¦ add a query any-sample-passed and you are done
Interesting, when did you try it last time? Canāt you have it run under amd or nv? I found this
It is possible to use conditional rendering to avoid the CPU-GPU synchronization when deciding on the number of depth peeling passes, but that kind of synchronization isnāt very efficient either. Besides, you may not WANT to do 200 passes of all geometry even if you can. Hmmā¦ Maybe itād be possible to use the stencil test to disable pixels that didnāt get any data the previous frame or something like that to improve performance, but processing the vertices again will probably be the bottleneck anyway.
I have an AOIT render path implemented in WSW. Did an extension check for atomic counters and loaded the AOIT shaders if it was available. Sadly, this made the game not start on Intel since simply loading the linked list traversal shader made the driver not just generate an error but completely crash the entire game. So we released the demo with AOIT completely disabled (FOMOIT is used by default). Even if Intel has fixed it by now, older GPUs and people that havenāt updated their drivers will still experience the same problem.
i added an inventory/building system that saves.
