Bad Mood : Falcon030 'Doom'

All 680x0 related coding posts in this section please.

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

Dio
Captain Atari
Captain Atari
Posts: 451
Joined: Thu Feb 28, 2008 3:51 pm

Re: Bad Mood : Falcon030 'Doom'

Postby Dio » Tue Feb 05, 2013 11:09 pm

Actually, I knew that. I think it was in one of the chapters in Abrash's Black Book.

Why I'd got stuck in my head there was actual raycasting algorithm involved I don't know. Sorry.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 06, 2013 9:40 am

Dio wrote:Actually, I knew that. I think it was in one of the chapters in Abrash's Black Book.
Why I'd got stuck in my head there was actual raycasting algorithm involved I don't know. Sorry.


Well my memory of the whole thing has become quite vague over the years and some of the Doom/Quake stuff already gets mixed up in my head. I spent more time in the Quake code than in the Doom code overall. It does suggest I should go through it all again though just in case :-)

User avatar
dma
Atari Super Hero
Atari Super Hero
Posts: 817
Joined: Wed Nov 20, 2002 11:22 pm
Location: France
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby dma » Wed Feb 06, 2013 11:38 am

CiH wrote:Meanwhile, on other retro platforms, developments move apace...
No pressure Doug! :mrgreen:
http://www.youtube.com/watch?v=Y7h3H-_8N_o

No pressure indeed, they flattened the game to wolf3d, no floor levels. :lol: Hangar is barely recognizable.
And I guess this can't take standard DOOM maps without severe preprocessing of those on some tools. :wink:
DarkLord wrote:
kristjanga wrote:Why on earth does this threat not show up in "View active topics" ???

I've seen that happen with other messages threads that were very active. Not sure why.

I suspect a rule for coding topics not to appear in the "active" list.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 06, 2013 1:40 pm

While trying to get a DSP texture unit to work, I spent a bit of time looking at ways to get the textures onto the DSP cheaply enough for the whole thing to be practical for a complex scene (after all it has to be fast with *many* textures, not just one texture).

I recently counted ~20 visplane texture state changes at some bad spots in e1m1, which is just way too many (5kb x 20 = 100kb of stuff to copy into the DSP for every drawing refresh, albeit without any texture packing). This is not because there are actually 20 floor/ceiling textures in the scene, but rather because the visplanes are extracted and 'stacked' for drawing in BSP order - often alternating between floor/ceiling in the process and that is far from the ideal texture order (where selecting a new texture has some cost).

So the obvious solutions to this are:

1) reorder visplane processing (unlikely - not enough DSP space to extend storage of intermediate/pre-defragmentation VPs)
2) leave visplane processing order alone, but reindex the defragged DSP visplane groups against drawing order (much more likely) and have the CPU ask the DSP for specific visplane groups in the order it wants them, instead of being told which one is arriving next.
3) store multiple textures on the DSP in some kind of cache, enough to reduce flipflopping between the same 2 or 3 textures due to unfortunate VP surface processing order.

I think the ideal solution is to do both (2) and (3), while allowing the DSP texture cache to persist across frames and reusing the most recently cached textures first (effectively ping-pong the texture state order at draw time to minimise texture uploads). For a scene with only 2 floor textures that would mean zero uploads, and for 4 textures it would mean ~1-2 uploads etc...

There are multiple problems here needing solved so it will have to be done one step at a time.


It also seems possible store 2 or 3 textures packed in the same 64x64 texel memory space, since the textures are indexed 8 (or less) bits per texel and a 24bit DSP word can store 3 or more of those at once. So that significantly increases the number which can be cached in the memory available (which now seems to be around 8k - roughly 2 texture pages). The texture cache can rotate/mask the 'current' texture selection into the active LSB of the active texture word, which the texture mapper will be able to use directly. The texturemapping fragment I came up with needs clean 16bit indexes so that limits things to 2 textures for the active page, with 8 padding bits always present in the middle byte. But a second, inactive page could pack in 3 textures. So that's a theoretical 5 textures living in 2x 4k pages, before we even get to reduced index depth (5 or 6 bits seems more than enough for doom floors & ceilings providing additional cost is paid for a unique palette LUT per texture).

This 'selector' step will cost something but it will be a lot faster than sending a new texture across the host port. Some kind of tagging scheme could also keep often-switched textures apart in memory, and more rarely-switched-between textures packed in the same footprint, since rotate/mask selection will cost more than a pointer change. That might be a step too far for what's needed here but it's another option.

So already we have split texture state changes into 3 costs - 1) a DSP-local pointer change, which costs nothing. 2) a DSP-local 'selector' texture processing step which costs something, but still relatively cheap. 3) a texture upload, which is quite expensive and to be avoided.

(Textures can also be sent pre-packed, which will cut the upload cost in half but it's still expensive even then)


Anyway not sure how it's all going to end up but those are some ideas, might be interesting for any other Falcon/DSP coders out there wanting to do similar sorts of things with textures.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 06, 2013 3:13 pm

Had a bit of a crazy idea at lunch re: raycasting and making it cheap enough to use directly for building visibility lists for surfaces.

Normally you'd fire one ray for every display column, so that's 320 rays for a low res display. The cost of each ray varies according with the number of BSP partitions it crosses on the way to an occluding surface (i.e. varies quite a lot depending on map, postion, view direction).

However there isn't anything 'interesting' happening between map vertices, where walls meet. There isn't really any point in raycasting every column (other than for texture indexing, which is optional) when the 'BSP state' only changes where splits/vertices occur in the map.

So lets say you had a preprocessed bag of vertices which were known to contribute to all possible visible surfaces from any ssector - all you'd have to do is project those vertices into view space, and into an indexed 1-D buffer, representing the horizontal positions on the display where some surface/window may begin or end. You then just need to fire one ray in-between each pair of vertices, to find the contributing surfaces in that region.

i.e. For an entire region between two vertices, the BSP state will be exactly the same. Only texture coordinates will vary.

Figuring out the vertices would be tricky because it wouldn't literally be map vertices but points where BSP hyperplanes and/or walls meet other hyperplanes and/or walls, but it's certainly doable.

You'd also know where sub-portions of walls begin and end - it would have to be at the first two adjacent vertices where the BSP state is different (recognizable by a state hash collected by each ray's walk).

So in the end you up with a bunch of 3D-2D vertex transforms, and 10-30 rays, instead of 320 rays.

Whether this ends up being worthwhile overall I don't know but it seems like maybe an experiment for another day.

It's very easy to get distracted with this stuff when there are so many things to do. But it seems like there are always things worth looking at.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 06, 2013 3:32 pm

BTW back to reality for a bit - in my last test I saw 7.95FPS on RGB for the default view (on a real machine), using the full indexed/tiling/lighting DSP texture mapper for floors/ceilings, with a single permanent texture (no DSP texture uploads). That's not a bad start but it will get slower by some unknown measure when the textures start getting pushed out to the DSP.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Wed Feb 06, 2013 10:58 pm

Ok, all talk and not much to show until tonight, so here's a first test with DSP pixel shader texturing ...woooo...

It's pretty horrible because there's only one texture active at any one time, the sky and lava is broken, the lighting had to be disabled (it will require the textures to be reindexed to suit the DSP) and I have a tiling issue to fix but at least the DSP shader works properly and textures are correctly coloured via the extreme end of the lighting table, and the CPU is just busy with "move.. move.. move...." all the way home (making it the fastest texture mapping possible, in terms of getting pixels onto screen area).

I had one ugly mistake in my DSP shader fragment, but then it was written without any testing. Fortunately it wasn't a corker and got fixed easily.

It only just scrapes by on my machine and will very probably crash if you shrink the display. It may even just not work on some Falcons. Hatari certainly doesn't like it much. But it runs here on my Falc and is quite a bit faster than BM3.07.

The floor/ceiling texture addressing is also quite a bit more precise than the old CPU version - 8bit fraction is upgraded to 10bits on the DSP.. and could go up to 17bits if needed, not that I think more will help. The extra 2 bits has cleaned up some 'wiggles' on the floor very near the viewer.

BM4DSPT.zip


[edit]

...it may feel slower when looking out windows across big complex scenes - and it probably is, because I had to move the wall processing code out of DSP 'fast ram' to fit the texture shader in there instead. Temporary measure - in the end any performance sensitive code will be paged into DSP fastram before use...
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: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Feb 08, 2013 1:10 pm

Apart from the DSP texturing experiments, have been looking at metrics output from the newly instrumented BadMood engine... and this has highlighted a number of well hidden bugs, missed opportunities and false assumptions that will get sorted out over the next releases.

Ever-growing list of things to fix and improve but it's all good news for making a faster engine...

bm-met.jpg
You do not have the required permissions to view the files attached to this post.

User avatar
dma
Atari Super Hero
Atari Super Hero
Posts: 817
Joined: Wed Nov 20, 2002 11:22 pm
Location: France
Contact:

Re: Bad Mood : Falcon030 'Doom'

Postby dma » Fri Feb 08, 2013 1:43 pm

Again, massive respect given for working on this.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Feb 08, 2013 1:51 pm

dma wrote:Again, massive respect given for working on this.


Thanks! It's a fun project to play with anyway but very nice that you and others follow the progress...

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

Re: Bad Mood : Falcon030 'Doom'

Postby kristjanga » Fri Feb 08, 2013 2:51 pm

dml wrote:
dma wrote:Again, massive respect given for working on this.


Thanks! It's a fun project to play with anyway but very nice that you and others follow the progress...


I log in twice a day to look at this project :coffe:

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

Re: Bad Mood : Falcon030 'Doom'

Postby f030 » Fri Feb 08, 2013 2:58 pm

dml wrote:Thanks! It's a fun project to play with anyway but very nice that you and others follow the progress...


can't wait to see it completed

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Feb 08, 2013 4:31 pm

It will be a while before the upgrades are complete but when that material starts to thin out, I'll start looking at the Doom code and how to join the two things together.

For now it will mainly just be bugs, performance & rendering quality improvements and there still seems to be plenty to do there.

The most recent problem I noticed is that two 'fast paths' provided for wall generation/rendering are not being used often enough - there is a linear interpolator which should be employed for the majority of distant walls but the perspective-correct version is being used nearly all of the time instead. Fixing this will help accelerate the wall processing - which after the floors was the next major cost. The other fast path was for special-case invisible walls (sky or missing texture) which generate no visible wall columns - this probably got broken after 3.07 but has been fixed now.

User avatar
troed
Atari God
Atari God
Posts: 1213
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Bad Mood : Falcon030 'Doom'

Postby troed » Fri Feb 08, 2013 7:26 pm

dml wrote:
dma wrote:Again, massive respect given for working on this.


Thanks! It's a fun project to play with anyway but very nice that you and others follow the progress...


Oh you've got a lot of lurkers I believe - thanks for all the updates on your progress :) I haven't owned a Falcon since 1993 but one of the few things I made was a very very naïve and unfinished "Doom"-renderer nowhere near what you have. This is a fascinating read.
Last edited by troed on Sat Feb 09, 2013 8:15 am, edited 1 time in total.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Feb 08, 2013 10:13 pm

troed wrote:I haven't owned a Falcon since 1993 but one of the few things I made was a very very naivë and unfinished "Doom"-renderer nowhere near what you have. This is a fascinating read.


Well it's great to know there are other people out there who worked on similar things and find something interesting here
:cheers:

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Fri Feb 08, 2013 10:58 pm

So I have fixed the problem with the perspective-correct vs. linear wall generation 'fast path' such that it's using the linear path for the majority of walls now (instead of one or two), without any perceptible distortion. My solution is correct but not well optimized - will do that later as it's a minor cost among everything else.

This was done by measuring the distortion error itself, and selecting the correct path based on that. I think it's important to do this bit properly because the difference between the two paths can be visually significant under the wrong conditions and switching modes on any given wall causes the texture to leap around, even if one or other mode 'looks' acceptable when static.

Perspective correct mapping is often done something like this:

Code: Select all

 a1 = attribute at start of gradient (e.g. texture coordinate, colour, whatever)
 a2 = attribute at end of gradient

 z1 = scene z (depth) at start of gradient
 z2 = scene z (depth) at end of gradient

 t = position on gradient being sampled

 // anti-corrective function - done once before mapping
 az1 = a1 * z1
 az2 = a2 * z2

 // affine function - interpolate z
 tz = z1 + (z2 - z1) * t

 // affine function - interpolate attribute(s)
 taz = az1 + (az2 - az1) * t

 // corrective function, per attribute, yields corrected attribute at pos[t]
 a = taz / tz


Whereas linear is just:

Code: Select all

 // affine function - interpolate a
 a = a1 + (a2 - a1) * t



To measure the distortion caused by choosing linear over perspective-corrected attributes, you can just sample the midpoint of the gradient using both schemes, and find the absolute difference. e.g.

Code: Select all

 // linear sample at midpoint
 aL = (a2 + a2) / 2;
 
 // corrective sample at midpoint
 az1 = z1 * a1;
 az2 = z2 * a2;
 azmid = (az1 + az2) / 2
 zmid = (z2 + z1) / 2
 aP = azmid / zmid

 // distortion = difference between samples
 aDist = abs(aL - aP)


Since for this case we don't care about the absolute value of the attributes (texture coordinates) - only the degree of distortion, a magnitude will work just as well as two sample values and is simpler...

Code: Select all

 // corrective sample at midpoint
 azmag = z2 * amag;
 azmid = azmag / 2
 zmid = (z2 + z1) / 2
 aP = azmid / zmid

 aDist = abs(aL - aP)


However the resulting distortion measurement (aDist) only yields the distortion in 'world space' i.e. world units, centimeters etc. so it will be useful for detecting distortion on walls near the viewer's face - but not very useful for walls which are miles away, and one texel of drift is completely invisible (each pixel might skip 30 texels at a time).

So to get the distortion in screen space, you need one last step:

Code: Select all

 aDistScr = aDist / zmid


Now you can check 'aDistScr' for pixel-scale distortion, and get perfect results.

This procedure only works for walls/surfaces which have both z1 and z2 in front of the viewing plane. Like many 3D calculations, vectors which cross the viewing plane cause things to break down. However it's also true that any wall with at least one Z value behind the viewing plane and which is ALSO visible, must have it's other Z value in front of the viewing plane - and this means it will have a high measure of perspective distortion by implication. So it's sufficient to just test both Zs and shortcut straight to the perspective-correct path if either is negative - for all other cases the test above is used.

Some 68882 code I cobbled quickly to implement the perspective correction part of the test (un-optimized, sorry for funny tabs)

Code: Select all

   fmove.l      umag(a4),fp0      ; umag
   fscale.w   #-16,fp0
   fmove      fp0,fp1
   fscale.w   #-1,fp1            ; umid = umag / 2
   fmove.l      z1(a4),fp2      ; z1
   fscale.w   #-16,fp2
   fmove.l      z2(a4),fp3      ; z2
   fscale.w   #-16,fp3
   fmove      fp2,fp6
   fadd      fp3,fp6
   fscale.w   #-1,fp6            ; zmid = (z1 + z2) / 2
   fmove      fp3,fp5
   fsglmul      fp0,fp5            ; uz2 = z2 * umag
   fscale.w   #-1,fp5            ; uzmid = (uz1 + uz2) / 2
   fsgldiv      fp6,fp5            ; uP = uzmid/zmid
   fscale.w   #16,fp5
   fmove.l      fp5,d0            ; perspective correct 'u' for middle of range


The most obvious optimization for this (apart from converting it from FPU to 68k+tables, or DSP!) is to remove all the fscale operations. Those are left/right shifts used as 2^n muls or divs - mainly to convert to and from fixed point. Since floats keep their 'shift' (i.e. exponent) as a separate value, it's just adding and subtracting from that - so removing them all and applying a single corrective adjustment at the end would achieve the same without any loss of 'precision'.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sat Feb 09, 2013 11:06 am

kristjanga wrote:I log in twice a day to look at this project :coffe:


I think it was your YT vid that made me remember it was never finished :)

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 » Sat Feb 09, 2013 1:32 pm

Hi,

I also follow this thread with much interest.
It's nice to see this project being worked on again, after so many years.

I gave it a try on my Falcon (stock Falcon, VGA monitor), with doom1.wad, default view:
BM307.TTP: 4.8484 fps
BM4DSPT2.TTP: 6.5306 fps & 6.5573 fps (it keeps switching between the 2 values)

With the Falcon overclocked (68030 & BUS at 25Mhz, DSP at 50 MHz), BMP4DSPT2.TTP run at 11.3475 fps.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sat Feb 09, 2013 1:45 pm

DrTypo wrote:Hi,
I also follow this thread with much interest.
It's nice to see this project being worked on again, after so many years.


Thanks - I haven't been releasing source for the recent changes as yet but I will when it settles down. Too much mess and change still...

DrTypo wrote:I gave it a try on my Falcon (stock Falcon, VGA monitor), with doom1.wad, default view:
BM307.TTP: 4.8484 fps
BM4DSPT2.TTP: 6.5306 fps & 6.5573 fps (it keeps switching between the 2 values)


The VGA version seems to leave the bottom 40+ pixels open on the display which is a bit wasteful on the bus. I'll fix this at some point later on so it should go a little bit faster. Unfortunately VGA will always be a bit slower than RGB because the bus load is higher with that pixel rate.

It runs quite a lot slower on Hatari still and the DSP/CPU host ratio timings are different too - some changes can only be verified on real kit. For most things I can still test quickly in Hatari though.

DrTypo wrote:With the Falcon overclocked (68030 & BUS at 25Mhz, DSP at 50 MHz), BMP4DSPT2.TTP run at 11.3475 fps.


Cool - while the current DSP floor texturing is a slightly shaky optimization, it should be reliable so long as the DSP is accelerated proportionally relative to the CPU & Bus (in fact, so long as the DSP has the speed advantage it should be fine, so an overclocked DSP on its own should be good too). However I didn't try this yet so it's good to know!

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Feb 10, 2013 5:27 pm

Today I got a mipmap filter/reducer integrated into BM's 'flat' texture cache stage, so all floor/ceiling textures now have a full set of mip pages from 64x64 down to 1x1. This includes colour remapping so all mips are still relative to the Doom 256 colour palette. This is temporary - soon each texture will have it's own sub-palette and lighting table so the remapping part will change again later.

I had to do the mip reducer/remapper in 68k which didn't help - the whole BM engine is still all assembly language. Maybe when I move to GCC+VASM and BM gets joined onto the Doom C code I'll start using C for supplementary/support modules like this, which aren't directly involved in rendering - it won't speed the code up but it will definitely speed me up :-)


Next thing I will try to do is get the mip pages onto the DSP, and get the texture mapping unit to select the correct page for a given z/distance. If/when this is all working the floors and ceilings should render more cleanly, with a lot less swimming. It may also open up the possibility of a fast path for the 1x1 page size, and for mip pages which can be detected as having near enough a single colour - filling those spans with a single colour directly and without involving the DSP.

The texture mapping unit still needs to be upgraded to handle the different page sizes and tiling for that but it should be ok.
.
.
You do not have the required permissions to view the files attached to this post.

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 » Sun Feb 10, 2013 9:22 pm

dml wrote: Unfortunately VGA will always be a bit slower than RGB because the bus load is higher with that pixel rate.


There is an easy way to gain speed on a VGA when doubling the pixel horizontally. You don't have to double the pixels with the CPU, just use the slowest pixel clock and you get an actual resolution of 160 pixels. So there is less memory writes from the CPU. The VIDEL uses also less bandwidth (same bandwidth usage as 320pix mode in RGB).

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Feb 10, 2013 9:52 pm

DrTypo wrote:There is an easy way to gain speed on a VGA when doubling the pixel horizontally. You don't have to double the pixels with the CPU, just use the slowest pixel clock and you get an actual resolution of 160 pixels. So there is less memory writes from the CPU. The VIDEL uses also less bandwidth (same bandwidth usage as 320pix mode in RGB).


I think the old version picked that setting up if you had configured the low res modecode to use it via Videlity/BlowUP etc..

However it seems unlikely anyone actually did this or would do it to run one program... (I did it once myself to test it but that's probably the only actual case ;-) so it's probably a worthwhile change, yes. I'm not very sure why it doesn't do this if it does handle double-line itself. Looks like an oversight, or that bit of the code predates me noticing the setting.

Thanks for pointing it out. Will make the change before it's done.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Sun Feb 10, 2013 10:09 pm

Based on tests so far and the various Videl tweaks available, the best 'resolution' for BadMood on a base spec machine will probably be 256x168. That means opening the borders and using slow dot clock on VGA (see last post) or double-written pixels on RGB. This should be realistic I think.

More time is now saved by eliminating wall columns than floor runs, and the vertical resolution is already low at 168 - dropping it looks ugly. So this seems to be the best mix for a decent framerate while still being able to discern whats happening on the screen, even if it seems suboptimal for rendering on RGB.

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

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Feb 11, 2013 11:58 am

As of last night, mipmap selection is now working for floors & ceilings, based on screen-space horizontal texel rate for any given line of the current visplane surface.

The mipmaps are not yet being transmitted to the DSP so all mip levels >0 render incorrectly (only the nearest mip is correct, as can be seen in the images below). This will be fixed when the new 7-page mip format is adopted in place of the default single 64x64 texture being used at the moment. It *should* be easy to make that change and address the correct mip page since everything else has been solved already... the unknown part is whether the extra cost of sending mip pages will offset DSP texturing optimisation in a negative way. Only way to find out is to try it. If it does cause an impact it can be made optional anyway - but it's nice to have mip-filtered rendering if possible :-)

I also thought of a way to get a sort of 'hybrid trilinear' filtering using the nearly same system but it will probably impact performance too much - it's not at the top of my list of things to do immediately.
.
mms2.jpg


mms1.jpg
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: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: Bad Mood : Falcon030 'Doom'

Postby dml » Mon Feb 11, 2013 7:36 pm

MipMaps working, bug in tiling textures fixed. Demo attached.

caveats:

- floor/ceiling (visplane) textures still not lit
- still only one visplane texture at a time
- visplane texture mipmaps are reduced against the original Doom palette which causes loss of detail - 2b fixed later
- mipmap selector not tuned for distance, but it's close enough for now
- somewhere along the line, Doom2 WAD support broken. invisible walls everywhere :-z later...

mf3b.jpg

mf7b.jpg

mf2b.jpg

mf5b.jpg
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 3 guests