ACE Engine v2 - DOS Doom II [vanilla++?]

[kgsws]

16 hours ago, No-Man Baugh said:

A long time ago in the Things About Doom I Just Found Out thread; Linguica made an interesting discovery on the game's vanilla sprite fuzz behavior:

 

Will it be possible to integrate this alternate rendering of Specters and player invisibility as an option in ACE Doom?

It would be easy but since other source ports don't do that i really see no reason to have this "bugfix".
Also, i would not even call this a bug. Anyone who wrote this code was OK with the result and so changing it would alter possibly intended look.

And the difference is not so subtle and it is possible that the original author would compensate by changing colormap offset.

[No-Man Baugh]

26 minutes ago, kgsws said:

It would be easy but since other source ports don't do that i really see no reason to have this "bugfix".
Also, i would not even call this a bug. Anyone who wrote this code was OK with the result and so changing it would alter possibly intended look.

And the difference is not so subtle and it is possible that the original author would compensate by changing colormap offset.

 

I get that, I don't necessarily agree with linguica that this is a bug either, I just think it looks really nice and would be a nice option along side the other specter transparency options you seem to be adding (which btw those are also looking real nice in doom v1.9's renderer)

Edited April 16, 2023 by No-Man Baugh

[Darkcrafter07]

I also think the bugfix looks really cool.

[kgsws]

Still working on maps.

I have found even more bugs while making those.

 

This scene is a bit overdetailed. It dipped to 10FPS on Pentium1 @ 75MHz. I have removed shadowed part (bottom and top) and now it dips to 13 FPS and feels much better to play.

[Darkcrafter07]

It seems to be way more demanding than Quake.

[Gez]

Is that Black Mesa?

[Darkcrafter07]

kgsws in one of his videos was telling about a need to split the map horizontally for each 3d floor so no depth sorting issues occur and this is probably what kills the performance, it's like traversing bsp each time a split occurs if not more.

[kgsws]

8 minutes ago, Gez said:

Is that Black Mesa?

It kinda is.

 

21 minutes ago, Darkcrafter07 said:

It seems to be way more demanding than Quake.

Oh, is it? I do did not really play quake back then.

(i know it even used 3D models but to me it always looked kinda like like a downgrade compared to doom gameplay and sprite graphics)

 

7 minutes ago, Darkcrafter07 said:

kgsws in one of his videos was telling about a need to split the map horizontally for each 3d floor so no depth sorting issues occur and this is probably what kills the performance, it's like traversing bsp each time a split occurs if not more.

It does not traverse BSP multiple times but kinda yes.

Each different 3D plane height causes horizontal split. Two 3D planes with same height cause only one horizontal split. 3D floors often have top and bottom plane, that often gives you two planes.

BSP is traversed only once and all different heights are added to the list.

Normal level geometry does not have to be split, but sprites and midtextures do.

Also, sides of 3D floors count as kinda midtextures - those have to be split too.

And yes, this does kill performance. That is why removal of top and bottom shadow effect improved FPS.

 

I already have new sorting system figured out. This system does not need to split entire level horizontally.

But it changes quite a lot in rendering code and i don't feel like patching it into original code right now. It might be worth using in source ports though.

(and it is also capable of sorting sloped and translucent 3D floors, something which even GZDoom fails to do)

[spineapple tea]

That's gotta be an OSHA violation.

[Darkcrafter07]

10 minutes ago, kgsws said:

It kinda is.

 

Oh, is it? I do did not really play quake back then.

(i know it even used 3D models but to me it always looked kinda like like a downgrade compared to doom gameplay and sprite graphics)

Well it doesn't look as bad as Half-Life does using the same approach and this is the game where all ugliness of primitive modeling goes up. Half-Life 2 being a totally different story though.

 

Where Quake shines the most is performance of rendering on older machines. I've tested it on PCem, a 486 DX4-100MHz was really a slow poke but still was able to give you around 10 FPS at best, if this can be even considered to be playable. The least CPUs for this game are Pentium 60, 75, or AM5 x86 75 giving about 20 FPS on average, the best value system was Pentium 133 and that's still 320x200.

Of course I had an AMD computer with K5 running at 133MHz when I was a kid and Quake felt slower than Doom but still very much playable, it's somewhere in Pentium 60-75 league if it comes to Quake. On a funny side, running Half-Life Blue-Shift was a nightmare for that computer and it had to load up for a very long time coming through minutes of stuttered sounds but then I could even play it like 2-5 FPS in 640x400 and that's under Win 98 SE, 1MB video card and 16MB RAM, crazy times. If I only could find that computer again...

[OpenRift]

3 hours ago, kgsws said:

Still working on maps.

I have found even more bugs while making those.

 

This scene is a bit overdetailed. It dipped to 10FPS on Pentium1 @ 75MHz. I have removed shadowed part (bottom and top) and now it dips to 13 FPS and feels much better to play.

Honestly I would say target something like a 133Mhz CPU at the least, this kinda stuff is far too advanced for anything below that speed.

[viti95]

Some optimization could be done in rendering code, specially if the project targets the Pentium processor.

[Redneckerz]

6 hours ago, OpenRift said:

Honestly I would say target something like a 133Mhz CPU at the least, this kinda stuff is far too advanced for anything below that speed.

But would an AMD 5x86 at 133 Mhz work? :) (That's a 486-class processor)

[Darkcrafter07]

2 hours ago, Redneckerz said:

But would an AMD 5x86 at 133 Mhz work? :) (That's a 486-class processor)

There was even a model with the corresponding name, AMD X5-133, it should go 133MHz stock. CPU Galaxy overclocked it to 180MHz and then to 200MHz but it was a black magic, definitely.

[Redneckerz]

19 minutes ago, Darkcrafter07 said:

There was even a model with the corresponding name, AMD X5-133, it should go 133MHz stock. CPU Galaxy overclocked it to 180MHz and then to 200MHz but it was a black magic, definitely.

I know some terminals/thin clients where FastDoom (Or DOS gaming in general) would be very useful for. Boundless Viewpoint TC200 had a 133 Mhz 5X86.

[kgsws]

13 hours ago, spineapple tea said:

That's gotta be an OSHA violation.

Yeah, that's in original half-life map.

 

13 hours ago, Darkcrafter07 said:

Well it doesn't look as bad as Half-Life does using the same approach and this is the game where all ugliness of primitive modeling goes up. Half-Life 2 being a totally different story though.

Half life looks amazing compared to quake.

 

13 hours ago, Darkcrafter07 said:

Where Quake shines the most is performance of rendering on older machines. I've tested it on PCem, a 486 DX4-100MHz was really a slow poke but still was able to give you around 10 FPS at best, if this can be even considered to be playable. The least CPUs for this game are Pentium 60, 75, or AM5 x86 75 giving about 20 FPS on average, the best value system was Pentium 133 and that's still 320x200.

Quake runs well on penitum because of FPU. It was basically designed for pentium.

 

4 hours ago, viti95 said:

Some optimization could be done in rendering code, specially if the project targets the Pentium processor.

ACE Engine targets 486 CPU. It's just that from all hardware i have, P1@75MHz is easiest to setup.

I have already changed solid column and span rendering to use unrolled code - like heretic did.

(Though i have improved plane rendering at an expense of speed. You might know what i mean - i actually use x and y step separately.)

Sorting for 3D heights is a bit slow since it has to go trough every midtexture and sprite for horizontal split.

[viti95]

3 hours ago, kgsws said:

ACE Engine targets 486 CPU. It's just that from all hardware i have, P1@75MHz is easiest to setup.

I have already changed solid column and span rendering to use unrolled code - like heretic did.

(Though i have improved plane rendering at an expense of speed. You might know what i mean - i actually use x and y step separately.)

Sorting for 3D heights is a bit slow since it has to go trough every midtexture and sprite for horizontal split.

 

Have you been able to fully unroll span drawing in Mode Y? I'm trying to implement that for FastDoom but it's giving me lots of headaches 😅

[kgsws]

6 hours ago, viti95 said:

Have you been able to fully unroll span drawing in Mode Y? I'm trying to implement that for FastDoom but it's giving me lots of headaches 😅

I have abandoned mode Y right when i have decided to add transparency. Since then i use linear framebuffer, just like heretic does.

And i have found that it is faster on 486 CPU. Which is what i target anyway.

 

Though your question is interesting anyway. I might think about it. Not for ACE Engine, of course.

[Uni Musuotankarep]

On 4/27/2023 at 4:07 PM, kgsws said:

(and it is also capable of sorting sloped and translucent 3D floors, something which even GZDoom fails to do)

I really want to see that in action, pretty please?

[Darkcrafter07]

I thought something like if you could borrow some optimization from fast doom like vga13h mode or even better - VBA2.0, the vesa mode works twice as fast to me, but it's PCem.

On 4/28/2023 at 2:23 PM, kgsws said:

ACE Engine targets 486 CPU. It's just that from all hardware i have, P1@75MHz is easiest to setup.

I have already changed solid column and span rendering to use unrolled code - like heretic did.

(Though i have improved plane rendering at an expense of speed. You might know what i mean - i actually use x and y step separately.)

Sorting for 3D heights is a bit slow since it has to go trough every midtexture and sprite for horizontal split.

There was an interesting AMD controversy on their AM5x86-75 processor and it was marketed as a "P75" counterpart but it was still an enhanced 486 with a slow FPU that made Quake running about 25% slower to my observations. But in Doom, thanks to the clock speed of 100 MHz + it was much faster than Pentium at 75MHz. Maybe processors like these were made for Doom. AM5x86-75+ was running at even higher clock speeds like 133MHz, 150MHz and sometimes overclocked to 160MHz, what served these CPUs a nice job.

So in Doom, AM5x86 AMD-K5 and Pentium had the same performance clock to clock and maybe AMD were about 2% faster.

What's about my opinion on Quake. I can't remember the framerates of my old machine I abandoned finally in the very beginning of 2008 but it was definitely playble, whether it was AM5x86 or K5 but according to my recent dig into PCem, the minimum system I felt playing Quake comfortably, smooth and without lags 320x200 - Intel Pentium 200MHz or AMD K6-166MHz. All the slower processors had such slowdowns with FPS dipping lower than 20 in crowded and detailed areas that any modern hardware reviewer would say are total unplayable garbage, so please don't give up on your system "P75" giving such bad framerates, it's not your fault. It's simply that even Doom needs at least an 486DX4-120Mhz to play nicely.

Edited June 2, 2023 by Darkcrafter07
Not AM5x86 but AMD-K5!

[kgsws]

On 5/11/2023 at 8:48 PM, Darkcrafter07 said:

don't give up on your system "P75" giving such bad framerates, it's not your fault. It's simply that even Doom needs at least an 486DX4-120Mhz to play nicely.

There are things that i could probably optimise more with different approach but yes, Doom on it's own is quite slow anyway.

I guess DOS gaming was slow-ish but i just don't remember.

 

 

Update:

I think demo maps are mostly complete now! I have indeed even found more bugs and that's one of the reasons i made demo maps anyway.

Now i just want to add a little details ... and enemies of course. Those maps are full of "scripting" demos but i think adding enemies is a good idea too.

 

[OpenRift]

5 minutes ago, kgsws said:

CUM

[Biz!]

27 minutes ago, kgsws said:

There are things that i could probably optimise more with different approach but yes, Doom on it's own is quite slow anyway.

I guess DOS gaming was slow-ish but i just don't remember.

 

 

Update:

I think demo maps are mostly complete now! I have indeed even found more bugs and that's one of the reasons i made demo maps anyway.

Now i just want to add a little details ... and enemies of course. Those maps are full of "scripting" demos but i think adding enemies is a good idea too.

 

Half-Life in Doom is looking awesome.

[Uni Musuotankarep]

On 5/12/2023 at 2:49 PM, kgsws said:

Due to this image, I am interested in a Half-Life TC with a special source port to run it, because of the changes to collision and rendering code to allow for horizontally moving and rotating sectors that aren't polyobjects, as well as slopes, sector over sector effects, and decals that can be put on any surface. But if not, then I understand.

[dasho]

18 minutes ago, Uni Musuotankarep said:

Due to this image, I am interested in a Half-Life TC with a special source port to run it, because of the changes to collision and rendering code to allow for horizontally moving and rotating sectors that aren't polyobjects, as well as slopes, sector over sector effects, and decals that can be put on any surface. But if not, then I understand.

 

I hear Valve made something along these lines

[kgsws]

16 hours ago, Uni Musuotankarep said:

Due to this image, I am interested in a Half-Life TC with a special source port to run it, because of the changes to collision and rendering code to allow for horizontally moving and rotating sectors that aren't polyobjects, as well as slopes, sector over sector effects, and decals that can be put on any surface. But if not, then I understand.

That would be something like build engine. Yeah, i think in rendering features of build engine are far superior to doom. It has other issues though.

I would love to have engine with such features, but that would not be compatible with any existing doom port anymore.

But how many people would appreciate engine like that, with software rendering and DOS support anyways? It would not even be for doomworld anymore ... unless it could load Doom WADs.

Offtopic:

Spoiler

!!! This is NOT ACE Engine. !!!

This is my experiment with build-like engine but in OpenGL.

Like build engine, it does not use BSP - map can dynamically change.

Also, like build engine, it allows non-euclidean geometry - two rooms at the same XYZ location.

 

 

 

 

Now, here's ACE Engine update:

 

One of last features i have added. Mod authors can now choose automap colors. Locked doors have extra customizable color. Just like in ZDoom, using LOCKDEFS.

I think it's basically done so i hope i can make V2 release next week.

Edited June 2, 2023 by kgsws

[LuciferSam86]

With low resolution I could imagine a liminal / backrooms wad with some 3D floors  and decorate  tricks . 

Edited June 3, 2023 by LuciferSam86

[Redneckerz]

On 6/2/2023 at 5:12 PM, kgsws said:

One of last features i have added. Mod authors can now choose automap colors. Locked doors have extra customizable color. Just like in ZDoom, using LOCKDEFS.

I think it's basically done so i hope i can make V2 release next week.

Very much please yes. If you do release, please make a post that highlights what the current iteration does of ACE Engine because i reckon it is much changed from how the Doom Wiki is now covering it :P

[Noiser]

I'm seriously thinking of making something special for this. The engine looks incredilble!

Edited June 3, 2023 by Noiser

[Dexiaz]

17 hours ago, Noiser said:

I'm seriously thinking of making something special for this. The engine looks incredilble!

 

Doom 4 Vanilla : ACE of Spades? :>

 

Well, I'll definitely start reworking my Boiled Doom for DOS.

 

But this engine allows something more...extraordinary.