Posted: Fri Feb 22, 2013 11:53 am
Yoohoo!! Thx! Your method working! Got it working in 3.4.6, dunno why it didnt work yesterday - but i think, its just shows how is important well sleep xD
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:
But still, for 3.4.6 cant use "pointer array" (sry, dunno how its called propertly
), so construction like this:
not works, instead, i need to point to exact texture array, for ex (tex_bricks):
This one works.
update seems that its somehow connected to data initialization, done by crt0? because, this construction works:
Btw, next candidate on tweak is this ugly modulo for angle i used to keep angle in 0-360:
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!
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!