Congratulations!
Added a performance graph and optimized the model debugging (and a buttload of âengine-stuffâ)
I did the LWJGL session at JCrete yesterday. Not a great turnout, but was good fun. I got most questions from Jaroslav Tulach (NetBeans architect, now working on Truffle/Graal). Spent a bit of the afternoon with him, building Graal and exploring its source code. It sounds like it might be a great alternative to Project Panama for native interop.
Apparently he also talked to Cliff Click about it and he decided to make a session this morning on âwhy JNI is slowâ. Iâm familiar with the issues and Iâd seen that presentation before, so not much to learn. An interesting note was on native-to-Java callbacks: theyâre slow because theyâre always interpreted. He wasnât familiar with Panama or JNI Critical Natives. Showed him some critical native code in LWJGL at the end, I think he was a bit surprised that it actually works.
I also did a session on Kotlin today, quite a few people showed up and most of them hadnât seen it before. Not much you can do in an hour, but I think it was enough to get them started.
Phew! Today was optimization day. Shoutout to theagentd for helping me with optimization over skype and teaching me some things about memory management and data reading and writing on the CPU. Overall, I increased textured rendering speed by 1.5x!
Iâve finally released a version of Naroth that supports the russian language (and also includes new images for the character creation process). Both combined look like this:
Added bounding box based shadows on the lightmaps 
Looks pretty good, but itâs not perfect yet.
Do you use automatic lightmap coordinates generation, or are your meshes parameterized?
@ags1, the whole thing is on github if you feel lazy today ;D
FrameTimeDebugRenderSystem.java
I also added an update time graph! The lower graph just displays fps with fps=1/delta which is also useful but not as useful as the time needed to run the update and render loop.
I calculate the lightmap UVs by finding the distance between the polygon vertices and normalizing them
More what I did yesterdayâŚ
I love the last one, looks like actual art
I ran some small tests on Vulkan pipeline creation. Vulkan has two ways of improving the performance of creating pipeline objects: derivatives and pipeline caches. Derivatives allow you to hint Vulkan that there are big similarities between two pipelines you want to create and that the driver should do its best to reuse data from one pipeline when creating the second one. A pipeline cache is an object you pass in when creating pipelines, and the driver is free to store and read data from the cache when creating pipelines. In addition, this cache object can be serialized to disk and reloaded later, allowing you to persistently save the cache between runs of your game, improving load times after the first run.
I simply ran a small test creating 1000 pipelines 100 times and measuring the average time it took:
Nothing: 86.599ms
Cache: 80.048ms
Derivative: 86.826ms
Cache+Deriv: 79.531ms
In other words, on Nvidia drivers derivative have no impact on load times, but the cache does take off almost 10% of the load time. In addition, the cache is thread-safe, allowing you to use the same cache from multiple threads. Looks like the simplest and fastest solution is to ignore derivatives and just multithread the whole thing while using a pipeline cache, at least on Nvidia. If someone has an AMD GPU, itâd be interesting to see how their driver deals with this.
EDIT: The above tests created all pipelines using a single vkCreateGraphicsPipelines() call to create all 1000 pipelines. If I create 1 pipeline at a time using one vkCreateGraphicsPipelines() call each, it takes around 92ms even with a cache.
In two weeks Iâll take a plane in Paris and will be out of France for at least 5 years
Going to study computer games technology at Abertay University Dundee, Scotland
J0
Today I made a console for my game.
I will use this to easily test features in my upcoming game (but I am planning to leave the console in the game).
It doesnât have many commands as of now but i will extend it 
![[->full size]](http://i.imgur.com/sjuSA8t.png){kind=link}
On Sunday I figured out enough about MIDI to set up a Receiver and obtain real-time messages from my synth keyboard (a Yamaha DX-7S), intercept and use them to play one of my Java FM synth patches. Iâm only responding to key-on and -off, making use of the MIDI key and velocity data.
There is a bit of lag, but it is not terrible. Could still work for someone playing solo, or playing ambient or in a situation where being âin the pocketâ is not required.
Next step is to interpret MIDI sequence files, where the timing info is included.
âMaster planâ : to have some degree of parallel development in DAW and Java available, having the same âpatchesâ available in both (have about a dozen so far, aiming for more like 60). Then, can compose music in the DAW, save to MIDI, import the MIDI into Java for procedural playback. TODO steps include translating the midi into the event system Iâve written, as well as dealing with unanticipated pitfalls. Lotâs to do still.
Today I made the thing with my DataProvider classes (had a recent What I did today post according to that, TL;DR all game assets and stuff are loaded through an abstract data provider class and I already had several implementations to e.g. map folder to memory and so on) even better:
GameCreator is now enabled to write the release version of the game directly to memory, starts the GamePlayer as a second process which then loads from it (over socket connection) - so no data is written to disc and it is quite fast
Had a quite productive dayâŚ
Integrated an Artemis-style ECS (Entity-Component-System) into my game and prepared everything for parameterizing my entity class and component classes with class reflection (makes loading entity templates into memory much easier)
Also finished the JavaFX-GUI for the World Editor of that game (using FXML and Scenebuilder) and started to work on the logic (JavaFX-Components are harder to handle than the good old Swing components PHEW)
Ray traced shadows now instead of bounding box :0
Textured
Not textured
Textured
Not textured
Lost a couple of days of Vangard prototyping due to computer malfunction. The power saving mode laptop CPU was set to 100% and cooling was set to passive⌠so it cooked itself while doing a system update. How did that even happen?
Just Windows. (I guess?)
And when it comes to overheating⌠Shouldnât CPU automatically shut down when its sensors detect that temperature gets too high? Intel CPUâs have special sensor that do emergency halt on hardware level when reaching high temperature (something like 90-95 degrees, exactly 93 on my old laptop), without communicating with OS or even BIOS.