DOOMITY public beta Released

[Dweller Dark]

7 minutes ago, -Carnage- said:

@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? 

 

It's a bit of a short video, but I hope this helps: 

 

[-Carnage-]

@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!

[Dweller Dark]

2 minutes ago, -Carnage- said:

@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!

 

I had some footage of that glitch from earlier around, so that's why I was able to upload it as fast as I did. But I'm glad it's helping you determine what's going on behind-the-scenes in some way. I'll keep recording these types of glitches as I find them, or whatever else shows to be abnormal from the intended outcome.

[-Carnage-]

@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!

[Dweller Dark]

2 minutes ago, -Carnage- said:

@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!

 

I'm not familiar with coding, but are you saying that the bug appears to be the result of a dying enemy being affected by a small amount of force that can get around the check you put in place? And that the way it's set up, the dying body would be blown far away by an explosion?

[-Carnage-]

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

[Dweller Dark]

9 minutes ago, -Carnage- said:

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

 

It's good we caught it in the beta though, so it could be fixed before being officially released.

[-Carnage-]

On 4/16/2021 at 6:48 PM, DavetheDoomguy said:

 

It's good we caught it in the beta though, so it could be fixed before being officially released.

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

[Dweller Dark]

4 hours ago, -Carnage- said:

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

 

I'm guessing the automap will be part of what's coming in the next beta release, then?

[-Carnage-]

On 4/18/2021 at 12:38 PM, DavetheDoomguy said:

 

I'm guessing the automap will be part of what's coming in the next beta release, then?

@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.

[Dweller Dark]

10 minutes ago, -Carnage- said:

@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.

 

Awesome! I hope the bugfixing goes well too.

[omx32x]

sorry i was away from my home for a few days i wasnt able to check the replies or play the port but im back on track i hope i can keep helping with testing are there any new versions with the bug fixes?

[-Carnage-]

22 hours ago, omalefico32x said:

sorry i was away from my home for a few days i wasnt able to check the replies or play the port but im back on track i hope i can keep helping with testing are there any new versions with the bug fixes?

@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.

[Dweller Dark]

5 minutes ago, -Carnage- said:

@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.

 

Is the Garbage Collector some kind of behind-the-scenes part of the port to get rid of some kind of unused data or something?

[Redneckerz]

Playtesting this a bit aswell, i have PMed you, @Carnage.

I run garbage can hardware, but even my junk (Geforce 6150!) could run upwards to 30 fps. But any map with relatively dense monster count tanks the hardware. Ironically, its not the graphical effects that do this, as dynamic colored lighting runs just fine. Its really in the beastiary logic.

 

NUTS.WAD will be a heavy metal workout for Doomity if it manages to process it.

[-Carnage-]

@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

Spoiler

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. 

[-Carnage-]

@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:

Spoiler

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:

Spoiler

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.



Edited April 23, 2021 by -Carnage-

[Redneckerz]

21 hours ago, -Carnage- said:

@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

  Reveal hidden contents

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. 

Doom actually keeps the enemies alive because there are tons of hacks and bugs documented when enemies are occluded or are reacting to something even when from the other side of the map. Obviously i don't know the fine print, but perhaps its ticrate related.

1 hour ago, -Carnage- said:

@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:

  Reveal hidden contents

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:

  Reveal hidden contents

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.



Try NUTS.wad for a stresstester. If you can hold up close to vanilla and a reasonable source port, than Doomity can shine :)

[-Carnage-]

Wow, it's been a few busy days of work on the new monster controller:

Spoiler

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.

 

[-Carnage-]

On 4/21/2021 at 3:08 PM, DavetheDoomguy said:

 

Is the Garbage Collector some kind of behind-the-scenes part of the port to get rid of some kind of unused data or something?

@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

[-Carnage-]

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:

Spoiler

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).

 

[omx32x]

so uh i disapeared again...

im having a lot of problems with my internet provider while also moving out of my apartment so im sorry for being so absent and i dont know if i will have time to keep helping with the testing 

sorry

[-Carnage-]

@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

 

[ddadd]

It's a little late, but I maybe can help with the play testing, and I did a version of wolf 3d in unity before if you're wanting to include that in the engine. It doesn't take anything from the og wolf 3d, but I made a map reader so I can create custom maps for it using paint. I even did a cool thing where I had two maps overlay to give it verticality. I can send you some pictures if you want me to. Here's a video of the concept from a while back 

 

[-Carnage-]

On 3/20/2022 at 10:28 PM, ddadd said:

It's a little late, but I maybe can help with the play testing, and I did a version of wolf 3d in unity before if you're wanting to include that in the engine. It doesn't take anything from the og wolf 3d, but I made a map reader so I can create custom maps for it using paint. I even did a cool thing where I had two maps overlay to give it verticality. I can send you some pictures if you want me to. Here's a video of the concept from a while back 

 

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

 

[-Carnage-]

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

[-Carnage-]

On 4/22/2021 at 4:34 PM, Redneckerz said:

Playtesting this a bit aswell, i have PMed you, @Carnage.

I run garbage can hardware, but even my junk (Geforce 6150!) could run upwards to 30 fps. But any map with relatively dense monster count tanks the hardware. Ironically, its not the graphical effects that do this, as dynamic colored lighting runs just fine. Its really in the beastiary logic.

 

NUTS.WAD will be a heavy metal workout for Doomity if it manages to process it.

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

[-Carnage-]

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.

Edited September 30, 2022 by -Carnage-

[CodeSmile]

Love it so far! :)

 

I've only ran into one small bug ... 

 

Yup, UI scale is bonkers. :)

And yes, that's a 32:9 monitor (5120x1440 px).

In the main menu, I can see "New Game" and half of "Options" so I can't even say if there's resolution options in there.

 

Next, I noticed it doesn't allow me to Alt+F4. I had to Alt+Tab out of it and right-click, then Close the window. That's essentially the same what Alt+F4 does, except I had to do it with the GUI (note: I did not force close it or use Task Manager and kill the process). Unless there's a specific, critical reason to block Alt+F4 I'd say enable it. MMOs and highly competitive eSport games I'm okay with blocking Alt+F4, they have reasons. But Doom? No.

 

Lastly, the cursor lock is not clever enough to unlock when a user Alt+Tabs or brings up the menu with ESC. I should be able to have a cursor, or not let the cursor go in hiding when the Doom window is in the background and I move the mouse over it. The Q3 character controller that was ported to Doom does that nicely, unlocking the cursor on ESC.

 

Anyway, I wish I had actual gameplay issues to report but alas, this is blocking me from playing.

 

Btw, does this have a source code repository somewhere? As a long-time Unity dev and Doom buff I'd love to have a look.

Edited October 9, 2022 by CodeSmile

[-Carnage-]

11 hours ago, CodeSmile said:

Love it so far! :)

 

I've only ran into one small bug ... 

 

Yup, UI scale is bonkers. :)

And yes, that's a 32:9 monitor (5120x1440 px).

Anyway, I wish I had actual gameplay issues to report but alas, this is blocking me from playing.

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