Search results

No it doesnt. But as anything with SDL it seams quite easy according to: http://www.libsdl.org/docs/html/guideinput.html Having no joystick at disposal I cannot do this myself for now.

Ok, that's probably the problem. If you lower the resolution (for instance, 400x240!) will the pandora zoom it in fullscreen mode? That would be ideal.

Hum no, it's actually rendered in software (thus the speed issues :-))

I'm surprised you have so much speed issues on the openpandora since on the N900 (a similar hardware AFAIK) the speed is good enough. Do you compile with -ffast-math, -fomit-frame-pointer and of course -O3 ? Also, what screen resolution do you use ? The GlES version will not come before...

Hi! At first sight, it seams your binary of fachoda complex is not fast enough. The simulation steps (including collision detection) is done at every frame, so if the frame rate is too low the ground collision detection happens too late, the plane being already far under the ground and thus...

CLisp compiles on ARM but outputs bytecode only. For native code, you have to look for a Lisp->C compiler. ECL does just that, and is usable. You have also severall Scheme compilers available, of which chicken scheme is a very pleasant one (also : MZScheme, gambit (but compilation is very slow)...

... the thing is, depending on the cleverness of your compiler and how the NOT_EXIST and BATTERY macro's (if they are macros) are defined you may in fact be ending up trying to "||" NOT_EXIST with the value of foe[i.].spc, and then check if that value is equal to BATTERY "||"'ed with foe[i].cnt...

First, is it C or C++ ? Then, there is an unmatched parenth at the end of the for block. Obviously you edited the block to remove something you believed was irrelevant, but due to the very nature of this bug I would really like to see the whole function, however big. Also, how is...

A block based renderer may be affected by the fact that memory writes are slower when far away (when not in the same "bank", I would say). Refer to this thread on that topic : http://www.gp32x.de/board/index.php?showtopic=32088 Requires testing to be sure, though.

Other tricks you might want to consider, extracted from gpu940 : - use the stm instruction to write several pixels at once (faster writes) ; - don't divide (linear interpolation is OK for most polys) ; - if you have to divide, cache some results (some like DX/DY are reused from poly to poly) ...

Here, you are compiling for the gp2x. In general, when compiling for the GP2X, I always define NDEBUG, so that all the assert() calls vanish. Normally, the gp2xenv.sh scripts does this, by defined CFLAGS with "-DNDEBUG" (amongst many other things). I suggest you source this script before...

Different address for odd and even lines in your GP2X video mode ? I don't know what the default video mode is, but it may be using this feature.

Why do you need floating points for alpha ? Is alpha not always between 0 and 1 ?

There is no such thing as a "binary" mode in Unix, so the b flag is ignored in the loader. It might be useful in the program that saves the data, though.

Hi Zodttd ! gpu940 is going more and more GL oriented. For instance, I'm about to remove keying and add a better blending support. Unfortunately I have not much free time ATM, so everything is going very slowly. About gpu940 versus HW SDL : I never used HW SDL, but like I said on the mailing...

Yes this is planned, but no time for it right now. (BTW, looked strange to saw a thread started by Epicenter)

K&R all the way ! If you need more precise informations, get the Harbison & Steele. It you need more precise informations, get the normative reference. You won't need anything else than those three.

Order of lib matters : the linker takes lib from left to right, and only fetch symbols that are still undefined. If you use "-lfoo -lbar" and if bar use symbols of foo he don't know they are in foo, and complains. So, order your libs properly (SDL at the end), or use the magic command line...

Feel free to contact me via email or PM if you want. Also, you can send me your code sample so that I can have a look. There's also a user mailing list for gpu940 (https://mail.gna.org/listinfo/gpu940-users/) which you can subscribe to if you plan to use the lib in the long term - email is...