Doom Frame rates on various systems?

[8bitbubsy]

Originally Posted by Karlos

No, it's mostly true. What matters is how quickly you can write to the video ram. And for the swipe effect at the start and end of a level, how quickly you can read ir too.

And how quickly you can read/write to VRAM also depends on the video card itself. It's not like every video card had 0-waitstate video memory and full 16-bit bandwidth-optimized read/writes. So yes, the graphics card does matter, even for DOOM.

Try something like a Cirrus Logic GD5401, it will be a big bottleneck!

[Bruce Abbott]

Originally Posted by Mad-Matt

Just to check, does 2-steps down window size mean from full window or fullscreen (no hud) as id forgot about nohud before pressing down size twice.

I suspected that. No, it's 2 steps down from fullscreen (no HUD), or 1 step down from HUD with no border.

Sadly the window size has no effect on C2P, which always does the whole screen. Not updating the border (which never changes) and HUD (which could be updated at a much lower rate) could result in a significant speed increase, especially in smaller window sizes.

A big speedup could also be achieved by halving the vertical resolution and using the Copper to line-double the window, though that is getting into the realm of 'not really Doom' console ports etc., which is a bit of a cheat.

[Karlos]

C2P doesn't have to update the whole screen. The only requirement (for efficiency) is that the destination is that the destination spans are 32 bit aligned. This means limiting the number if smaller size options, e.g. 320, 256, 192.

You could (should) the pre convert the background texture to planar and just overdraw (via C2P) what changes. You could also convert the HUD elements to planar if you wanted. This isn't cheating if the core rendering and game logic are unchanged. It's just doing a good job.

In AB3D2, elements that can stay planar on AGA (border, counter glyphs, small screen text overlay) are all plotted using planar routines. C2P is only used for what is in the game display.

[Mad-Matt]

ok for the sake of accuracy and a comparable result I have rerun timedemo demo3 using the original doom (3 episode). With Sound , No music. 040/25 Voodoo3 RTG, 1 step down with hud. Quite a drop in performance for one window size up :S

timed 3863 gametics in 9764 realtics (13.84 fps)
[ Show youtube player ]

Now bring on the 030 and 060 runs to compare!

[Karlos]

Can you use bustest or similar to benchmark your vram access? Some RTG solutions have slower write access than AGA.

[Lunda]

DoomAttack CD32 AGA, 030 70.9MHz. Using Doom 1.9 (2134 gameticks standard benchmark settings) Demo3 No music: 17.1 fps

[Karlos]

Originally Posted by Lunda

DoomAttack CD32 AGA, 030 70.9MHz. Using Doom 1.9 (2134 gameticks standard benchmark settings) Demo3 No music: 17.1 fps

Killing it.

[Mad-Matt]

I'm not sure if I'm operating it right. I just gave bustest the start addr of mediator gfx memory.

[Karlos]

Originally Posted by Mad-Matt

I'm not sure if I'm operating it right. I just gave bustest the start addr of mediator gfx memory.

About 6.7MB/s for long writes, comparable to AGA. I recall my BVision hitting 14MB/s on my 040/25 and higher speeds reported by 060 users.

See how AGA lores NTSC with C2P fares.

[Mad-Matt]

I do have a BVision boxed up. Too much hassle to swap it over atm

So same settings using DoomAttack 040/25 AGA NTSC 320x200. C2P_040+ With Sound No Music
timed 3863 gametics in 11055 realtics (12.23 fps)

BlizzPPC 603/175 using AdoomWOS AGA NTSC 320x200 ChunkyPPC-C2P Sound, No Music)
timed 3863 gametics in 4324 realtics (31.27 fps)

[paraj]

B1260/50MHz 23.3fps (DoomAttack / 1.9s shareware Doom / NTSC lores / 040+ C2P)

[Lunda]

DoomAttack Amiga 4000 Z3660 060 100MHz(standard benchmark settings 2134 gameticks):

AGA 34.3fps
RTG 46.9fps

[Bruce Abbott]

386SX-16 with 16MB RAM, Trident TVGA8900CL-C VGA card (manufactured 10/94) with 1MB RAM, all jumpers set to 16-bit mode, Doom V1.9 shareware, no sound:-

2134 gametics, 55811 realtics, 1.34 fps.

[Mad-Matt]

Doomattack looses sync right away with Shareware doom Demo3 (1.9S) but does use 2134 tics (vs 3863 ticks with Doom 1.9 /UltimateDoom 1.9). I'm pretty sure Demo3 was desyncing in the full wads as well at the end with the bouncing skulls.

So this time I am testing with 1.9S, Adoom 1.4.1. 1 notch down window with hud., High Detail.
Adoom -timedemo demo3 -forcedemo -nomusic -nosound -mmu

A1200 Blizzard PPC 68040/25, AmigaOS 3.9, Mediator
AGA 320x200 NTSC 2134 gametics, 6895 realtics (10.8 fps) (C2P Time 22673 us/frame)
EHB 320x200 NTSC 2134 gametics , 7609 realtics (9.8 fps) (C2P Time 32077 us/frame)

Adoom -timedemo demo3 -forcedemo -nomusic -nosound -mmu -rtg
Voodoo3 (P96) 320x200 2134 gametics , 6047 realtics (12.4 fps) (WPA8 time 10685 us/frame)
(with -DirectCGX 6277 tics 11.9 fps) (Lockbitmap time 346 us/frame)

AGA 320x200 NTSC 2134 gametics, 6806 realtics (11.0 fps) (WPA8 Time 20973 us/frame) (With BlazeWCP, using RTG on an AGA screen results in a single buffered screen with some slight gfx glitches)

---------------------------------------------------------------

EDIT: Turns out if I delete the config file and let it rebuild when I change wad file, the desyncs are no longer an issue .. who knew. Shareware now working properly so now its an Adoom vs Doomattack post.

DoomAttack C2P_040+, NoSound, NoMusic, MMU1+2

AGA 320x200 2134 gametics, 6580 realtics = 11.35 fps
Voodoo3 320x200 2134 gametics, 5833 realtics = 12.80 fps

[ Show youtube player ]