Ok. I see two reasons to have floating point faster than fixed point :
1) Your test function is optimised very cleverly by the compiler. If you test is something like :
a = 3.141592
b = 6.666
c = a * b
The compiler is able to precompute 3.141592 * 6.666 for the floating point version of this...
The cheese as nothing to do with confusion, that's a French frog that said that to you :P ! Indeed, yes, you right, at least recent GCC versions (4.x.x) are able to generate optimized code for the operations implying float constants.
Well, I think you don't use correctly fixed point. Doing software floating point operation is MUCH slower. Just compare the assembler code needed by an addition, a multiplication, or a square root ! And the difference is even greater when the fixed point usage is implicit like in the Bresenham...
Yeeeeeeaaaaaah, got it ! I was listening Born to be wild, I was reading the SDL code source, scratcing my head, and... voila ! Hardware accelerated rectangle blitting ! Now I'am yelling in my room, jumping around :D
The point I missed : the blitter understand only PHYSICAL adress, not the mmu...
I'm trying to use the blitter to fill rectangle with a single color. By reading the harware optimised SDL, I do this way :
1) Magic to enable the blitter operations
gp2x_mem_fd = open("/dev/mem", O_RDWR);
blitter_regs_32 = (unsigned int*)mmap(0, 256, 3, MAP_SHARED, gp2x_mem_fd...
Yes, raycasting is perfect for a 3d illusion (only 4 degrees of freedom, 5 with some works), not for true 3d (but it's possible, check the Ken Silverman Voxlap engine). But why fighting for true 3d when the illusion is good enought ? For a fast paced fps, I think it's okay.
Well, before focusing on assembler, MMu hack and the blitter, focus on the algorithm. When using a vector instead of a linked list (for random index insertion as instance), even the most optimised vector on an overclocked CPU is slow. 'O(1) versus O(n)' or thing like this before anything.
:D Got it ! I'am not that ignorant in computer science, but a real noob for the low level stuffs. Here it is my self answer, so that other newbies like me will find their way in less time than me.
What I was searching is : the interrupts code used to call a given function of the Linux kernel...
I made for my personal use a little C library, in the spirit of the Rlyeh lib : no C standard lib, simple memory management withou mallocs. But I still need to speak a little bit with Linux. Currently, I ripped an assembler source code from Dzzz tutorials. Here it is the beast...
Finite state machines could enougth to control such LCD games, don't you think so ? You will a have a generic emulator of LCD games. An LCD game is a finite state machine with a picture file. My 2 cents.
Actually, I do like Squidge said : after each vblank, I grab the 0x1184 register. But I was quite afraid to miss buttons events, leading to poor game controls. Anyway, you true, 50 hz is not so bad sampling frequency, Keep It Simple Stupid... So I will keep this way.
Ok, after some further readings, it seems that catching the interrupts like in the good old DOS time (int 9 to be precise) is not possible under good OSs like Linux. So my question is now :
* In the "without SDL" case, how do you handle the keyboard and joysticks event ?
Hi all !
I'am just beginning to get into the GP2X development, learning by making tiny demos. I want to bypass the SDL, to get a full freedom and speed (and also pain :P). My actual main problem is to get the events from the keys and the joystick.
what I do now
Direct read of the keys...