I just got first test run - for now it seems to give +1 stable fps, but im sure its only beginning.
update after few minor "tweaks", its even +2 fps, and much smoothly movement than before! Here is binary:
raytest4.bin
raytest4fs.bin "fullscreen" version (using SGDK bitmap routines - seems even more smooth!!)
Thats, how it works for me:
Code: Select all
while( heightY )
{
register u16 c = texturePtr[ textureY & ~63 ];
setBMP(screenX, offsetY, c);
offsetY += 1;
textureY += textureInc;
heightY--;
}
Code: Select all
const u8 *textures[] =
{
0,
tex_wood,
tex_bricks,
tex_bird,
tex_bricks2
};
...
blablabla
...
register u16 *texturePtr = &textures[ slice->textureId ][ slice->textureOffset ];
Code: Select all
register u16 *texturePtr = &tex_bricks[ slice->textureOffset ];
update seems that its somehow connected to data initialization, done by crt0? because, this construction works:
Code: Select all
u16 *textures[5];
blabla
void main(){
textures[0] = 0;
textures[1] = &tex_wood;
textures[2] = &tex_bricks;
textures[3] = &tex_bird;
textures[4] = &tex_bricks2;
costab[(((angle % 359) + 359) % 359)]; //somehow just "% 359" not enough in this environment and gives wrong modulo
I suppose, that its produce very ugly asm code (to be true, didnt looked), and its happens three times per each one vertical line - need to transform my sincos arrays to some range which is pow 2 aligned, so instead of it use just one logical AND. for ex:
costab[(angle & 511)]; //costab precalc array for -2pi/2pi as range 0-512.
update did it - it give little boost but also few minor rendering artifacts:
raytest5.bin
raytest5fs.bin "fullscreen" version (5 to 12 FPS!)
Also need to try to somehow force drawSlice and my setBMP to be inline. As my other test (just simple draw 64x64 texture on screen) showed, that doing, what setBMP does, inside of drawing cycle (instead of calling setBMP), gives +4 fps. But setting setBMP to inline didnt gave same boost, so, i suppose, gcc ignored this inline...
Thank you very much!