VOGONS


Reply 360 of 571, by rasz_pl

User metadata
Rank Oldbie
Rank
Oldbie
DEAT wrote on 2021-12-01, 01:47:

Any area that has a lot of moving platforms (eg. E2M3) destroys the FPS when it is in the player line-of-sight, as the CPU needs to calculate all of the platforms - this was on my 386SX-40. Any situation for where there's a lot of active monster AI (eg. HR2FINAL.WAD MAP32) will also destroy the FPS, but that's an unavoidable situation - I can still see sub-30 FPS on a 500Mhz Coppermine Pentium III with that specific map, but I use that map with a tool-assisted UV-max demo purely for benchmarking.

those are interesting cases that deserve some profiling - it might very well be a case of suboptimal algorithm doing something stupid.

Reply 361 of 571, by ViTi95

User metadata
Rank Member
Rank
Member

It's possible to profile FastDoom but only with Pentium processors (and later models). I'll try that same setup that uses @DEAT, it looks a very extreme test but will show perfectly what's the culprit.

Reply 362 of 571, by trixster

User metadata
Rank Newbie
Rank
Newbie

I swapped out my Mach64 on this Amiga Bridgeboard pc for a Tseng ET4000AX and saw an increase in framerates 😀

Fdoom 8.8.8 timedemo demo3, one level of green border, ET4000AX in brackets
-Nosound -nomouse -ram

Fdoom 14.227 (16.262)
Fdoomvbr 14.493 (15.334)
Fdoom13h 13.389 (14.352)

Sadly vbd is still a no-go

I’m impressed that this TI486SXLC 50mhz processor (basically a jumped up 386! but with the 486 instruction set and 8K L1) still has more to give with a change of video card!

So, is there an ISA card out there that might provide even more fps than the Mach64 and the ET4000AX?!

Last edited by trixster on 2021-12-06, 22:07. Edited 2 times in total.

Reply 363 of 571, by GigAHerZ

User metadata
Rank Oldbie
Rank
Oldbie
trixster wrote on 2021-12-06, 18:32:

So, is there an ISA card out there that might provide even more fps than the Mach64 and the ET4000AX?!

I have CL-GD5434 based ISA VGA card on my 386DX-40. Do you want me to test something out with it?

"640K ought to be enough for anybody." - And i intend to get every last bit out of it even after loading every damn driver!

Reply 365 of 571, by mrau

User metadata
Rank Oldbie
Rank
Oldbie
ViTi95 wrote on 2021-12-01, 13:35:

It's possible to profile FastDoom but only with Pentium processors (and later models).

is this due to time stamp counter? there was no software profiling before that?

Reply 366 of 571, by ViTi95

User metadata
Rank Member
Rank
Member
trixster wrote on 2021-12-06, 18:32:
I swapped out my Mach64 on this Amiga Bridgeboard pc for a Tseng ET4000AX and saw an increase in framerates :) […]
Show full quote

I swapped out my Mach64 on this Amiga Bridgeboard pc for a Tseng ET4000AX and saw an increase in framerates 😀

Fdoom 8.8.8 timedemo demo3, one level of green border, ET4000AX in brackets
-Nosound -nomouse -ram

Fdoom 14.227 (16.262)
Fdoomvbr 14.493 (15.334)
Fdoom13h 13.389 (14.352)

Sadly vbd is still a no-go

I’m impressed that this TI486SXLC 50mhz processor (basically a jumped up 386! but with the 486 instruction set and 8K L1) still has more to give with a change of video card!

So, is there an ISA card out there that might provide even more fps than the Mach64 and the ET4000AX?!

That cpu is very limited due to the 16-bit RAM and slow 25 MHz bus, that's why the fdoom executable (mode Y) is faster than those that use the backbuffer (vbr and 13h). The direct rendering VESA mode requires a Linear FrameBuffer, and I have still to see an ISA videocard that supports that, that's why it doesn't work on ISA cards (only VLB onwards, maybe EISA or MCA cards could support it). In my testings the Cirrus Logic are the fastest ones, specially the GD5429.

mrau wrote on 2021-12-07, 11:15:
ViTi95 wrote on 2021-12-01, 13:35:

It's possible to profile FastDoom but only with Pentium processors (and later models).

is this due to time stamp counter? there was no software profiling before that?

Yes, OpenWatcom requires TSC support for profiling.
https://users.pja.edu.pl/~jms/qnx/help/watcom … popts.html#SWet

Reply 367 of 571, by 386SX

User metadata
Rank l33t
Rank
l33t

A question, considering the latest ISA cards already had the BitBLT engines and quite optimized for Win GUI where there's a huge improvement using those early accelerators, couldn't that engine be used somehow to offload some of the Doom gfx rendering calculations?

Reply 368 of 571, by BitWrangler

User metadata
Rank l33t
Rank
l33t

Not really, Amiga programmers doing 3D had to work around the blitter rather than with it, it's great for fast scrolling and sprites, flatworld games, but not 3D.

Unicorn herding operations are proceeding, but all the totes of hens teeth and barrels of rocking horse poop give them plenty of hiding spots.

Reply 371 of 571, by 386SX

User metadata
Rank l33t
Rank
l33t

Sure I would have no problem calling Doom a 3D game cause the whole 2.5D or 3D discussion has always been more about the limitations than the real user experience that was indeed a tridimensional enviroment once those limitations were accepted.
I suppose that if every game console having all type of 2D oriented accelerations in hardware back in the middle 90's, couldn't run the real version of Doom even with all sort of tricks to get a decent frame rate (probably only the PlayStation version was good enough and still it had the "light" console version maps), probably no 2D functions I imagine might help during the code but the idea of using the BitBLT engine that did miracles in the Win GUI seems like a good possibility to find some units that might help to run what has been an heavy game indeed.

Reply 372 of 571, by appiah4

User metadata
Rank l33t++
Rank
l33t++
xcomcmdr wrote on 2021-12-08, 09:46:

I would more faithfully describe Doom as "3D with some limitations"

Not really.. To make my point, you could play Doom as 2D as a topdown shooter on the automap and it would function 100% fine. It's a 2D game rendered in 2.5D using Z values, but verticality has no bearing on game play other than determining whether you can scale platforms. The game's entire AI is 2D based, maps are 2D data, even collision works in 2D ie. you can't stand under a cocademon for example.

Now, if you will excuse all of this and call Doom "3D" we have to go back and recategorize A LOT of games as 3D. Grid based dungeon crawlers, for example - are they 3D? Calling Doom 3D does disservice to a lot of games that preceded it, and did real 3D so much better. Doom is great, don't get me wrong. But it's not 3D. It is a very immersive illusion of 3D for sure, but it's still more or less Wayout (1982) for the Atari 8-bit on steroids..

Retronautics: A digital gallery of my retro computers, hardware and projects.

Reply 374 of 571, by xcomcmdr

User metadata
Rank Oldbie
Rank
Oldbie
appiah4 wrote on 2021-12-08, 10:40:

verticality has no bearing on game play other than determining whether you can scale platforms.

Flying monsters and projectiles, how do they work if not because of the Z axis ?

As Romero said, it's 3D.

wrote:

even collision works in 2D ie. you can't stand under a cocademon for example.

Infinite height for collision detection does not equal to no height variance for flying objects.

=appiah4 wrote on 2021-12-08, 10:40:

Calling Doom 3D does disservice to a lot of games that preceded it, and did real 3D so much better. Doom is great, don't get me wrong. But it's not 3D. It is a very immersive illusion of 3D for sure, but it's still more or less Wayout (1982) for the Atari 8-bit on steroids..

I called it 3D with some limitations. I should have used bold.

Reply 375 of 571, by 386SX

User metadata
Rank l33t
Rank
l33t

I suppose we can call it a 3D game from the final user experience point of view but calculated in a easier way for the time it's been released. The same game rendered with polygons and textures I suppose would have not been possible in that year, no matter how optimized the code might have been. But it's true that polygon based enviroments into msdos games already existed like Stunts or Test Drive III or LHX games were impressive for THAT specific reason, not to mention (at least for Stunts) the "realistic" physic realized in the game.

Reply 376 of 571, by dr_st

User metadata
Rank l33t
Rank
l33t
appiah4 wrote on 2021-12-08, 10:40:

verticality has no bearing on game play other than determining whether you can scale platforms

That's already something. And there is also moving vertical crushers which damage actors if the ceiling-floor difference is smaller than the actor's height, but not otherwise.

appiah4 wrote on 2021-12-08, 10:40:

even collision works in 2D ie. you can't stand under a cocademon for example.

But a Cacodemon's fireball can hit the wall above your head and not damage you. These are just a couple of examples, there are more.

This subject has been chewed to death a million of times already. Doom is a game where some aspects of the engine are 2D and other aspects are 3D. This cannot be denied as the source code is there to prove it. Thus, the discussion on whether "a sufficient critical mass" is there to call the game "3D" or "2.5D" or "2.666D" is completely subjective, and, IMO, pointless.

https://cloakedthargoid.wordpress.com/ - Random content on hardware, software, games and toys

Reply 377 of 571, by GigAHerZ

User metadata
Rank Oldbie
Rank
Oldbie
leileilol wrote on 2021-12-08, 11:06:

Please, as leileilol has posted, it's been settled.
Though, i would love to identify Doom as 2.666D 😁

This is FastDoom project's thread. That project is amazing! But what are we discussing here?

"640K ought to be enough for anybody." - And i intend to get every last bit out of it even after loading every damn driver!

Reply 379 of 571, by 0x90

User metadata
Rank Newbie
Rank
Newbie

I converted (hand-conveted since I couldn't get some kind of automated tasm2nasm tool I found to work properly) linear.asm from TASM to NASM 2.1x.x compatible a few months ago, to cross-compile a quick hacky little Doom port for testing stuff w/o requiring any tools which don't run natively on my "work" laptop.

I could attempt to do the same for the other ASM files in this project. Interested? Or is TASM preferable for this project and the maintainers? Note that even the newest versions of NASM are still available for DOS so the ability to also build it on DOS wouldn't be lost.

For the same reason (easier cross-compiles) I think porting the SETUP program from Borland to 16-bit Watcom C would be good, but not sure if I personally want to attempt that...

edit: also, NASM can generate object files which are compatible with GNU tools (djgpp) which I don't think TASM can do, yet could be useful since gcc can optimize better than Open Watcom even for older CPUs (though certainly it can also be significantly slower and more memory hungry while compiling, if you're compiling on target hardware)