Please share the crisis
I think you will find I am now old and fat and running out of hair.
Though if I managed to diet and had a shave Iād maybe look a bit less decrepit.
Cas 
Well i shave, and yea it works a bit. Then i got a part time job driving buses. I have to cycle 8km to work. So 16km a day. And now i\m loosing weight. But went to a rave in a cave in the weekend. Was the oldest person there by over 5 years, out of 100 pplā¦ shesh.
Today I logged into JGO for the first time in a year, and started adding curly bracket support to TreeML, as an alternative to tabs.
Today, I finally had the time to add new stuff to Tetouris.
Feel free to play the new version.
[b]
Google Play: https://play.google.com/store/apps/details?id=br0ken_m1nd.tetouris.android
Itch.io: https://br0ken-m1nd.itch.io/tetouris
[/b]
Today i realized i have litterly done nothing constructive at all for 2 weeks. :
Just submitted my PhD. It took 5 years! If anyone canāt sleep, Iāll send you my work on ātax abitrage and minimisation in a comparative statics and general equilibrium settingā.
Iām now looking forward to doing more Java game programming.
Congrats on getting it submitted. Writing up a PhD is not the most fun thing you can do with your time. 
What do you guys think of our Status Menu? Edit: please donāt mind the silly item names. Theyāre just for testing.
Also, theagentd and I are thinking about making the We Shall Wake/Robot Farm game engine open source once RF is done. Would any of you guys be interested in using it if we did? It uses LWJGL3 and JOML. We think itād be cool to maybe get some kind of free open source community game engine going in Java (besides jMonkey of course). Iām not really sure if anyone would actually want to help though haha.
[quote]What do you guys think of our Status Menu?
[/quote]
Clean, but too many and too long words, a bit bland and crowded.
It looks good, i like the general looks of it, but usability might be a bit meh because it lacks symbols and visual clues to differentiate stats, you have to actually read the densely placed text to know what is what.
The triangle indicating which character is selected is a bit badly placed right at the outline of the stats section, it looks like itās just part of the outline.
The character selection could use some visual clues as to which character is selected, like scaling down the icons of the characters that are not selected.
[quote]Would any of you guys be interested in using it if we did?
[/quote]
What does your engine do? Why should anyone use it instead of building their own with some framework or using another engine?
I quit jMonkey because i found it to constricting, i wouldnāt go near any type of engine if it doesnāt provide clear benefits.
The only engine/framework i would ever want was LibGDX but cleaned up and with a full 3d rendering API. Iām talking animations, light and smoke, but blazing fast and packed neatly into modules, with editors that are actually usable.
To summarize, thatās pretty much what NNGINE is. It has 3D/2D rendering, along with a sound system, and various utilities and wrappers that speed up development. Everything is module based and you can easily pick and choose what parts of it you do and donāt use. Weāre gonna clean it up a lot after RF and give it proper Vulkan support as well, but make it optional so that OpenGL and Vulkan can be interchanged (but Iām not gonna talk too much about it since thatās theagentdās baby). It also has full Blender/Substance Painter integration - we wrote plugins/export settings for both of them so that you can pretty much send stuff straight from those programs into NNGINE. Just a lot of neat tools weāve made over the years that might benefit others.
If you want to see what it can do, this is our best example we had like two years ago, although itās pretty old and not really indicative of what we can do with it now (this was the LWJGL2 version):
Q0vzfEv2-EM
Also I appreciate the detailed feedback on the Status menu. Iām gonna see if I can make whoās selected clearer. The only thing I disagree with is the ātoo many wordsā part. Itās a jRPG. Thatās an inevitability. Haha. The good news is that literally everything has a tooltip, so weāre not leaving you in the dark and you can just mouse over stuff and see what it is.
[quote]Itās a jRPG
[/quote]
Oh, kinda makes sense. Itās always good to have visual cues accompany text is all i wanted to say.
Itās not like itās bad, iām just nitpicking there
[quote]NNGINE
[/quote]
I saw that video some time ago, it looks god damn sexy, i thought it just vanished but itās good to hear that itās still worked on!
Where does it stand with GUI and other usability stuff? It would be a shame if itās the inverse of LibGDX, great 3d API but no 2d magic.
Also I would be intrigued to see how a simple scene setup/update looks with that engine?
Somthing like a box, a light and a particle spawner in an empty scene with some default skybox/skylight.
It would be a great test on how good the engine actually is actually structured 
[spoiler]PLS PLS PLS ;D[/spoiler]
Oh gosh. This enthusiasm actually legitimately made me smile. Lol. And donāt worry, no offense taken - I understand what you mean about the menus. Iām working on it now to try and make it clearer.
Robot Farm is actually running on the same engine as WSW. You can see its 2D features in just these screenshots Iām posted. We have Distance Field Fonts working for example, which means theyāll scale to any resolution. We have support for making icons with the same tech, itās just that we added the functionality too late in so I wonāt be able to fit it into RF now.
Unfortunately, the GUI API Iāve written for NNGINE will likely be retired after RF. It hasnāt held up over the test of time. But I may write a new one or see if someone from the community would be interested in writing a new UI system for it.
As for the rest, when Robot Farm is done and released, weāll make a thread on here and get some stuff going. Itās really too early to talk about it. But if you guys would use it, weāll share it. Itāll need a lot of work to make it clean enough for us to feel comfortable sharing it because itās really just a huge mess of tools weāve made since like 2013 at the moment.
Iāll post some examples to give you a generic idea of how NNGINE works as soon as I can (either tonight or tomorrow night depending on school).
[quote]Robot Farm is actually running on the same engine as WSW.
[/quote]
Ooooohhhh :o Didnāt see that coming.
[quote]But if you guys would use it, weāll share it.
[/quote]
If itās usable than sure, java doesnāt really have a good 3d engine/framework, jMonkey is a mess with aweful tools and all the other engines donāt go very far with their 3d feature-set imho.
[quote]Iāll post some examples
[/quote]
1000x thanks man :point:
Is NNGINE a fork of NGINX? ;D
No, it is a TERRIBLE DISTRACTION from the awesome VOXOID engine heās also making 
Cas
Yes, the engine is just the front-end and is just a webpage. It just connects to our server farm in China.
ā¦ which is also just a distraction from my schoolwork and Masterās thesis. =P
Got distracted building my ui interface, in my quest to get a rounded rectangle I ended up building a new vector graphics engine which has a nice triangulation routine to triangulate any shape (convex, concave, single hole, many holes). Also allowed me to do some nice gradient shading / texturing on any shape.
I wonāt go too deep into detail here, as 1. itād be way too much for one post and 2. some of it may change drastically before we would consider releasing it, so keep that in mind.
2D is mostly just simple stuff like sprite batching and some simple postprocessing, so not too much to brag about. We have some simple postprocessing for 2D (simple bloom, dithering, MSAA resolving). Not much to say here.
NNGINE has a powerful task-based threading library which allows the user to define ātask treesā to run. These tasks may be able to individually be processed on multiple threads (example: split up frustum culling into N subtasks) or individual tasks (run two non-threadable tasks in parallel). The task set additionally contains dependencies between tasks, forcing certain tasks to finish before others can run. The system has the potential to use any number of CPU cores, and NNGINE could hit 3.5x scaling on a quad core, held back by OpenGL.
The 3D engine is where most of the fancy stuff is happening. The engine is currently using classic deferred rendering, but this will be changed to clustered deferred, with an optional forward clustered rendering mode (either for the entire scene, or just for lighting particles/transparent effects etc). The G-buffer data for deferred will be customized with a storage/read shader to allow games to customize the G-buffer layout to contain the data they need.
Rendering of geometry is done using a minimal Renderer interface. The interface pretty much only has a render() function which is called by the engine for each view that needs to be rendered. However, the Renderers are allowed to inject their own tasks and dependencies into the main NNGINE task tree, allowing renderers to run frustum culling in parallel, etc. This is used extensively in the current Renderers we have implemented.
USING Renderers is pretty easy. Hereās the complete code for adding the ocean I made that you may have seen screenshots of here:
oceanRenderer = new OceanRenderer();
graphics.addRenderer(oceanRenderer);
Obviously, the complexity of the renderer depends on the actual implementation. Hereās the code for setting up a static 3D model:
modelRenderer = new ModelRenderer();
graphics.addRenderer(modelRenderer);
modelRenderer.addStaticModel("terminus", ModelUtils.readModel(new File("terminus.wam")));
Instance in = modelRenderer.createStaticInstance();
in.addModel("terminus");
in.matrix.translation(x, y, z).scale(0.5f);
//once you don't want the instance
in.dispose(); //don't forget it or it lingers forevaaa
You also need to create the NNGINEGraphics object which is the main 3D engine object (the āgraphicsā variable in the above code). This is 20 lines or so, including setting default graphics settings and setting up a camera.
Model textures are streamed in automatically on demand on a background thread by the engine by checking the materials of visible models. Gonna make model vertex data (optionally) streamed too, as itās annoying to manage right now.
Lighting includes shadowed and unshadowed point, cone and directional lights (with configurable cascades). Lighting is physically based and produces very high quality reflections, and should close to the result seen in Substance Painter when designing materials for NNGINE. A planned feature is changing the BRDF to allow for lower quality lighting, cel shading, etc.
Postprocessing is currently not heavily customizable. Every single possible setting can be changed while the game is running and updated (except GPU count and texture resolution, last one for now only, planned feature), but you cannot currently add your own postprocessing passes. This is due to the heavy integration of the passes to minimize the number of fullscreen passes and how optimized the whole thing is. Adding individual postprocessing āpassesā will never perform well, so Iāll probably introduce the concept of a complete āpostprocessing pipelineā which you can completely swap out instead. Current effects include: HQ SSAO, motion blur and depth of field (extremely high quality, writing my masterās thesis on it), screenspace volumetric lighting, HDR tone mapping, HQ bloom, temporal SRAA, tone mapping (with camera exposure etc), air distortions, and probably a few I forgot about. =P
Transparency rendering is a tough one. When designing NNGINE I went for a 100% order independent transparency system, but this wasnāt entirely optimal due to performance and memory usage. Iām not sure what to do here, but regardless of the sorting system weāll allow for lit particles in the future thanks to the wonders of clustered shading. Regardless, transparency is structured similarly to the opaque Renderers, with different renderers. Particles are a specific renderer and are in turn split into Systems for culling. This stuff is very likely to change though, so not much point in posting code. It wonāt be that far off from the above ModelRenderer example though.
Finally, the entire engine will be ported over from OpenGL to a graphics abstraction system Iām working on that will allow the engine to run on pretty much any rendering API, with the primary targets being Vulkan and OpenGL variants. The abstraction is pretty much doneā¦ in my head at least. I have some minor code and proof of concepts (read: a single triangle), but itās been on ice for some time since that. The abstraction will include a cross-API shader language (or something along those lines). Bear in mind, it will NOT be easy to work with the abstraction directly (which you would have to do to some extend when writing your own Renderers); itās essentially raw Vulkan with only very minor simplifications. That being said, the actual code youād write in that case would be surprisingly similar to OpenGL. When running on OpenGL, command buffers are emulated (still can bring great performance benefits actually). Vulkan support will allow for significantly reduced driver overhead, threaded rendering (finally linear scaling with cores!) and advanced features like manual multi-GPU support.
We got an OpenAL-based sound system, controller support, multi-window support, etc as well. We got a Blender plugin for exporting models and animations from Blender directly to our own format. We got an entire toolset under construction for converting textures to streamable NNGINE textures.
I feel like I forgot half the shit I wanted to write, but TL;DR: When released, it will be a completely multithreaded, cross platform, cross API (with Vulkan support) highly customizable engine