#Eduke32 shadow warrior generator
#Eduke32 shadow warrior code

Big number of small files caused long startup time as well. Some might say that decoding compressed sound is not a difficult task, but when you’ve got several dozens of effects at the same time, it really makes a difference – especially on consoles. Surprisingly, it caused performance issues as well – most of the sound effects were vorbis-encoded and once again it caused high CPU load when lots of them were played simultaneously. The last, but not the least was sound playback. Guess we could call is a great decision – it gave us a significant performance boost (at least 15 FPS in complicated scenes on PS4). Using this feature, we modified the first pass to produce a command list for rendering for each vertical level and on the second pass, we replayed those command lists in the right order. We slightly improved it by adding a feature to record command lists and execute them later. And that was a great opportunity to eliminate the double work by new renderer architecture which was mentioned earlier. The first pass was also causing the same amount of vertex processing as rendering does. The implementation of the feature caused double-processing of world geometry: the first pass to determine level order – back to front, and the second pass to actually render them. TROR is EDuke32 feature which allows the construction of sectors in a vertical arrangement.

All of possible options would require rewriting the whole Polymost, but it didn’t suit us for sure.ĭuring the work we discovered that Polymost does the double work due to specifics of TROR (True Room Over Room) implementation. Our task was improving algorithms or run on multiple CPU cores, but gotta confess, we fail and couldn’t find an easy solution. It goes without saying that our main task throughout whole development process was work on speeding everything up – on this level of geometry complexity it took way too much of CPU resources. Next thing to work with was the speed of Polymost itself. Luckily, the game has both types of assets. The only scene where the rendering thread wasn’t performing good enough had too many voxel objects around, so we simply replaced distant voxels with their sprite counterparts to solve this problem. The new architecture relied on generating a list of draw commands instead of calling graphics API directly and sending it to another thread for actual execution, and it allowed us to take better control over the rendering order and helped us to deal with the glitches.īatching got worse but due to the fact that all GPU work was already on a dedicated CPU core, it didn’t matter since overall performance significantly improved. The renderer we had at that moment was still tightly bound to the main thread and to unbind it we had to largely redesign the renderer. Due to a fully single-threaded nature of the engine, the CPU was busy with GPU synchronization (20-25%), so we decided to find some way to move all the graphics calls to separate thread to off-load the main thread. So we had to come back to looking into the renderer.Īs the matter of fact, we had to rework the renderer to accurately keep the rendering order to get rid of those glitches.

And even after all the improvements we manage to achieve, we were still suffering from poor performance during more complicated scenes and had some minor graphical glitches. But achieved result showed that this time wasn’t wasted: after translating all of the game scripts we were able to get an average 10-15 FPS increase.Īnyway, performance problems weren’t the only thing we had to face.

#Eduke32 shadow warrior generator

It took us one month to implement a basic translator using a parser generator called ANTLR4 and another month to debug and optimize it.

The way we picked wasn’t an easy or expected one – after few unsuccessful attempts to speed up the CON interpreter, we agreed on converting all scripts to C++ code. Which is not such an easy thing, by the way, since the script execution could take up to 50% of CPU time.

The bad thing about it is that this kind of approach has huge performance penalty, therefore you can either find a way to neutralize it or deal with it. Ion Fury relies on those features to implement all of the game logic, which allows developers to make fast iterations during development. But in EDuke32 virtually all aspects of the game can be accessed and manipulated via events, structures, and variables. Most aspects of the game (weapon firing rates, camera positioning, physics, etc.) couldn’t be altered.

#Eduke32 shadow warrior code

In the original Duke Nukem 3D for DOS, the CON scripting language was relatively limited, and was mainly used to code simple AI routines for monsters and manipulate the player’s inventory amounts.