Bad Mood : Falcon030 'Doom'

All 680x0 related coding posts in this section please.

Moderators: simonsunnyboy, exxos, Mug UK, Zorro 2, Moderator Team

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Feb 11, 2013 8:13 pm

...sorry one more caveat - FPU needed. Haven't converted the linear/perspective-correct thing back to 68k. Again, temporary.

DrTypo
Atari freak
Atari freak
Posts: 73
Joined: Sat Apr 09, 2011 12:57 pm
Location: Paris, France

Re: Bad Mood : Falcon030 'Doom'

Postby DrTypo » Mon Feb 11, 2013 9:55 pm

I tested BM4T4.TTP on my Falcon.
Default view: 6.4256 fps.
Overcloked: 11.111 fps.
I moved around and it doesn't hang on the overclocked Falcon. Therefore on a stock Falcon the DSP has a comfortable margin left.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Feb 11, 2013 10:25 pm

DrTypo wrote:I tested BM4T4.TTP on my Falcon.
Default view: 6.4256 fps.
Overcloked: 11.111 fps.
I moved around and it doesn't hang on the overclocked Falcon. Therefore on a stock Falcon the DSP has a comfortable margin left.


Ok thanks for the results - was that overclock test with the same ratio of DSP:CPU+BUS == 2:1? Or was the CPU clocked a bit faster? I think it should be ok if the ratio doesn't change or the DSP keeps the edge. If the DSP ratio drops I'd expect some problems with lockups.

There's definitely a problem shrinking the display but I think it's actually a bug in the DSP view init code not preparing the display structures properly on a resize. There's at least one other DSP bug which needs attention which only shows if I clear the DSP memory to some non-zero value before use. I'll get around to these eventually (or when they stop progress ;-) ).

This version is a little slower because some things got de-optimised for rework but more speed will be scraped again back later.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Tue Feb 12, 2013 10:02 am

Last night I tested two JagDoom -> 'vanilla' Doom conversion to see if the reduced-detail map would improve performance. However this is what I found:

6.4515fps jaguartc.wad [Hatari]
6.4515fps jagdoom.wad [Hatari]
6.4777fps doom1.wad [Hatari]

Both Jag versions were actually slower. In fact they are probably both the same map, with some changes to suit different engines. I'm not yet sure why they are slower because there are obvious optimizations in view, including the removal of one 'step' sector in the recess immediately in front of the viewer. There are fewer textures as well although I don't expect a big saving from that on the Falcon since texture count isn't yet a performance variable.

My guess is that the map conversion didn't BSP as well as the original. When Doom1 was released, it struggled on a large number of the PCs in circulation (low end 386's), so Id probably spent ages BSP'ing the maps with frequent edits and different settings and tweaks to get the performance up. Since then, the need for optimally built maps for user-made levels has dropped away because machines are so much faster now.

Anyway I'll look into it another time...

[edit]

I now think the main 'optimization' in the Jaguar Doom maps is texture count, and removal of transparent walls. There are some geometric detail reductions but not very many. On balance, it's not really helping the Falcon except maybe on a 4MB machine when the whole game is loaded...

DrTypo
Atari freak
Atari freak
Posts: 73
Joined: Sat Apr 09, 2011 12:57 pm
Location: Paris, France

Re: Bad Mood : Falcon030 'Doom'

Postby DrTypo » Tue Feb 12, 2013 12:08 pm

dml wrote:Ok thanks for the results - was that overclock test with the same ratio of DSP:CPU+BUS == 2:1? Or was the CPU clocked a bit faster? I think it should be ok if the ratio doesn't change or the DSP keeps the edge. If the DSP ratio drops I'd expect some problems with lockups.


68030 & BUS are clocked at 25MHz and DSP at 50Mhz (I'm using Rodolphe's Centurbo 1 evolution 2 board).
The acceleration ratio for each component is +56.25%.
However the 68030 gets more than that: the VIDEL uses a fix amount of bandwidth. About 4MHz for a 320x200 TC screen on a VGA monitor.
So on a stock Falcon there is 12MHz left for the 68030.
On the accelerated Falcon there is 21MHz left. So the bus bandwidth left for the 68030 grows by +75%.
When you chekc the fps in Badmood, there is a +73% speed increase on the accelerated Falcon.
Basically the 68030 fillrate grows more than DSP computing power.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Tue Feb 12, 2013 12:48 pm

DrTypo wrote:
dml wrote:Ok thanks for the results - was that overclock test with the same ratio of DSP:CPU+BUS == 2:1? Or was the CPU clocked a bit faster? I think it should be ok if the ratio doesn't change or the DSP keeps the edge. If the DSP ratio drops I'd expect some problems with lockups.


68030 & BUS are clocked at 25MHz and DSP at 50Mhz (I'm using Rodolphe's Centurbo 1 evolution 2 board).
The acceleration ratio for each component is +56.25%.
However the 68030 gets more than that: the VIDEL uses a fix amount of bandwidth. About 4MHz for a 320x200 TC screen on a VGA monitor.
So on a stock Falcon there is 12MHz left for the 68030.
On the accelerated Falcon there is 21MHz left. So the bus bandwidth left for the 68030 grows by +75%.
When you chekc the fps in Badmood, there is a +73% speed increase on the accelerated Falcon.
Basically the 68030 fillrate grows more than DSP computing power.


Yes that all makes sense. I only thought about the Videl ratio after posting. It's very useful to have these details though (my guess re: the Videl ratio was at best just a guess).

So it would seem there is indeed margin left on the DSP in VGA mode. I had some problems in RGB mode while changing the number of padding operations on the DSP but I didn't compare on VGA to find out how the available DSP time varied between the two. It seems like an experiment worth doing. It might actually be possible to arrange a different rendering routine on systems with lower available bandwidth between CPU/DSP, to consume the extra DSP time in some useful way. Something I didn't consider before...

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Tue Feb 12, 2013 12:49 pm

The next thing I'll be working on short-term is remapping the visplane textures into their own private 32x32 palette/lighting table (LCLUT).

Reducing the unique colour count to 32 seems brutal but the original textures don't actually use many colours - based on the fact they are already indexed against a generic 256 colour palette, only a small part of which makes sense for each individual texture. Some of those textures use as few as 4 or 8 colours. So reducing to 32 colours with the mipmaps included in the reduction will actually increase the colour count in those textures due to the filtering effects producing in-between shades. It will also allow me to pack 3 texels per word for DSP uploading, and reduces the LCLUT to 32x32 = 1kword on DSP (or 2kbytes to upload). Each texture will then cost about 4kbytes to upload in total including MIPs + LCLUTs, and will allow sector and depth-cue lighting again.

I'll use a linear congruential generator to sample the mip page colours for reduction. This is the fairest way to generate each LCLUT while taking advantage of the increase in colours, and remain quick enough to do on demand.


Once this is done, I'll focus on DSP texture uploads and scene renderstate sorting for that. This will require DSP code rework so it will take some days before anything is likely to appear...

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 13, 2013 1:40 am

Had a crazy idea tonight which needs tried later - bump maps on floors!

Since each texture has it's own lighting info on the DSP side, it would be possible at something like 3x the cost of standard texture mapping.

The texturemapping aleady interpolates world x,z as texture u,v coords and tiling is applied late - just before addressing, so the DSP knows where each texel is in worldspace all the time.

A single lightsource positioned in worldspace would need transformed into floor texture space before rendering, and a vector drawn between each texel <x,0,z> position and the lightpos as the texture mapper advances across the texture (and floor). This vector would then need normalized with a ~2k(?) lookup table on the (magnitude^2), and dot3 against a 2nd texture containing <nx,ny,nz> bump normals (or at extra cycle cost and complexity, the top 8 bits of the same texture, with <3,2,3> bits of normal info). The product is used to index the lighting table and you have shiny bumpmaps.

For a directional vs point source, it's about half as complex as that (just dot3 the 2nd texture against a one-time transformed/normalised light ray), so maybe 1.5-2x the cost of texture mapping. Probably not as nice though.

I guess this would not be a helpful 'upgrade', given that the aim is to make the thing faster for gameplay. And there are no Doom bumpmaps to play with in any case - but it looks feasible and would be funny to see on a base Falcon :-)

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 13, 2013 10:27 am

Visplane mipmap filtering is now truecolour, and still permits lighting. Although lighting is still broken.
.
mmtc2.jpg


mmtc1.jpg



Getting towards the end of the major rework on floors and ceilings... still a few things needing done but end is in sight.

It will be another couple of days I think before anything new happens.
You do not have the required permissions to view the files attached to this post.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 13, 2013 11:54 am

Last version with the changes made last night with quite a lot of old bugs fixed, including a nasty DSP window resize thing, screen clear and VGA scanline adjust problems.

Mipmaps still need some work, especially view-dependent rate adjustment for perspective compression, but it is working reasonable well already and the reduction step doesn't take long. Reduction will be off-lined & cached as files at some point later.
You do not have the required permissions to view the files attached to this post.

User avatar
bullis1
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2301
Joined: Tue Dec 12, 2006 2:32 pm
Location: Canada
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby bullis1 » Wed Feb 13, 2013 1:44 pm

I'm just chiming in to express my enjoyment of this project!

I've been working on a Doom-engine based project for the Sega 32X for a while now. Maybe an enhanced Falcon version would be possible in the distant future.
Member of the Atari Legend team

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 13, 2013 2:07 pm

bullis1 wrote:I'm just chiming in to express my enjoyment of this project!

I've been working on a Doom-engine based project for the Sega 32X for a while now. Maybe an enhanced Falcon version would be possible in the distant future.


:-) Cool. I noticed some 32X activity recently while digging around for Doom resources so maybe that's the same project.

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

Re: Bad Mood : Falcon030 'Doom'

Postby f030 » Wed Feb 13, 2013 2:18 pm

F030 + Mighty Sonic 32 cpu@16mhz dsp@32mhz RGB gives 7.5 fps
F030 + Mighty Sonic 32 cpu@16mhz dsp@32mhz + TT-ram RGB gives 8.4 fps

tt-ram gives nice boost about 13 percent

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 13, 2013 4:00 pm

f030 wrote:F030 + Mighty Sonic 32 cpu@16mhz dsp@32mhz RGB gives 7.5 fps
F030 + Mighty Sonic 32 cpu@16mhz dsp@32mhz + TT-ram RGB gives 8.4 fps

tt-ram gives nice boost about 13 percent


Thanks for that - the boost is probably within wall drawing and scene processing. The floor drawing is all DSP and CPU cache, not much gain to be had from fastram.

It might be a good exercise to turn the texturing off in the walls and compare with/without fastram because this will indicate what proportion of time is spent fetching instructions from the STRam bus. i.e. room to speed things up more using the i-cache.

I'll prepare a modded version for this soon if you're able to do the test for me.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 13, 2013 4:30 pm

Forgot something important - the other thing I did was build linuxdoom for TOS using cross-gcc, since I'll need a way to measure the cost of the game code itself before I try to join BM+Doom together. I had to disable the sound and video stuff so there isn't much to see, but the WAD is loading and the game loop runs.

I tried the pmdoom 0.57 code a couple of weeks ago but had lots of problems trying to compile it and get the dependencies working with the existing configure script. After much futile poking and prodding I went back to the original Id source, and got that running with just a few tweaks.

ldoom.jpg
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: Bad Mood : Falcon030 'Doom'

Postby f030 » Wed Feb 13, 2013 4:53 pm

dml wrote:I'll prepare a modded version for this soon if you're able to do the test for me.


yes of course

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 13, 2013 6:35 pm

f030 wrote:
dml wrote:I'll prepare a modded version for this soon if you're able to do the test for me.


yes of course


Here's the version with the walls flatshaded for this test.

:cheers:
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: Bad Mood : Falcon030 'Doom'

Postby f030 » Wed Feb 13, 2013 7:09 pm

with fastram gives 9.63 fps
without fastram gives 8.64 fps

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 13, 2013 7:12 pm

f030 wrote:with fastram gives 9.63 fps
without fastram gives 8.64 fps


Thanks - I'll post one more test build for this, with the profiler enabled so we can see which bit is most affected by fastram. Will help later.

[edit]

...here it is. Press '5' so the profiler appears and give it 10 mins or so to settle before writing down the numbers. The 'texcache' entry should drop off the bottom of the list by that time. Just the final column will do (xx.yy ms), cheers!
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: Bad Mood : Falcon030 'Doom'

Postby f030 » Wed Feb 13, 2013 9:48 pm

dml wrote:...here it is. Press '5' so the profiler appears and give it 10 mins or so to settle before writing down the numbers. The 'texcache' entry should drop off the bottom of the list by that time. Just the final column will do (xx.yy ms), cheers!


texcache appears after 2-3 minutes and is not readable (flashing) and disappears after 1 minute
after 15 mins BSPwal.. is the last column (not readable, flashing)

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 13, 2013 9:59 pm

f030 wrote:
dml wrote:...here it is. Press '5' so the profiler appears and give it 10 mins or so to settle before writing down the numbers. The 'texcache' entry should drop off the bottom of the list by that time. Just the final column will do (xx.yy ms), cheers!


texcache appears after 2-3 minutes and is not readable (flashing) and disappears after 1 minute
after 15 mins BSPwal.. is the last column (not readable, flashing)


There must be something wrong with the profiler - sounds broken. I'll need to double check it here outside Hatari and we can repeat the test another time. Thanks for trying it.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 13, 2013 10:39 pm

dml wrote:
f030 wrote:
dml wrote:...here it is. Press '5' so the profiler appears and give it 10 mins or so to settle before writing down the numbers. The 'texcache' entry should drop off the bottom of the list by that time. Just the final column will do (xx.yy ms), cheers!


texcache appears after 2-3 minutes and is not readable (flashing) and disappears after 1 minute
after 15 mins BSPwal.. is the last column (not readable, flashing)


There must be something wrong with the profiler - sounds broken. I'll need to double check it here outside Hatari and we can repeat the test another time. Thanks for trying it.


Looks like a repeat of the same problem I had in the mipmap reducer the other day - it refused to work on a real 030, but seemed fine in the emulator. Temporary variables were being written very close to executing code. Move the variables away from the code modifying them and problem goes away...

Seems like a strange mmu/cache/prefetch dirty data rule I forgot about or never noticed before :?

I should go through the code looking for other cases of it before posting any more tests.

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

Re: Bad Mood : Falcon030 'Doom'

Postby f030 » Thu Feb 14, 2013 12:48 am

dml wrote:There must be something wrong with the profiler - sounds broken. I'll need to double check it here outside Hatari and we can repeat the test another time. Thanks for trying it.


thanks for your hard work, i will try to help as much as possible

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Thu Feb 14, 2013 1:47 pm

I have a pretty good idea now of how to join BadMood and LinuxDoom, although there are some difficulties too.

The main difficulty is keeping the two 'world' representations in sync, since the plan is to let the Doom game engine do it's thing, under the illusion that it's renderer is working from it's own in-memory game state but have BadMood monitor this state and use it where necessary, but using its own data structures for the map etc. BM will need to monitor specific state such as moving sector floors and ceilings, or moving 'things' around the map. I haven't enumerated all the things needing kept in sync but those are pretty good examples.

It has to be like this to some extent because BadMood is not Doom - the internal representations of the world are not the same.

By leaving the Doom code mostly alone, it will also make patching easier in future (especially since LinuxDoom isn't the 'best' version of the code). It will be up to BM to integrate as lightly as possible I think, but without making a mess of it in the process.

I got LinuxDoom rendering to the Falcon's screen last night. It's ridiculously slow, even without the 16bit display conversion pass. At some point I'll modify LinuxDoom to use BadMood's entrypoint/init code to set up the machine, display, keyboard etc. and then hand control back to Doom for the game event loop, as if the BM part hadn't happened. This should make it possible to 'play' Doom using the portable code - as a starting point - and then have both Doom and BM rendering output to the same display (shrunk, or whatever). It will then be a gradual process of binding BM's state to Doom's game state, and nulling out the Doom renderer until one has replaced the other.

That's the plan. Will see how it goes in practice. I predict a few things will cause some problems - memory management, level loading events, getting BM to reset properly for multiple levels in one session... some other things of this kind. Apart from that it will probably make quick progress at first and then bifurcate into hundreds of small annoying fixes as things are found not to do what's expected in the BM map :-)

There is still a lot to do before starting this process but at least there is some kind of plan now.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Thu Feb 14, 2013 4:32 pm

f030 wrote:
dml wrote:thanks for your hard work, i will try to help as much as possible


:cheers:

Perhaps this one will work better. Shouldn't have to wait as long for this one to settle - the profiler is reset just before the mainloop starts, after textures are loaded. A few mins should be enough to get sensible numbers.
You do not have the required permissions to view the files attached to this post.


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 1 guest