-Carnage-

I'm happy to announce that DOOMITY has gone open beta: Now you can try it out directly on your web browser: https://kncarnage.itch.io/doomity FAQ: WHAT IS DOOMITY? DOOMITY is a module of the "United Generations" (Behemoth) Project, that aims to have all the Classic ID games (Wolf3d, DOOM, Quake1 and Quake3), playable under the Unity Engine in the spirit of the late Quake2 Generations (https://web.archive.org/web/20020306115539/http://www.planetquake.com/generations/) WHY? THERE ARE A LOT OF OTHER SOURCEPORT DEVELOPED DOOMITY is not a source port, it's based on Risto Paasivirta's Doomloader (https://www.doomworld.com/forum/topic/98682-doomloader-for-unity/) which is based on Pascal vd Heiden (CodeImp) Doom Builder, which allows to get the geometric data of the maps, to have a polygonal representation which Unity can work with, then the gameplay elements are added on top of it to have Doom "feel" gameplay, the only part of the code that's share with other source ports is Randy Heit's Mus to Midi converter (mus2midi.cpp). HOW DOES IT ACHIEVE DOOM GAMEPLAY? At startup it load the selected iwad (doesn't have a iwad selector yet), the it cache the textures, images, sounds and finally it load the selected soundfont, then it start reading the corresponding map information (linedef, sidedef, sectors, things, etc) then it start building and populating the map dynamically, basically all of Doom gameplay information/elements were taken from https://doomwiki.org WHY THE UNITY ENGINE? Because of the editor and the support it has. Having an editor run at the same time as the gameplay is priceless, you can make changes to the map, add/remove stuff, check the drawcalls, etc, and not to mention for the debugging information, really priceless. One common problem/limitation that all source ports have is that they need to upgrade the rendering engine in order to take advantage of any new API (Vulkan, Direct3d, OpenGL, etc) or to add new visual enhancements. When developing for Unity, you don't need to worry about this (probably in the future will have to worry about Mono vs DOTS), also to have a common engine allows for a really easy integration between all these games, also using Unity allows us to port it to different platforms (including Wii-U) TECHNICAL STUFF: BEHIND THE CODE Rendering and Collision Getting everything loaded for a map had some limitations, we got the same problem that Carmack got when porting Wolf3d for the SNES, the hardware began to struggle. As everything was loaded on a map and having only Frustum Culling (even though Unity offers Occlusion Culling, it must be used for static items, as it need to bake the map in order to get the data to know what to occlude, however as everything is loaded dynamically we cannot baked it) we had a lot of overdrawn getting even more than 8000 draw calls in really populated maps. Doom solved this with Binary Space Partition, however as our approach was different as we were working with meshes we wanted to move forward to a more modern approach, here is a good read (http://www.robotrenegade.com/articles/id-tech-3-optimization/vis.html) so basically every sector needed to be broken down to convex subsector (BSP) to be culled with a Potentially Visible Set (PVS). Vavoom had PVS implemented and their solution proved to be fast and efficient (https://www.vavoomengine.com/glvis/). So the rendered was done on the subsector occluded on the PVS, however having so many triangles and meshes for the collision detection was a bit overkill, considering Doom used the Blockmap tables, we wanted to improved a bit, so in our case we used the original sector meshes as our collider meshes. AI Doomloader original had Breadth-first search algorithm for pathfinding, however because of the algorithm chosen and the way it was implemented, it had a lot of limitations, basically everything was searching for just 1 target (player) and the way it was implemented was really CPU intensive (when tested on the Wii-U it was the most CPU consuming process), so it had to be removed but the quick grid look up tables were kept, as they fast to access and to check for every triangle either on the sector meshes or subsectors, anyway A* was chosen as the pathfinding algorithm, and has proven to be fast an efficient. Music Doom original music it's just too awesome, I don't think any MP3 can surpass the feeling that, Unity doesn't have any midi player, however there was C# Synth Project (https://archive.codeplex.com/?p=csharpsynthproject) that was used as a based and ported to Unity (yes it works on the Wii-U) along with Randy Heit's Mus to Midi converter (mus2midi.cpp), allowed to use soundfonts to load and play the original Doom Soundtrack. External Resources Doomity can load external resources (HD textures, etc), the fastest way is to have everything loaded as resource in Unity and then it's packed and ready for use, however that present a huge limitation when trying to use other textures, graphics, whatsoever, so it was design to load everything externally then search for internal data and finally inside the WAD. It takes some time to load all the data when the program is launched as it need to convert the png images "friendly" to Unity (DXT1 or DXT5) WHATS DONE SO FAR: Technically Ultimate DOOM (Episode 1, 2, 3 and 4) and DOOM 2 is completely playable. 4 Splitscreen Multiplayer it's been working on. END GOAL FOR DOOMITY The rendering code was design for a 4 player spit screen, so that would be finished as soon as we get a good Customizable Doomguy model. Online multiplayer will be implemented also to work between platforms (Wii-U and PC, Android, etc) CREDITS There are a lot of you guys here on Doomworld that I have contacted and asked permission to use their resource, etc, everyone of you that has help pus over these past months/years, the project is huge and a lot of people have been involved, Thank you all, everyone will be properly credited If you want to help of be a betatester, just post here and I will pm you with all the necesary information Thank YOU ALL WHERE TO PLAY You can download it here 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)

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.

@omalefico32x Glad to have you back. I'm working on a new version but I'm hoping to add and check the most in order to release it by Sunday. @DavetheDoomguy Yes and not only bugfixing I'm trying to optimize the most, currently reducing the load on the Garbage Collector as much as it can.

@DavetheDoomguy Yes indeed. Actually is almost complete so I should have a new beta really soon, just want to wrap up the most bugfixes possibles.

@DavetheDoomguy that's the idea of the beta program. Right now I'm working on enable the textured automap.

@DavetheDoomguy Exactly like that. I should have put if (impulseVector.sqrMagnitude > 0) instead and no bug then. LOL

@DavetheDoomguy You cannot tell how much helpful was your video to track the issue. The body is sliding, so that mean that a force is being applied, but as seing on the video is very little force, so going up in the code //dampen impulse if (impulseVector.sqrMagnitude > 0.1f) // if (impulseVector != Vector3.zero) { if (controller.isGrounded) impulseVector = Vector3.Lerp(impulseVector, Vector3.zero, impulseGroundDampening * Time.deltaTime); else impulseVector = Vector3.Lerp(impulseVector, Vector3.zero, impulseAirDampening * Time.deltaTime); if ((impulseVector).sqrMagnitude < 1f) impulseVector = Vector3.zero; } I used to check that the impulse vector was different to zero to dampen it, however when profiling and with multiples enemies on a map, an is not equal of a vector, was doing: 1- a subtraction of the vector, 2- comparing it's squared magnitude 3- Inverting the result, so 3 operations instead of one, being called multiple times per second per enemies, things got staked up fast indeed, so I just jump to the last operation and decided that 0.1f was small enough, as then when in gets in, it will be reduced to zero. HOWEVER, it could happen that after that check when the enemy was dying, a new force came in small enough to bypass this check (ex. 0.09f because if it were alive the other forces will send that impulse back to zero) public void Impulse(Vector3 direction, float force) { if (controller == null) return; float length = force / Mass; impulseVector += direction * length; } So that's were the bug was. I could check the impulse if the enemy is dying and not add any other force, however a cool effect is that if an enemy is dying if there is a rocket or a barrel blown up, it will send the dying body away with extreme force. Thank you guys!

@DavetheDoomguy Wow! That was fast. Thanks for the video. Actually that's completely different on what I was saying on the other post, as it has nothing to do with the Character Controller (Nvidia PhysX CCT), it's seems that the enemy is not going to the Ragdoll layer, will have to investigate why. Thanks!

@DavetheDoomguy I think it's because the Character Controller (Nvidia PhysX CCT) is only disabled on the last frame, the main Capsule Collider is disabled on first frame (I had the problem in the past that dying enemies were completely blocking my path), then the object get back to a Ragdoll layer, so it's not taken in consideration for any type of collision detection, however as there is still force (actually Impulse Vector and Gravity) being applied I need to disable it when that force (Impulse) is close to 0, however has the main collider has been disable it shouldn't interact with anything but the floors and walls. Can you do a video about it, so I could check further?

@DavetheDoomguy Awesome, found it and corrected it. It was the walk trigger repeatability that was not set to false. Before the 1.2b release the stairs had only 3 states: Wait, Action, and Done, once Done they went dormant and do nothing, so there was no need for repeatability, as even the on the specs the regular stairs types was only activated ONCE (either switch or walk) (https://doomwiki.org/wiki/Linedef_type#Stair_builders) However, just before the release, I was doing a quick run and found out that on MAP21 there were 4 switches, all of which activated the same staircase (had a huge rewrite as I had to correcting the geometry in order to avoid what you just saw (seeing the sky), and also after the first activation, they behave differently as they have to grow each one either 8/16 units in conjunction and not like an staircase, because if it did, then the step were huge, well after all that rewrite I completly forgot that the walktrigger repeatability was not set to false. Thanks!

@DavetheDoomguy Yes please post it here, so everyone can see. Yes I'm really interested to find out what stairs glitch are you talking about, also so other testers can check so no double report. Thanks