Isotröma 2017

[N_I_C_S]

////// 23-03-2018

//////

Hello,

Today i’d like to share with you some of my progresses on this project i develop episodically since many years, with the hope to have one day a real game…

The goal is to make a nervous fps in a set of many short and intense stages (after loosing myself in several gameplay tries, like too big procedural maps, i finally went back to this idea, which was the very first one).

The possible “originality” could be in the resolution of different “puzzles” based on the switch of gravity, taking control of opposite mobs, and terrain shapes modifications.

The technical part is still based on a homebrew game engine using LWJGL, Paul Lamb Sound System and PNGDecoder, so i hope this topic can help me verify its functioning at this point.

So i submit you a little demo, short to test, containing 2 basic stages. As i have at this time no communication platform, i can put a simple direct link :

http://tesseract-fps.sourceforge.net/isotroma/isotroma_sample.zip

Compatibility :

• Java 1.5 and more
• OpenGL 3.0 and more

Thanks for your attention .

Screenshot :

[Gornova]

I like it, really fast gameplay, remembers quake1 from some points, so I like it!

From your description seems to be a puzzle game, but is a FPS on the core!

My suggestion, release your game on a platform like itch.io or gamejolt!

[N_I_C_S]

Thank you,
actually it will be definitely a fps ! i will try to exploit smartly a few “reflexion” things without lowering action, which is perhaps not so easy .
Thanks for reporting me itch.io, i didn’t know and it seems actually more “convenient” than steam to release his little game.

[orange451]

Cool to see this again! Runs and feels really nice. Load times are great.

The only graphical problem I found was the overlapping blood splatters on scene 2, which just looks like a shader trying to write to itself while reading itself.

[N_I_C_S]

Thank you !

Actually the meshes are rather low polys so the loadings follow, the slow part is the tris generation of the marching cubes terrains, but multithreading finally fix it pretty well.
Ok for the decals, it’s a deferred display, i must get tangled up between gbuffer configuration, blend setup, … I’ll take it back, thank you.

[orange451]

Had a similar problem in my engine a few months ago. I just created a temporary copy of certain pieces of the GBuffer, wrote to them, and then afterwards wrote the temporary copies to the original.

Not sure if that’s an efficient way to do it… but it worked out fine, and stll runs alright on my laptop.

[N_I_C_S]

Sorry for answer time,

Thank you for the advice, before trying it i modified 2 little things which could make the error :
i binded all the gbuffer attachments even when i currently write the decals on 1, so i try to only bind my “albedo” one and switch from gl_FragData[xx] to gl_FragColor in the decal shader.

Theorically, it would be the same than for example displaying blended meshes in a fbo…

For me, it’s ok on my pc with radeon and laptop with intel chip,
please, may i ask you, if you have time, if you could try the new version if there’s a change ?
( http://tesseract-fps.sourceforge.net/isotroma/isotroma_sample.zip )

[orange451]

Oops, I hadn’t seen your reply. I will test it out when I get home later today.

The main cause of the problem on my NVidia card is (how TheAgentD put it to me) due to the tile-based rasterization. Leads to faster graphics drawing, but can create some more graphical headaches if you don’t follow graphics programming rules strictly.

To better clarify what I wrote before. If I bind a texture for a shader, sample from that texture, and also write to that texture (at the same time), it can lead to the tiling issue (on certain drivers (newer ones) on certain NVidia cards (newer ones)).

[EDIT]
Just tried the new demo. The tiling issue is fixed

[N_I_C_S]

Oh thank you very much !

Yes actually i met this damned fbo read/write issue a couple of times !
And i think that’s what happened to my gbuffer : to write correctly on the “diffuse” fbo, i need to read the “normals” fbo.
But to write on this diffuse attachment i binded all my gbuffer for draw, including the normals attachment, which surely caused this read/write problem in this normals fbo.

That leads me to realize another issue : if we want the decal to also update normals, specular, gloss, etc… it must take 2 passes : one for the blended diffuse and one, with raw replacement, for the other channels…

[orange451]

That’s what I ended up doing in my engine
Decals can modify the diffuse, normals, and specular.

[N_I_C_S]

Great !
I think i finally got it : : if you write decal parts in a separate buffer, it must be to manage the normals (which can’t be read and updated).
To solve this i have already a feature : my gbuffer contains also a “flat tris normals” buffer (i did that to have clean cascaded shadow maps with normal bias…), which could be read instead of the regular normals one. Theorically it should end up the same than your solution.

[N_I_C_S]

Hello,

I’d like to show a few screens of some little progresses done recently :

while working on a new level, i improved at the same time some of lighting computes, like per-vertex color on voxel terrains, for a better contrast :

(the “columns” in the middle are my artistic contribution ingame…)

I also worked on a better integration of the “classic” meshes in the voxel terrains, by modifying their lightmaps compute to take the terrain into account :

(lightmapped stairs and pile of bricks)

See you soon for the finished level !

[N_I_C_S]

Hello,

Just a little up to keep this topic open (i feel ridiculous to make one by year !) and to show a bit of the progress :
the level making (slowly) goes on, i’ll be soon able to release it as a demo.
Until then, to avoid graphic spoils : , here is a screen of the same place than higher :

See you soon !