View Single Post
Old 09 January 2018, 21:56   #21
LaBodilsen
Registered User

 
Join Date: Dec 2017
Location: Gandrup / Denmark
Posts: 79
Quote:
Originally Posted by britelite View Post
I had some spare time and decided to implement mipmapping to the rendering, resulting in getting rid of displacements when reading the texture. So, now the code is pretty much:
Code:
...
move.b (a1)+,0(a0)
move.b (a1),160(a0)
move.b (a1)+,320(a0)
...
and for really up close walls (zoom factor >2.0):
Code:
...
move.b (a1)+,d2
move.b d2,0(a0)
move.b d2,160(a0)
move.b d2,320(a0)
move.b (a1)+,d2
...
With the stream I've been using this gets the speed to around 1.7-2.5 frames (including blitter clear of buffer and c2p), while the previous version barely had a best case of under 2 frames.

The routine still only renders bytes, so next up would be to try out chb's method of rendering in pairs. With this approach I might also try turning the framebuffer 90 degrees, so I could do the writing with pre/post-increments instead of displacements, saving up a few additional cycles, as an additional blitter pass will anyway be required for handling the byte-pairs.
Nice.. So all the work i just did to try out this:
Quote:
Originally Posted by britelite View Post
Could also be a good idea to have a look the cases for zoom factor <1.0, to see if a combination of post increments and addq.l #value,(a1) could speed up the rendering, like:
Code:
...
move.b (a1)+,0(a0)
move.b (a1)+,160(a0)
addq.l #1,a1 ; skipping an additional byte
move.b (a1)+,320(a0)
move.b (a1)+,480(a0)
...
Is wasted , just kidding. i tried optimizing by hand, just to test, and the result was positive, as it did speed up the rendering to more cases under 2 frames. of course now that you have changed to mipmaps, this is not needed anymore.

btw: in your code, it seems the chunky buffer is segmented for every 4 pixels (0,1600,3200,4800), is that to easier do C2P with the blitter?
LaBodilsen is offline  
 
Page generated in 0.04024 seconds with 11 queries