Falcon Doom

All about games on the Falcon, TT & clones

Moderators: Mug UK, moondog/.tSCc., [ProToS], lp, Moderator Team

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Tue Jan 29, 2013 4:03 pm

nativ wrote:Hi,
I have a 68882 16 in my falcon with a 40 ready to fit when I get some desk space!
Can your FPU code be enabled on the 040 and 060?


If I do go near the FPU for this, I will be avoiding 881/2-only opcodes like a bad flu. The 040 and 060 should be happy.

However I don't think a BadMood-based Doom will be the ideal 040/060 Doom. It's really aimed at a base machine as much as possible, and this is why I'm on the fence a bit re: the FPU...

For an 060 especially, using the DSP in this way is a bit of a negative performance effect. A more classic port of the original code (PMDOOM?) is probably a much better choice.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Tue Jan 29, 2013 5:39 pm

One of the things I managed to do last night is rework the "SSector->Seg" (i.e. walls) processing loop completely into separate passes. BM3.07 implemented the scene BSP walk as one big monolithic unit which switches duties constantly between figuring out what's visible, what to draw, dealing with walls, retrieving stuff from the DSP, drawing stuff etc. etc. This simplified matters when comparing with the Doom engine, but it's not optimal for performance on a CPU with a tiny cache. The constant switching incurs extra overhead and makes certain improvements more difficult - more CPU resources allocated at one time.

The new engine narrows and batches work into something like displaylists, which get handed from one processing unit to the next, with each unit being much smaller and with better cache coherency. It is also easier to observe narrowing of work between each stage.

So far this hasn't sped anything up because there is a bit left to do - it's still processing things in the same order as before, but a few more small mods should change the order of all steps and it should (hopefully) result in some speedups in the core/3D part of the engine.

The drawing/texturing is still the primary cost and needs separate attention but I'll get to that much later. There are some new options surfacing here which need experiments.

User avatar
NGF
Captain Atari
Captain Atari
Posts: 368
Joined: Tue Nov 22, 2005 9:22 pm
Location: Stockholm, Sweden

Re: Falcon Doom

Postby NGF » Tue Jan 29, 2013 5:48 pm

Would Doom have a better chance running on a TT or would it make no difference?
"4160" STE with Ultrasatan | Falcon 030 14MB with CF-reader | TT030 | STacy | 520STFM x 2 | 520ST x 2

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Tue Jan 29, 2013 6:52 pm

NGF wrote:Would Doom have a better chance running on a TT or would it make no difference?


Not sure what the chances are for Doom on a TT. I don't know enough about the graphics modes (any chunky pixel modes?) or how efficient the Doom C code is on '030 without a rewrite. If you can find somebody with a TT and coding experience, we might find out :)

Another forum member (Frank B) has both, so if you can talk him into it that might be a good way to get him away from his Amigas ;-) [hint]

BadMood could be converted to pure 030 but would obviously be slower than it is without the DSP, and I expect a direct port of Id's C code would have to run at 'postage stamp' resolution.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1481
Joined: Sun Jul 31, 2011 1:11 pm

Re: Falcon Doom

Postby Eero Tamminen » Tue Jan 29, 2013 7:15 pm

dml wrote:Not sure what the chances are for Doom on a TT. I don't know enough about the graphics modes (any chunky pixel modes?) or how efficient the Doom C code is on '030 without a rewrite. If you can find somebody with a TT and coding experience, we might find out :).


While Hatari's Falcon emulation is more advanced (more cycle accurate etc) than TT emulation, I think its TT emulation to be good enough for Doom development. Unfortunately TT doesn't have chunky pixel modes, just planar ones.


dml wrote:BadMood could be converted to pure 030 but would obviously be slower than it is without the DSP, and I expect a direct port of Id's C code would have to run at 'postage stamp' resolution.


I would propose considering use of a monochrome (or TT duochrome) resolution. Ordered dithering of 8-bit chunky data (which palette has been converted to grayscale with good contrast) can produce OKish results in larger resolutions [1]. With 1-bit display, resolution can be larger than in 8-bit planar, and Monochrome Doom would certain differ from most Doom ports. :-)

[1] Ordered dithering here is plain C and included binary compiled for 68000:
http://koti.mbnet.fi/tammat/hatari/prog ... tml#mortar

Well optimized 030 code hopefully provides significantly more speed (I wouldn't mind somebody contributing one :-)).

User avatar
nativ
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 4087
Joined: Mon Jul 30, 2007 10:26 am
Location: South West, UK

Re: Falcon Doom

Postby nativ » Tue Jan 29, 2013 9:21 pm

dml wrote:BadMood could be converted to pure 030 but would obviously be slower than it is without the DSP, and I expect a direct port of Id's C code would have to run at 'postage stamp' resolution.


Did you ever play Legends of Valor? that had a postage stamp mode :lol:

http://www.atarimania.com/game-atari-st ... _9817.html
Atari STFM 512 / STe 4MB / Mega ST+DSP / Falcon 4MB 16Mhz 68882 - DVD/CDRW/ZIP/DAT - FDI / Jaguar / Lynx 1&2 / 7800 / 2600 / XE 130+SD Card // Sega Dreamcast / Mega2+CD2 // Apple G4

http://soundcloud.com/nativ ~ http://soundcloud.com/nativ-1 ~ http://soundcloud.com/knot_music
http://soundcloud.com/push-sounds ~ http://soundcloud.com/push-records

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Tue Jan 29, 2013 9:59 pm

Eero Tamminen wrote:I would propose considering use of a monochrome (or TT duochrome) resolution. Ordered dithering of 8-bit chunky data (which palette has been converted to grayscale with good contrast) can produce OKish results in larger resolutions [1]. With 1-bit display, resolution can be larger than in 8-bit planar, and Monochrome Doom would certain differ from most Doom ports. :-)

Well optimized 030 code hopefully provides significantly more speed (I wouldn't mind somebody contributing one :-)).


It certainly helps to use a less costly display conversion (8bit chunky -> planar is expensive). Mono Doom would be a bit of a novelty I think :)

At some future point I may provide a 68030 version of the DSP modules in BadMood, although the main goal just now is the Falcon version.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Tue Jan 29, 2013 10:10 pm

So the displaylist/batching exercise turned out to be useful - it has forced quite a bit of rework in areas I didn't spend much time on before, and I can see that some calculations are repeated for upper / middle / lower wall surfaces which only needs done once for the entire wall segment.

Some optimizations are missing from the 'sky' surfaces that seem only applied to real walls for no obvious reason. There were also some calculations shared between wall surfaces that weren't obvious and broke the batching test. So the code will be much more compact and consistent after the rework (and so, likely quicker).

There are still some fiddly changes to be made (more than I expected :-( ) but it's going in the right direction...

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1481
Joined: Sun Jul 31, 2011 1:11 pm

Re: Falcon Doom

Postby Eero Tamminen » Tue Jan 29, 2013 11:03 pm

dml wrote:
Eero Tamminen wrote:I would propose considering use of a monochrome (or TT duochrome) resolution.


It certainly helps to use a less costly display conversion (8bit chunky -> planar is expensive). Mono Doom would be a bit of a novelty I think :)


Before doing that one would need to check that Doom palette provides enough contrast, or can be made such that when it's ordered dithered, the result is clear enough... If not, it's not worth the trouble.

One possible improvement could be to change game player and aliens textures brightness vs. background textures so that at least enemies can clearly be seen with BW ordered dithering. If it's possible to use different rasterizer for different types of objects, another possibility would be to use separate dither matrices for them.

Last time I looked at Doom & Heretic code (in 90's), the final display part was well separated from rest of the code (= not possible to separately rasterize objects at that state), so testing the dithered rendering speed of C-version should be fairly easy to do, if one is so inclined. :-)

User avatar
viking272
Captain Atari
Captain Atari
Posts: 239
Joined: Mon Oct 13, 2008 12:50 pm
Location: west of London, UK

Re: Falcon Doom

Postby viking272 » Tue Jan 29, 2013 11:07 pm

dml wrote:Lets also assume it was an all or nothing decision - you either need one or you don't. Would that be a bad thing?

The stock model Falcon didn't ship with a coprocessor, but OTOH they are cheap and common and solder-free to install (Atari provided the empty socket) and I'm not sure if other ports (e.g. Amiga?) would hold back from adopting FPU if it helped. Not that I've looked into it much but it seems like it might be fair game.

So far BadMood hasn't used the FPU at all and so it will work on any Falcon but I'm not sure what people think about 'min spec' for a Doom engine on Atari? Should it be aimed at 'stock model' machines all the way?


I fitted a 68882 also and most of my mates did, but I can't help thinking there are lots without an FPU still.
Having the socket easily recogniseable on the motherboard and simply pushing them in was dead easy.

I guess it depends on how much gain there is? < 15% no but > 15% then yes??

User avatar
Omikronman
Atari Super Hero
Atari Super Hero
Posts: 514
Joined: Wed Dec 01, 2004 12:13 am
Location: Germany
Contact:

Re: Falcon Doom

Postby Omikronman » Wed Jan 30, 2013 5:00 am

Software which recommends a FPU is very rare. Raytracing/Rendering makes heavy usage of the FPU, and most raytracing software does not work without a FPU (except RayStart).

The only screen mode which would probably be useful and colorful enough on the Atari TT may probably be the TT low res mode, 320 x 480 pixels and 256 colors, choosen of a 4096 color palette.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1481
Joined: Sun Jul 31, 2011 1:11 pm

Re: Falcon Doom

Postby Eero Tamminen » Wed Jan 30, 2013 8:32 am

TT has FPU, so use of FPU would make more sense there...

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Wed Jan 30, 2013 9:32 am

Seems like Falcon users would like to see the FPU useful, but not a firm requirement.

The easiest way to do that is issue two different builds of the program, but if the FPU stuff isn't scattered everywhere some functions could be selected at runtime and permit a single build.

BM is still all assembly language so meta-controls on code generation are sometimes uncomfortable to do without source code duplication but it's ok for small patches of stuff here and there...

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1481
Joined: Sun Jul 31, 2011 1:11 pm

Re: Falcon Doom

Postby Eero Tamminen » Wed Jan 30, 2013 2:34 pm

FYI: There's now first version of Hatari profile data post-processor:
http://hg.tuxfamily.org/mercurialroot/h ... profile.py

So far I've tested it only with EmuTOS, but next I intend to test it with normal programs, I would suggest waiting until I've finished that.

Normal program rofile post-processing requires giving the script both program symbol information and TOS symbol information, if program calls TOS functions during profile. A latest Hatari mercurial version will also be needed as only that will output the TOS & program location information to the profile data.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Wed Jan 30, 2013 4:16 pm

I had some time over lunch to test the most recent code but forgot to post executables here - perhaps somebody can test them on a real Falcon and report back the FPS reading? Assuming they work at all...

BM4T1.zip


It's an early work in progress so plenty still to do, but a few optimisations are already in there.

In Hatari I was getting 3.0FPS for the original BM3.07.TTP, and now I'm seeing 4.4FPS with the new code, same configuration.


Differences:

BM4T1.TTP - normal test with the usual stuff enabled (mouse is off though). (This is the one reading 4.4FPS in Hatari)

BM4T1_NS.TTP - sprites ('things') are disabled in this one. sprites drawing is 'temporary' in BM so it hurts speed when a few of them are visible at once. this gives a more honest measure of the wall/floor drawing which is the main focus at the moment.

BM4T1_NT.TTP - textures are also disabled in this one. shows the speed of the engine core without the separate (currenly heavy) cost of texturing or sprites. any slowdown in this build indicates bottlenecks in the CPU or DSP part of the main engine.
You do not have the required permissions to view the files attached to this post.

User avatar
calimero
Atari God
Atari God
Posts: 1941
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Falcon Doom

Postby calimero » Wed Jan 30, 2013 5:34 pm

'postage stamp' ROLF :D :D

BM4T1.TTP - 4.6647 FPS
BM4T1_NS.TTP - 4.8632 FPS
BM4T1_NT.TTP - 11.1887 FPS

btw in BM4T1_NT.TTP there are still two walls with textures ;)
this rainbow doom is supter fast!
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

f030
Atari User
Atari User
Posts: 41
Joined: Wed Dec 07, 2011 1:46 pm

Re: Falcon Doom

Postby f030 » Wed Jan 30, 2013 5:41 pm

seems to be slower than BM3.07

rgb:

BM4T1 - 4.6511 fps
BM4T1_NS - 4.8484 fps
BM4T1_NT - 11.1887 fps

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Wed Jan 30, 2013 5:45 pm

f030 wrote:seems to be slower than BM3.07


Slower than the old 1990's release of BM3.07? or the 'broken textures' test I posted quite recently? (the one that looked dark blue and corrupted).

I should have started changing the version number as soon as I edited the code to prevent confusion...

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Wed Jan 30, 2013 5:50 pm

Here's the original one for comparison...

BM307ORG.zip
You do not have the required permissions to view the files attached to this post.

User avatar
calimero
Atari God
Atari God
Posts: 1941
Joined: Thu Sep 15, 2005 10:01 am
Location: STara Pazova, Serbia
Contact:

Re: Falcon Doom

Postby calimero » Wed Jan 30, 2013 6:10 pm

dml wrote:Here's the original one for comparison...

BM307ORG.zip

with this one:

2.6446 FPS

EDIT:

WAIT !!!

I just do clean boot (ctrl) and I get 5.2117 FPS (it looks like that something in my auto folder interfered with BadMood) BUT previous results with version 4 are SAME! (my auto folder stuff affect only version 3.07)
using Atari since 1986.http://wet.atari.orghttp://milan.kovac.cc/atari/software/ ・ Atari Falcon030/CT63/SV ・ Atari STe ・ Atari Mega4/MegaFile30/SM124 ・ Amiga 1200/PPC ・ Amiga 500 ・ C64 ・ ZX Spectrum ・ RPi ・ MagiC! ・ MiNT 1.18 ・ OS X

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Wed Jan 30, 2013 6:28 pm

Looks like I accidentally left the d-cache off in v4.00 while testing something for Hatari :-(

That probably wasn't helping matters...


Thanks everyone for testing it. Looks like the test was broken and I'll have to issue a new build. At least it does still run on a normal machine though..

My 16MHz stock Falcon works now and is booting from CFLASH but I can't transfer anything to it from the PC yet. Writing to the CF on the PC corrupts the whole partition every single time, despite being formatted in HDDRIVER for TOS+Win/byteswapping/32MB etc...

f030
Atari User
Atari User
Posts: 41
Joined: Wed Dec 07, 2011 1:46 pm

Re: Falcon Doom

Postby f030 » Wed Jan 30, 2013 6:30 pm

dml wrote:
Slower than the old 1990's release of BM3.07? or the 'broken textures' test I posted quite recently? (the one that looked dark blue and corrupted).


slower than the one from 90's

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Wed Jan 30, 2013 7:23 pm

If this version doesn't help, I'll hold further builds until I get file transfer sorted out over here...

BM4T2_NS.zip
You do not have the required permissions to view the files attached to this post.

f030
Atari User
Atari User
Posts: 41
Joined: Wed Dec 07, 2011 1:46 pm

Re: Falcon Doom

Postby f030 » Wed Jan 30, 2013 8:03 pm

rgb:

BM4T2_NS - 5.4237 fps

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3429
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Wed Jan 30, 2013 8:19 pm

f030 wrote:rgb:

BM4T2_NS - 5.4237 fps


Thanks.

So the 030 data cache is making quite a big difference somewhere in BadMood. Hatari currently behaves a bit like it's always turned off (which is how I managed to forget I left a hack in there to compare on/off in Hatari == no difference).

It's often just disabled in demos because it thinks it's running on a 32bit bus and ends up wasting cycles overall. But clearly it can be useful. I'll be looking for ways to make it more useful a bit later.

For now it seems there's a small speedup over 3.07 which is fine. Wasn't expecting much as the texturing is the main cost. But gradually getting more and more of the code and data to fit in the caches is helping in small pieces...


Social Media

     

Return to “Games”

Who is online

Users browsing this forum: No registered users and 2 guests