Search results

Email me a save from just before the point where it stops working and I'll see if I can spot what's going on.

Spare some change guv'nor?

This has already been done to death. http://gp2x.projectinfinity.org.uk/news.php http://wiki.gp2x.org/wiki/Common_User_Inte...Recommendations

Hard drives need to be formatted with fat32, and it's unlikely that your 300gb drive is formatted with fat32 (unless you know what you're doing windows won't let you format 300gb using fat32 and it will just use ntfs instead).

Older consoles/computers used resolutions like 320x240 which meant that they could display the full screen on both the odd and even frames and have a 60fps progressive display (no need to interlace something thats shorter than the height of the screen).

You only have the source code to a game that runs in a particular engine. You need to port the engine, not the game. Think of is as a more advanced type of level editor - what you have written is like creating new levels for a game. To run those levels on a different machine you would need to...

Frame rates are an artificial creation. Eyes work in a completely different way to computer hardware, and depending on exactly what it is they are viewing they adjust from only seeing low 'frame rates' (for looking at detail I'd guess) to seeing very high 'frame rates' (a few thousand? can't...

You used a game creator, so no you can't port your game. It's not your game that needs porting it's the game creator engine that does. If that could be ported then any games that are written with it should work.

It probably has nothing to do with your firmware (changing firmware should always be seen as a last resort, not something to try just for the hell of it). Check the menu settings again. If you've not enabled usb devices then that is your problem.

http://www.gp32x.de/board/index.php?showtopic=36870&hl=

Have you enabled all the usb settings from the menu yet? They're off by default. Also, not all software supports usb controllers so make sure you're using compatable emulators.

SDL_FillRect uses x,y,w,h, but you're using the x2 and y2 values from boxColor instead of w and h. As for boxColor not working, try making sure that you're not drawing off the edge of the screen (can't remember if boxColor likes that or not), and I don't have time to read through and find out...

There's GLBasic, but you'll probably still need to rewrite a lot of stuff because most implementations of Basic are completely different from each other.

Don't get too excited just yet. As Ark says, this is untested and just my guess at what could be causing the problem (based on me making the same mistake with sdl a few weeks ago). It was 4am and I'd had no sleep, so the chances of me misreading something could have been quite high ;). Also...

I've just taken a quick look at pucks code (if that's what these problem emulators are using), and it seems that left is set if the value of the axis is <0, right if it's >0 and they're both unset if it's 0. I suppose there's always a chance that the movement could be so quick that the 0 value...

You're creating a screen with 2 buffers, writing to only one of them, and then you have a while loop that does nothing other than flip between your written to buffer and the empty one. You either need to write things to both buffers, or only call flip once to get things displayed then don't call...

The built in sdl libs (ignore the wiki, sdl itself has been built in since day 1 but some of the additional libs like gfx weren't always there) only work with an older slower version of gcc (3.3 or lower I think). To use the newer gcc in devkitgp2x you need to add -static when you link so the...