Falcon Doom

All about games on the Falcon, TT & clones

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

kristjanga
Captain Atari
Captain Atari
Posts: 400
Joined: Sat Jul 25, 2009 3:35 pm

Re: Falcon Doom

Postby kristjanga » Thu Jan 10, 2013 7:41 pm

this deserves to be worked on

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

Re: Falcon Doom

Postby nativ » Thu Jan 10, 2013 7:50 pm

I wonder would any FPU optimisations be useful in this game? supporting the 68882 with the 030 and the built in ones on the 040 and 060?
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: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Thu Jan 10, 2013 7:54 pm

LaurentS wrote:I think this approach is the good one to have a descent Doom on Falcon.
It's sad that it was not finished.


Hi Laurent - I remember you worked on the project too.
Yes we should have continued with it. I'm still a bit sad I left so many Atari projects unfinished and so abruptly.

EvilFranky wrote:Was a shame it never became a complete game but guess there is a large amount of work to be done.
Doug - so you think it could be made faster again?


I think most of the work would be in level design and new, more interesting enemies and game objects (why port doom directly? everyone must be sick of it by now!). i.e. proper game design. I suppose any music/sfx had better avoid the DSP too...

Yes I think it could be faster. I learned things since then which would probably lead to different choices in places and I remember wanting to try the PMMU cache inhibit flag for display memory to get more mileage from the data cache for scaled-up textures. The DSP is probably still being underused as well (or 'over used' i.e. needing optimisation).

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

Re: Falcon Doom

Postby dml » Thu Jan 10, 2013 8:18 pm

kristjanga wrote:this deserves to be worked on


Thanks for putting up the YT vid some time ago :) I only found it yesterday.

nativ wrote:I wonder would any FPU optimisations be useful in this game? supporting the 68882 with the 030 and the built in ones on the 040 and 060?


On the 040 and 060 - certainly. But at that time it was intended for 030.

I actually tried both a 68040/FPU and a DSP version of the Quake surface renderer in my Quake port, and found the 040/FPU version slightly faster and more precise. The DSP version worked (and was quite complicated :/) but didn't gain anything. Testing on a normal Falcon - everything else on the 68030 was slow enough that it was little more than an experiment in DSP programming... it was unplayable. In fact even the 040 version wasn't playable but it was at least watchable :)


A 68882 (coupled to 030) is a very precise device but it's not terribly fast.

I've been working on some 3D stuff again recently and have implemented a software FMUL for plain 68000 which takes about 150 cycles, and the 68882 FMUL takes about 75 cycles. So in this case the 882 is only 2x as fast as my hand coded ST asm :) albeit a good bit more precise!


A 68882 could probably be put to use for some of the stuff happening in BM - low bandwidth 3D stuff for the BSP nodes etc. Would be simpler and more maintainable than the existing DSP version.

However the DSP is doing some heavy spanbuffer management, which drives the CPU drawing/texturing and prevents overdraw and missing pixels - this requires a lot of bandwidth and not much precision so 882 isn't much use there.

I wouldn't rule out the 882 completely but it needs quite specific problems to be worth using it around high performance drawing on a normal Falcon. I can think of one very good use case but I should try it before I say what it is ;)

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

Re: Falcon Doom

Postby nativ » Thu Jan 10, 2013 9:31 pm

ok 8) d:m:l

I was looking at the comparison tables between a Falcon @40Mhz and a Falcon 68882 @ 16Mhz (Kronos tests) which showed the FPU as quite beneficial.

I currently only have a 16Mhz FPU in my Falcon ( though I have a 40 ready to pop in )....... hmmm I am thinking about vector games and simple 3d so I wonder if the FPU is beneficial to research?

On a slight tangent there is a Dreamcast cheat to show the debug mode of Sonic adventure, it's was very interesting to see how they were building the environment. As I understand the DC uses it's FPU to some interesting effect.


I suppose any music/sfx had better avoid the DSP too... Some funky chip music? ;D and 68k sample FX sorted

Depends how much CPU you have left? space isn't an issue these days so you could 'Stream audio' from the HD or a CD? then it's just a DMA feed.

/nativ
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
LaurentS
Captain Atari
Captain Atari
Posts: 286
Joined: Mon Jan 05, 2009 5:41 pm

Re: Falcon Doom

Postby LaurentS » Thu Jan 10, 2013 10:44 pm

Hi Doug,

> Hi Laurent - I remember you worked on the project too.

It's a great pleasure to hear about you after all these years.
I was at the early beginning of Badmood, but you are the one who did all the magic coding on this piece of software.


> Yes we should have continued with it. I'm still a bit sad I left so many Atari projects unfinished and so abruptly.
I agree. I've also turned away of the falcon world for too much time.
But I think I've repaired my fault ;) with beats of rage (I wish) and Hatari falcon emulation (not finished, but useful).

It would be great to have a nice doomlike on standard falcon (as a enjoyable old project).

Best regards,

Laurent / Thadoss

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

Re: Falcon Doom

Postby dml » Thu Jan 10, 2013 10:48 pm

nativ wrote:I was looking at the comparison tables between a Falcon @40Mhz and a Falcon 68882 @ 16Mhz (Kronos tests) which showed the FPU as quite beneficial.


It is useful, but it is of limited use for pixel painting. It becomes more useful as you do less with it, basically :) esp. if you need precision - or more importantly, dynamic range (e.g. placing a small rock in a huge world without massive headaches).

If you overclock the thing you're obviously making it more useful... I also have a couple of 40MHz chips kept aside for Falcon tests :-)

I'm have really been talking about a stock Falcon so far. The fmul and fadd are not quite quick enough @16mhz for pixel/span-level stuff and a bit borderline for scan-level stuff. On 040/060 they are good for everything - esp. 060 where floats are essentially free :)

nativ wrote:Depends how much CPU you have left? space isn't an issue these days so you could 'Stream audio' from the HD or a CD? then it's just a DMA feed.
/nativ


It's not frame-locked so there's as much CPU time left as the audio will need... a 4 channel mux should be workable at least (e.g. cpu modplayer) for sfx and/or music. There is SFX support in BM already (by another contributor) but I'd need to look to remember how that works... it may already be solved.

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

Re: Falcon Doom

Postby dml » Thu Jan 10, 2013 11:00 pm

LaurentS wrote:It's a great pleasure to hear about you after all these years.


And it is very nice to see you here as well, almost like the years didn't pass. :-)

LaurentS wrote:I agree. I've also turned away of the falcon world for too much time.
But I think I've repaired my fault ;) with beats of rage (I wish) and Hatari falcon emulation (not finished, but useful).


Amazing work!! I did not know that was you.. :-z I am still catching up with a lot of things it seems....

LaurentS wrote:It would be great to have a nice doomlike on standard falcon (as a enjoyable old project).


It was a lot of fun working on it - and on the Falcon generally.

Perhaps a good start would be to relink the last sources at my site, for others to look at while I find more time...

http://www.leonik.net/dml/sec_bm.py

(done) ;)

Best Regards,
Doug

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

Re: Falcon Doom

Postby dml » Fri Jan 11, 2013 11:45 am

Ok while I was certain the BM rendering code used mipmaps, I can't find anything in the code for that (so far). So there's another way to speed things up, if the data cache can be better used at greater scene depths.

The lighting and depth-cue is also dynamic (texture lookup[uv] -> colour lookup[l] -> output) which makes room for lots of nice effects, but if the depth cue was unrolled into mipmaps instead and resolved using only scene-z instead of the usual du/dv it would reduce three costs at once - the extra lookup would be gone, the datacache would be available for the mip source only and there would be less needing cached for distant mips. However the dynamic lighting stuff would need to be handled differently, or the existing code kept only for surfaces which needed dynamic lighting.

The 68040 CPU detect code tries to find my XMMU cookie API and makes calls to that to prepare display memory for 'pure writing', as a speed optimisation. This is also possible on a 68030 and I can see that I began work on a XMMU driver for 68030 for this purpose (auto folder patch). But I didn't finish it and I don't know if the gain would even be noticeable with the current drawing code as it is. It would also send MiNT into the vortex if both were used together ;)

There is also code-generation potential for texturemapping since walls have a finite number of usable/differentiable indexing patterns, although the solution for that would likely need tons of memory and there would be some texturing precision loss (the precision level is currently nice IMO :). I don't see how this could work for floors though - burning rotation and scaling into floor drawing code means too much memory or too little precision - wobbly floors. And it definitely doesn't work for turbulent floors (water, lava).

There is no code/rendering profiler in BM. This would have been a good move - seeing the %age impact of various kinds of drawing and relative use, for guiding sensible optimisation effort. A prime-number based TimerC event sampler coupled with a task index updated in the main code would be enough to build a decent picture over a few seconds and quite easy to implement.

There is also an unexplored c2p/256 colours route but I think the c2p cost would set an unacceptable minimum bound on framerate on a stock Falcon. The rendering would also look a bit worse for it. Somebody else might have a different opinion - I didn't actually try it.

Any optimisations would need to take special care over precision loss - since lowering the display resolution ('blocky' double pixel modes) will basically double or quadruple any precision errors in the texturemapping. What looks like acceptable error at 320x240 doesn't look so acceptable at 160x120...


Anyway - even on a quick inspection there are lots of ways to mess with it and likely speed it up. The more complex something is, there more ways there are to optimise it. BM is quite complex so there's plenty still on the table...

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

Re: Falcon Doom

Postby nativ » Fri Jan 11, 2013 3:00 pm

Any optimisations would need to take special care over precision loss - since lowering the display resolution ('blocky' double pixel modes) will basically double or quadruple any precision errors in the texturemapping. What looks like acceptable error at 320x240 doesn't look so acceptable at 160x120...


http://www.youtube.com/watch?v=Z3-J2-VeoH8

I am assuming this runs at less than 320*240 :)
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: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Fri Jan 11, 2013 3:13 pm

nativ wrote:http://www.youtube.com/watch?v=Z3-J2-VeoH8
I am assuming this runs at less than 320*240 :)


Trying Wolf on a 6502 is a wild idea but also cool...

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

Re: Falcon Doom

Postby dml » Fri Jan 11, 2013 4:37 pm

There is another way to 'finish' BadMood IMO - the cheap & cheerful way. That is not to 'finish' it but to graft it directly onto Doom itself as an output-only rendering server.

I imagine a process something like this...

- Get BM building with VASM and gcc cross-tools
- Rework it into two parts - the rendering part and the 'game' part which has some proto-game stuff in it already like collisions and camera/sector height management.
- Turn the rendering part into a gcc library via VASM. Keep the other part on the shelf, just for viewing WADs.
- Grab the Doom sourcecode. or better still - PMDOOM since it's Id's complete code with ready-ported 68k bits and pieces and already compiles and runs on Atari! But essentially, get the actual Doom code.
- Isolate the rendering services in Doom, replacing it all with a very high level stub renderer. This shouldn't be too hard (!) because Id did everything that way from the start. Doom was developed on NeXT before it reached the PC and the 'rendering server' idea is already present.
- Do some performance testing on the Doom code without any rendering (e.g. in attract mode) and make a note of anything painful.
- Link BM to the newly crippled Doom project, and give BM control over the display init & refresh, but leave game state and WAD selection in the hands of the Doom game code. BM can still open the WAD file independently to get textures etc. not efficient but hardly worth worrying about since BM will have the lion's share of the WAD use anyway.
- Tie up game state to BM via the stub renderer and any other tunnels required to do the job - current level, position of camera, positions of sprites (and when they move), text overlays blah blah.
- Need a little bit of complexity to register/relate BM sprite objects with Doom game objects, since BM will prefer to render sprite lists from its own internal sector-based representation.
- Fill in annoying missing bits like text support in BM
- Order beer

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

Re: Falcon Doom

Postby dml » Fri Jan 11, 2013 7:01 pm

Perhaps somebody could test this for me on a real Falcon030 without any speed mods made to it (esp. the DSP).

https://dl.dropbox.com/u/12947585/BM/BMTEST.zip

Use this WAD (it's not the full one, but the demo - if you have this already, skip the download):

https://dl.dropbox.com/u/12947585/BM/DOOM1.zip


Drag the WAD file onto BM and when you see the splash text, press a key as usual and you'll see a 'coloured mess'.

Press 'F' for fullscreen mode, and press '5' to enable the FPS counter, and let it settle. Please report the FPS figure back to me here, for both versions of the TTP in the ZIP.

Note: There's no point in running this under Hatari - I've already done that bit :)

Note #2: Try not to disturb the view by moving the mouse - I'm looking for a FPS reading with the camera at the exact startpoint.

Cheers

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 872
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: Falcon Doom

Postby EvilFranky » Fri Jan 11, 2013 7:47 pm

Ok, decided to pull the Falcon out and try this Doug...

BM1.ttp gets 7.5117 FPS
BM2.ttp gets 7.5117 FPS

Don't know what difference each of them have, except for slightly different colour schemes!

If you need more tests then I'll keep the Falcon out :cheers:

This was with the full Doom 1 WAD.

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

Re: Falcon Doom

Postby dml » Fri Jan 11, 2013 7:55 pm

Ok so it's exactly the same. Thanks.

Both of them have texture lookups disabled so it can't get faster than that without changing the spanbuffer (DSP side) or reducing the cost of plotting pixels, or number of pixels plotted. The difference between the two - there are some cache control differences for plotting. Didn't have any impact so I'll leave that alone until I can test it properly here.

I'll probably have another test to follow up another day.

Cheers,
Doug

EvilFranky wrote:Ok, decided to pull the Falcon out and try this Doug...

BM1.ttp gets 7.5117 FPS
BM2.ttp gets 7.5117 FPS

Don't know what difference each of them have, except for slightly different colour schemes!

If you need more tests then I'll keep the Falcon out :cheers:

This was with the full Doom 1 WAD.

User avatar
dma
Atari God
Atari God
Posts: 1029
Joined: Wed Nov 20, 2002 11:22 pm
Location: France
Contact:

Re: Falcon Doom

Postby dma » Sat Jan 12, 2013 10:19 am

So this is intending to have Doom playable on a standard Falcon? Would be amazing. :)

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

Re: Falcon Doom

Postby dml » Sat Jan 12, 2013 10:31 am

dma wrote:So this is intending to have Doom playable on a standard Falcon? Would be amazing. :)


It seems like gluing BM onto Doom is possible and it would probably open up a path to simpler / faster renderers (e.g. flatshaded, or simpler texturing or 16-colour or whatever can be brewed up) for an already finished/playable game.

Compared with writing game logic for BM it seems like less work to me. Although I was originally hoping for a new/different game with doom-like visuals. There are so many versions of Doom that it would be more of a Falcon novelty than an interesting new game...

OTOH, if it's done right one could open a path to the other :) Somebody else could get interested in writing the game part and join it up to BM in exactly the same way.

First I'll look to see how much effort is involved and do some proper profiling on it to see if it's currently more CPU or DSP limited. Looking at it with fresh eyes again.

User avatar
LaurentS
Captain Atari
Captain Atari
Posts: 286
Joined: Mon Jan 05, 2009 5:41 pm

Re: Falcon Doom

Postby LaurentS » Sat Jan 12, 2013 11:34 am

That's a very good news !

Thanks for this.

Best regards

Laurent

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

Re: Falcon Doom

Postby nativ » Sat Jan 12, 2013 11:08 pm

If you were considering a new game in this vein then I would suggest 'Out Trigger' (SEGA) or Unreal Tournament as possible candidates?

Or something else...... http://bzflag.org/
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: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Sat Jan 12, 2013 11:18 pm

nativ wrote:If you were considering a new game in this vein then I would suggest 'Out Trigger' (SEGA) or Unreal Tournament as possible candidates?

Or something else...... http://bzflag.org/


I really meant something that only exists for Falcon - not a port of some other existing game. Use BM to draw stuff, but the game part is unique. However, we'll see. I have a lot to think about before taking any steps in either direction.

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

Re: Falcon Doom

Postby nativ » Sun Jan 13, 2013 12:28 am

:) just a wild thought... I was thinking about tinkering with network games and vectors... :coffe: got plenty to read
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: 3474
Joined: Sat Jun 30, 2012 9:33 am

Re: Falcon Doom

Postby dml » Sun Jan 13, 2013 11:49 am

nativ wrote::) just a wild thought... I was thinking about tinkering with network games and vectors... :coffe: got plenty to read


:)

Keep in mind Doom is a 2D vector game, not 3D at all. It's all plan view layout with elevation values for a conceptual floor and ceiling (every sector has an implied floor and ceiling, even if one or other is marked invisible), but projected into 3D in a clever way. So making a game for the 2D vector bit is quite a lot less trouble than a real 3D game...

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

Re: Falcon Doom

Postby dml » Sun Jan 13, 2013 12:02 pm

So I've been thinking about this over the weekend and it's clear there are numerous ways to speed up BadMood on a normal Falcon. I don't know what it all adds up to but it can be made faster than it is.

However some of the speedups would use ram - it's likely the best gains would be realized on a 14mb machine. I don't know if that would be a problem, although making those speedups optional would be possible too (i.e disable on 4mb machines).

Opinions on the 'min spec' are welcome.

EvilFranky
Atari Super Hero
Atari Super Hero
Posts: 872
Joined: Thu Sep 11, 2003 10:49 pm
Location: UK
Contact:

Re: Falcon Doom

Postby EvilFranky » Sun Jan 13, 2013 12:23 pm

In this day an age RAM is so plentiful that it shouldn't make any odds as to whether a production should fit into a 'constraint', look at all the new STE stuff that is making good use of more than 1MB now...

It would be great to see Bad Mood optimized after all these years (it's hardly slow though) and to see what could have been achieved on a 4MB Falcon vs a 4MB PC as I believe this was roughly minimum RAM for the PC version back then?

I guess to cover all bases your idea of having a select-able 4MB/14MB mode would be best Doug.

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

Re: Falcon Doom

Postby dml » Sun Jan 13, 2013 2:15 pm

EvilFranky wrote:In this day an age RAM is so plentiful that it shouldn't make any odds as to whether a production should fit into a 'constraint', look at all the new STE stuff that is making good use of more than 1MB now...


I think a lighting and mipmap cache would see some speed gain at the cost of (quite a lot) more RAM - but cache size limits can be set and levels (for a new game anyway) can be designed to trade cache size against incremental level loading time (the textures are loaded and surface cache populated as new textures are seen). So a smaller cache could be used on 4MB and might yield some fps gains but there would be more interruption when moving from region to region or a sudden loss of fps on more complex scenes...

EvilFranky wrote:It would be great to see Bad Mood optimized after all these years (it's hardly slow though) and to see what could have been achieved on a 4MB Falcon vs a 4MB PC as I believe this was roughly minimum RAM for the PC version back then?


Should be possible to keep things working ok on 4MB even if there isn't much gain.

Some speedups won't need any extra ram - just texture precalc/cache related ones.


Social Media

     

Return to “Games”

Who is online

Users browsing this forum: No registered users and 6 guests