DOOM on atari st

[GokMasE]

Considering the recent progress I can't wait until the next demo binary

It all looks stunning!

[dml]

Considering the recent progress I can't wait until the next demo binary

It all looks stunning!

Thanks. I sent a recent test build to Eero to debug something but it's still running a bit slow and I decided not to post. I've been looking at the disassembly and preparing to rewrite the important bits in 68k. The compiler has done an ok job in some places but other bits look quite bad so a rewrite should help.

Fortunately there isn't that much code in total so it's not a huge job.

[Eero Tamminen]

It all looks stunning!

Looking at the binary Douglas sent, that's indeed the case.

The flicker from color dither "interlacing" is a bit distracting though, at least on my LCD screen, so having in source support also for non-flicker version would be nice, especially if disabling interlacing would increase speed a bit...

[dml]

The flicker from color dither "interlacing" is a bit distracting though, at least on my LCD screen, so having in source support also for non-flicker version would be nice, especially if disabling interlacing would increase speed a bit...

I spent some time today comparing output in different emulators and a real STE. If you can get Hatari or STeem to output a reasonably precise, synchronized 50 or 60hz the effect is essentially invisible and closely matches output on a real machine.

However by default, I get bad flicker in both Hatari and STeem in both windowed mode and fullscreen, but it varies. I was able to get best results with STeem in fullscreen mode + draw every frame + 'screen flip' config. Changing these settings brings the flicker back.

I think these problems have a lot to do with video drivers and reduced degree of control over certain types of display on the host machine.

If you can get an accurate refresh it shouldn't be visible though. If frames are being dropped or a blit is being used which is not synchronized then it goes bad. It just seems to take quite a bit of fiddling around with the emulator configs to deal with it.

[EDIT]

BTW I think one of the things that kills the effect even in fullscreen is due to the host display not actually changing refresh rate, and some sort of time stretching/aliasing thing happens instead. e.g. field A is displayed for 1 frame, and field B is displayed for 2 frames, to fill an 85Hz (or whatever) refresh to 50Hz. It averages to the right duration but individual frames persist too long and the eye catches it. Since its not always possible to convince the host display to drop as low as 50 or 60hz, the effect isn't easy to emulate correctly. And the only way to be sure it's working is to have a working reference to compare it with visually. Not ideal!

[Eero Tamminen]

That might explain it. The flicker seems more pronounced at middle of emulated ST screen and the place where it's visible, moves up and down a bit, so maybe SDL Vsync() isn't used or working properly.

Btw. Johan Klockars' Mgif graphics program had this special ST-high (72Hz) mode where it switched between 3 differently error diffusion dithered monochrome screens to create (a very good) impression of grayscale. That had exactly the same problem although with monochrome dither the luminance difference was of course even larger and 72/3Hz < 60/2Hz i.e. even more flickery.

[dml]

Btw. Johan Klockars' Mgif graphics program had this special ST-high (72Hz) mode where it switched between 3 differently error diffusion dithered monochrome screens to create (a very good) impression of grayscale. That had exactly the same problem although with monochrome dither the luminance difference was of course even larger and 72/3Hz < 60/2Hz i.e. even more flickery.

I always wondered how multi-field images would look in monochrome. I didn't realize he tried it out.

[Eero Tamminen]

I always wondered how multi-field images would look in monochrome. I didn't realize he tried it out.

I think the code for that mode came originally from someone else, but it worked very well in Mgif. I used it even for pre-viewing PovRay raytracing results (8Mhz ST + monochrome monitor might not have been best choice for raytracing though ). Mgif could also save such images and there was a small viewer for them.

[dml]

I could actually prepare 2 sets of graphics - one limits flicker for emulators, the other has better colour reproduction for the real machine. The palette and translation map are loaded at runtime, and the only other thing affected is the texture files so it's easy to have it load one or the other.

The flicker arises mainly from luma divergence in the two fields, when viewing with skipped (or duplicated) frames. I have set up different penalties for luma and chroma divergence and fiddling with these has quite a big impact on the result. I had tuned it to look good assuming the refresh matches real hardware but it could be tuned separately to limit flicker under 'emulated refresh'. There will be fewer pseduocolours in the output though...

[Eero Tamminen]

If it requires different set of (large) data files, I don't think it's worth the trouble, at least if there isn't also noticeable speed increase on real HW. IMHO programs should do emulator specific stuff only for better debuggability.

[dml]

If it requires different set of (large) data files, I don't think it's worth the trouble, at least if there isn't also noticeable speed increase on real HW. IMHO programs should do emulator specific stuff only for better debuggability.

There's no influence on performance, unless dual-field rendering is dropped for single-field dither-only. That does save some c2p time.


Have made a few more changes today which optimize out (remove) 4 of the 10 multiplies per visplane scanline, improving floor and ceiling performance. It costs more memory/table space so it's a build-time switch. It may be possible to remove one more if pushed. The rest probably can't be removed without destroying render quality.

Each horizontal span has one additional multiply - but this pays for itself when the floor gets fractured into funny shapes by wall contours as scanline setup is done only once for all spans on that line.

[mikro]

I've debugged those issues in binaries that Douglas has built, and he's using Vincent's gcc 4.x cross-compiler. Mainly it's a stripping issue, which I've discussed shortly on the mint-mailing list.

Having too many symbols is less of a problem than having too few. If there are too many symbols, you can see that from callgraph.

Right, now I remember. It's partially my fault, too because a) I was the one who had suggested the "-x" switch to Vincent and b) I haven't done the size tests properly (trying various switches with --traditional-format instead of keeping it in a.out).

If I wont forget I can take a look into this again but I'm pretty sure if file size using the switches you proposed in the mintlist thread wont grow too much, Vincent will be open to include them instead of "-x".

[dml]

I have begun converting some of the more important C areas into 68k, starting with the floor drawing. This seemed like a good place to start because it's a standalone block of code and complex enough to study the compiler's own codegen (which can be very strange!).

This area doesn't contribute much to an average scene but causes bad slowdown when steps are visible.

The per-scanline, per-span overheads have since been reduced by 50%. Averaging 4000 frames this was just 5% of total time so that's a small 2.5% saving for most views. Rendering sequences of steps or fragmented wall contours however (i.e. worst case) shows a much bigger gain as there are many more, shorter spans to deal with. The savings increase with window height also.

So after the change it's a little faster on average but maintains speed much better at the worst parts of the map.


When I return to it I'll look at the raycasting bit.

[dml]

Eero - I'm going to replace some of the GCC inline asm with VASM sourcefiles so native GCC 2.9.5 might start coping with it. I think there's only one sourcefile with funny syntax anyway - the rest is compliant. Should be easy to fix.

[alexh]

I don't know if you would be interested but someone just posted the Source code for DoomAttack, the fastest port of Doom "heavily optimised" for 68020+ based Amiga's.

http://aminet.net/package/game/shoot/DoomAttack_src

I'm sure that BadMood is probably already much more advanced than any of the optimisations here but you never know.

[dml]

Hi,

I don't know if you would be interested but someone just posted the Source code for DoomAttack, the fastest port of Doom "heavily optimised" for 68020+ based Amiga's.

http://aminet.net/package/game/shoot/DoomAttack_src

I'm sure that BadMood is probably already much more advanced than any of the optimisations here but you never know.

I have this source and did look through it recently. It's more of a direct conversion of Id's C code than BM, which was derived through DVIEW and other routes. They have concentrated mainly on the drawing stuff (r_???.c) and the conversion is reasonably literal. I didn't notice changes to algorithms from the C version.

There is quite a bit of 68k for the rendering side but I don't think there were any significant game-side optimizations when I last looked. I'll diff the code again to make sure that's the case. Game-side optimizations are interesting because there are lots of problems in that area.

[dml]

Bit of an update on this.

Last night I had 2 of the 4 big areas of C code completely converted to 68k (there were 6 areas in total to begin with, but 2 were already in 68k - i.e. horizontal and vertical span drawing and there were small pieces of 68k inside other areas of the C code).

Used cycles:
38.47% _commit_raycontacts (+ contains vertical pixel drawing)
26.78% _c2pzoom_96_ccpairsq_dualfield (68k only)
14.58% _raycast_world_68k (C version + asm innerloop was 21%)
12.20% _render_drawplanes_68k (C version + asm horizontal pixels was 17%)
7.62% _scanconvert_visplanes

The routines in bold have been completely redone in 68k and reasonably optimized. There are still C reference versions of everything kept in the project but the 68k versions are now preferred.

The main raycast_world routine already had the innermost loop in 68k and that remains mostly as it was, but the outer loop responsible for restarting rays has been shrunk and much improved. This has saved about 25% of all time spent in raycasting, especially when viewing across height changes. There are still 3 or 4 obvious optimizations which can be made here but further savings probably will be small.

commit_raycontacts is the biggest C function and will be quite a lot of effort to rewrite. It's responsible for turning ray strikes into surfaces, and for generating floor/ceiling spans. It looks like the most expensive area - although it hides calls to generated code for drawing vertical columns. I've been trying to hack up a profiling solution to this so the cost of the column drawing shows separately but haven't been successful yet - probably requires an extra symbol to be loaded/defined at the profiler post-processing stage (but I'm not completely sure yet).

The current *average* performance is about 7.8fps for a 96x pixel render. The *max* is around 12fps when close to walls. The fps is mainly limited now by the big remaining C routine and the dual-field c2p pass. I have changed the map, camera and some other things since last measuring fps, so the figures are not comparable (the scene is more expensive than it was). So speed has improved, but rise in scene cost has nearly matched it. I won't be changing the scene again until the 68k bits are complete.

[bullis1]

That's seriously impressive performance. I never thought you'd break a 7fps average or so with multiple flat heights and crypto-chrome intact.

[dml]

That's seriously impressive performance. I never thought you'd break a 7fps average or so with multiple flat heights and crypto-chrome intact.

I think it's about half-way towards being optimized now. I'll finish unrolling the raycast code later this evening to see if it can be brought closer to 10% CPU and maybe 8fps. I doubt it will go very much below ~12% though with the scheme I have used.

[calimero]

I don't know if you would be interested but someone just posted the Source code for DoomAttack, the fastest port of Doom "heavily optimised" for 68020+ based Amiga's.

http://aminet.net/package/game/shoot/DoomAttack_src

I'm sure that BadMood is probably already much more advanced than any of the optimisations here but you never know.

interesting. I found on youtube video of DoomAttack posted by NovaCoder (same guy who made Quake 2 port for Amiga!) and some other videos from 386 PC.

Blizzard 030 Mk4 @ 50Mhz, 64mb RAM:
- http://www.youtube.com/watch?v=tUbEwkWr4E4

PC 386DX 40MHz
- http://www.youtube.com/watch?v=_mLFSsXF2TQ (at 2:10)

PC 386SX 16MHz
- http://www.youtube.com/watch?v=qFG6dqQZzbU


and I just watch BadMood on 16MHz+DSP Falcon: I would say it is un pair with 40MHz machines (of course, BadMood is not complete game but... )
and I would say that Amiga 40MHz is faster than a PC!!!

it would be nice to see timedemo (or how it is called for Doom ) from different machines!

[Eero Tamminen]

and I just watch BadMood on 16MHz+DSP Falcon: I would say it is un pair with 40MHz machines (of course, BadMood is not complete game but... )

I don't think BadMood is missing any game features which would effect speed significantly. In its current state it's fully playable.

However, BadMood compiled with most optimal build options (used in Douglas' videos) isn't compatible with Doom timedemo's (and wouldn't with network play of other Doom implementations) because its internal game clock runs at lower frequency i.e. some game activities (monster AI decisions etc) aren't as accurate. Some other things are also simplified / short-circuited more (like sound propagation for monster wakeup). In general, the enemies in BadMood are slightly dumber / less of challenging than in PC Doom.

[Eero Tamminen]

commit_raycontacts is the biggest C function and will be quite a lot of effort to rewrite. It's responsible for turning ray strikes into surfaces, and for generating floor/ceiling spans. It looks like the most expensive area - although it hides calls to generated code for drawing vertical columns. I've been trying to hack up a profiling solution to this so the cost of the column drawing shows separately but haven't been successful yet - probably requires an extra symbol to be loaded/defined at the profiler post-processing stage (but I'm not completely sure yet).

You could create a file listing generated code call addresses and symbols at run-time, when that code is generated at startup. If those addresses are absolute, you give that file to post-processor with the "-a" option (file with a list of TEXT section offsets is given with "-r" option).

Only downside of not having the symbols available at profiling time is that profiler won't collect caller information for them, i.e. you don't see them separately in the callgraphs produced by the post-processor. You will see them in the flat profiles though.

If you want also callgraphs (+ see those symbols at run-time in debugger), you need to load them to the debugger before starting profiling. Because debugger currently supports having only single symbols file information in memory, you would need save generated code addresses as TEXT relative and append them to the program symbols list before loading that.

[dml]

In general, the enemies in BadMood are slightly dumber / less of challenging than in PC Doom.

In fact they are less challenging at distance, but more challenging up-close, than PC doom. Although it's still subject to tuning.

[dml]

You could create a file listing generated code call addresses and symbols at run-time, when that code is generated at startup. If those addresses are absolute, you give that file to post-processor with the "-a" option (file with a list of TEXT section offsets is given with "-r" option).

I managed to get a fake profile analysis by pasting a label at the first address of the generated code, but I think the result was incorrect because there are many functions of the same type beyond that address, and I think only the first block showed as a function with the fake symbol - the others got absorbed somewhere else.

So yes - it would probably have to be done by writing a symbol file at runtime.

[dml]

Got the 3rd large area of C code partly converted to 68k last night and seems to be working, although the pieces which generate floor areas are still missing. Have temporarily run out of CPU registers (luckily, managed not to run out until all the wall surfaces were working!) but some reshuffling should fix that problem and allow it to get finished. May have something complete and working this evening or over the weekend.

[Scarlettkitten]

Wow, I can't wait