SpritesMind.Net

Posted: **Wed Feb 27, 2013 8:37 pm**

Great! I'll check if it fixes the problem in the init for the demo.

Posted: **Wed Feb 27, 2013 9:21 pm**

And it works fine now! No need for the kludges to get it running on real hardware. It's even a whole FPS faster now!

raytest8-joe2.7z

Posted: **Thu Feb 28, 2013 12:16 am**

Glad to hear the bug has been fixed and it's a very little bit faster ^^

Posted: **Thu Feb 28, 2013 6:53 pm**

Great work, Chilly Willy and Stef!

Posted: **Thu Feb 28, 2013 7:37 pm**

You can get just a little bit more speed by replacing the sqrt in the raycaster. For peekpoke's code, that's like this:

Code: Select all

//        s16 dd = (iSqrt( dx*dx + dy*dy ) * (costab[offsetAngle & 511]))>>7;
        s16 dd = (distance_approx( dx, dy ) * (costab[offsetAngle & 511]))>>7;

For my SCD demo, it's like this:

Code: Select all

//        uint32_t dd = ( ( iSqrt( ( F2I(dx) * F2I(dx) ) + ( F2I(dy) * F2I(dy) ) ) ) * ( FIX_COS( offsetAngle ) >> 8 ) ) >> 8;
        uint32_t dd = ( approxDist( F2I(dx), F2I(dy) ) * ( FIX_COS( offsetAngle ) >> 8 ) ) >> 8;

where approxDist() is the same function put into wolfdemo.h since the SCD demo doesn't use sgdk.

Given the resolution and "quality" of textures here, you can't really tell the approximate distance from the real thing.

Posted: **Fri Mar 01, 2013 4:04 pm**

New version (more cosmetic changes):
raytest9.bin

Posted: **Fri Mar 01, 2013 4:39 pm**

This is cool stuff !

Would it be possible to make the walls higher to compensate for the wideness ? In one raycaster I did long ago it was matter of changing a constant

Posted: **Fri Mar 01, 2013 5:34 pm**

Thank you!

Exactly - just a matter of changing one variable

But, higher walls, more pixels to draw - it eats valuable fps xD

Special Edition:
raytest9h.bin

Posted: **Fri Mar 01, 2013 6:06 pm**

Yeah, that cuts well into the framerate.
What about making the window smaller horizontally, so that there are no black lines ?

Posted: **Fri Mar 01, 2013 6:18 pm**

That's why I doubled the pixels vertically on my SCD demo - just a bit faster than actually drawing the slice at twice the height because you only do half the texture fetches.

I like the new textures - actually looks somewhat like the start level.

Posted: **Fri Mar 01, 2013 6:53 pm**

TmEE co.(TM) wrote:Yeah, that cuts well into the framerate.
What about making the window smaller horizontally, so that there are no black lines ?

Here is version using my bitmap routines (1:1 pixel formatt) - slower than Stef's bitmap routines. This exact version uses old sgdk, so have vdp bug - will not work on real hw:
raytest9bmp.bin

Posted: **Fri Mar 01, 2013 7:05 pm**

So you cannot push the pixels closer together on Stef's code ?

Posted: **Fri Mar 01, 2013 7:14 pm**

TmEE co.(TM) wrote:So you cannot push the pixels closer together on Stef's code ?

Cant give u definitely answer right now

As i understand, Stef's bitmaps routines are fast, because they treat pixels as bytes instead of nibble (8 bit, instead of 4 bit) - so because of this bitmap is "vertically interlaced" on screen. But to be true i didnt looked into his routines very closely... I may be completely wrong! But even if i right, probably, here is some way to switch it to 4bit mode... If Stef read this, and its not difficult for him, he may comment on this issue.

Posted: **Fri Mar 01, 2013 11:17 pm**

If the lines in-between visible columns are transparent, you could display the framebuffer on both layers, with one layer shifted to the left one pixel. That would fill up the space between columns and make it just look like it was stretched horizontally.

http://imgur.com/gNXZpe5

Posted: **Sat Mar 02, 2013 9:28 am**

Thank you, TapamN! Your idea looks very cool - ill try to implement it.

SpritesMind.Net

Genny and 3D