-Carnage-

I love Quake3 Arena, I love it so much, that I'm rewriting it for the Unity Engine: As I feel so disappointed with Quake Champions, as they took years just to just to bring "The Longest Yard", that felt like they wasted all the potential without a proper mapping tool.

Now you can Play Doomity directly on your web browser: https://kncarnage.itch.io/doomity

Actually it's on 2017.4.40f1 ;)

32:9 WOW! I didn't even know that was possible LOL I though the most would be 19:10, so yes the UI was scaled to the max wide. You can change the resolution before starting the game: -Select "Doomity.exe" -Press "Shift" Key -While holding down "Shift" Double Click on "Doomity.exe", the resolution dialog will pop up There you can choose a 16:9 resolution to try it out. I will have to work on 21:9 and 32:9 aspect ratio thanks for pointing it out. Yes everything will be released on GPL3 as soon as we get out of beta. Thanks for trying it out

Today we are ready for our first public Beta Release: https://www.dropbox.com/s/6v4j3s0ocpiabxn/Doomity_v1.7b.zip?dl=0 That it's the base, and include the shareware version, just unzip and run https://www.dropbox.com/s/k6a8wbiryxjvtbd/HDAssets.zip?dl=0 Here are the HD, just unzip everything on the same folder and you are ready to go. Options menu it's not working but everything else is (SAVE/LOAD) there are just a few things missing (text/end text) Thanks everyone for your support in making this release possible. Here is a gameplay video of my favorite Doom2, so you can check out how Doomity works.

@Redneckerz Finally here is the answer. NUTS.WAD on Doomity

I was doing some shaders changes, and while testing the following scene formed, which I found interesting enough to capture.

Wena poh! Another Chilean here. Home of Batman Doom and Zan Zan TC I though I was the only Chilean left here, after all these years.

That's awesome, and the general idea that started all in Unity. I did the same thing for wolf3d, a png that was a map and then populated, indeed Unity is a great tool. However currently I'm rewriting everything. Why? Because basically we a looking at a different approach, switching to Data Oriented, as explained on the Video The problem was that for 2020/2021 Unity was completely silent on DOTS, (there was speculation that it was being phase out), so I stopped the rewrite until the dust settle, but finally a few weeks ago, they made a massive update (from 0.17 to 0.50) So there is a TON of work to do, to get where I was back then but now on DOTS

@omalefico32x Don't worry, there is no hurry, this is something that should be funny so take all the time you need. I've been working heavily on improving the performance using nuts.wad as an stress test. So we are pushing heavy on performance

Finally the monster controller was completely remade, the logic (animation, behaviors, etc) remain on the main thread, while all physics (movement, pathfinding, collision) went to the physics engine. Again on MAP10 with 279 monsters active and doing their stuff: So for 279 enemies it takes just 4.52ms! There are few cons with this aproach, as the movement went to the physics engine, it use the forces and velocities vector, that means that monster don't do a full stop on just 1 frame, they decelerate (kind of small slide), so that means if pinky is running toward the player and then get to do the bite, if the player move back he will be bitten as pinky still have momentum to reach the player. Another issue is on the steps, as some heights are ridiculous height, and the physics engine calcs asume that height is unreachable for a gravity of 9.8ms2. I will have to do some verifications for steps and add aditional force to reach them. Anyway @Redneckerz thanks for your feedback as it made the whole enemies bottleneck to go away (Now is the Garbage Collector the new bottleneck as you can see on the pic above). As soon as that's done I will post a video with the results on NUTS.WAD (hope it behaves LOL).

@DavetheDoomguy Just realize that I forgot to answer this. Yes the Garbage Collector take care of the "no longer in use" memory. The problem is that is easy to generate garbage and when it max out it cause "Lag Spikes" so instead of just using a new ray (new memory) for a raycast, to reuse it from the last frame (pool that data), that comes specially important for the Arch-Vile as he is constantly casting rays every frame to check for dead monsters. Same goes for projectiles, etc

Wow, it's been a few busy days of work on the new monster controller: Nvidia CC was completely removed, right now, the whole monster controller (logic, movement, pathfinding, animation etc) for 279 enemies takes 6.48ms, we are getting there. I think we can still squeeze a few ms, and made more improvements. I think I will also add a frame skipper in case there are more than 500 enemies, after all Doom game logic was capped to 35 frames per second, yes trying out different things.

@Redneckerz I've been working on Doomity exclusively into solving this bottleneck. I tried numerous differents things, even going to the plain movements without any type of collision detection, after doing some more test (using MAP10 as a base) I started with all enemies in awaken state and got the following results: Yes it was horrible, as those 279 calls to Move function (NVIDIA PhysX 3.3 Character Controller) took 16.14ms almost the complete 16.66ms for a smooth frame (60FPS Vsync ON). So it seems it was about time to ditch the Character Controller for enemies, and I think the number seems ok, as basically it maxed out on 279 characters, and as it was designed for players, having 279 players at the same time is indeed a huge load. So, here comes the new approach, drop all that load directly to the physics engine (NVIDIA PhysX 3.3), so I did a quick and dirty code change (everything to rigidbody) so in just 1 call the physics engine, it took care of every collision and movement of enemies, the result is as follows: Wow, having the same MAP10 courtyard with 126 enemies active it took just 0.3% of the CPU load in 0.11ms! That's almost 260 times faster than the previous 103 calls (CC.Move) that took out 2.85ms. So doing some quick approximations to get the same previous results, it would take 32,760 enemies (126*260) to drop the fps as it previously did with only 103. It looks like if the code is improved NUTS.WAD should run smoothly! So time to get back to code and clean up the new rigidbody movement. 

@Redneckerz Thanks for the PM and the feedback, and Yes you found the bottleneck we currently have, it's not on the GPU but on the CPU As you can see on the screenshot (Doom2 MAP10 player on big courtyard) what takes the most CPU is NVIDIA PhysX 3.3 Character Controller (Move function) and as you can see, there are actually 103 (out of 279) active enemies and moving, to achieve smooth frame rate (60FPS Vsync ON) we only have 16.66ms per frame, those 103 calls (CC.Move) took out 2.85ms (21% of the CPU Load), which is a lot. I will try different approaches on how to deal with this bottleneck, I think Doom just send the enemies back to being inactive once they are far away, probably could use the same PVS approach that worked for rendering but this time for the enemies.