GP2X Stppc2x News


ledow

Member
Joined
Jan 6, 2008
Messages
430
Age
45
Location
UK
Website
www.ledow.org.uk
Just a heads-up for anyone interested in STPPC2x. I'm working on a big version 1.0, that'll definitely have the following:

- Integrated game menu - you select the game and it loads instantly. All games are contained in one program.
- Whole distribution takes up less than 3Mb!
- New internal menus that hold lots of new options, including a "saveslot" menu.
- Easy saving and loading of "presets" (difficulty levels).
- "Perfect" display of the games (no more horrid-looking parts - they are pixel-for-pixel the same as the Windows, etc. versions now) - also Solo shows up properly now.
- Some games use the 640x480 mode (with appropriate jiggery-pokery) so that they are clearer to see.
- Background music (easily turn-off-and-on-able).
- A small change to "map" (by user request) to show "unchangeable" regions.
- Undo and Redo buttons (can even undo an accidental "Restart Game")
- Lots of minor bugs fixed.

I'm hoping to add some other larger features (which I don't yet have working sufficiently) such as:

- Switching to a "cursor key" input system (using a menu option). This will let you press Up on the joypad to mean "Up" in games like Sokoban, Maze3D etc. The mouse-emulation will still be the default, though.
- Interruptible game generation (so if a game takes ages to build and you want to change your mind, you can).
- Auto-save on exit (so when you quit a game and then go back to it, it automatically "remembers" where you left off).

I don't know when it will be released, but just to reassure people that the GP2X's "death" is greatly exaggerated. :D

More technical details, news, ramblings, "what's to come" etc. are available on the STPPC2x development blog: http://stppc2x.blogspot.com/.
 
Loving your work, and looking forward to this.

Not that I care, but the last few versions have been a case of "everything works... except for Mines". Has that changed? It's becoming a comforting constant, like a warm blankie. :)
 
Cool, i played alot to this and all these future features sound very good, i hope mines will work too. :p
 
(In a Muttley voice:) Sussing, frussing,...

Yes, I'm still working on mines. The bloody thing is a real pain. I've tried every compiler switch I can find (unsigned chars, packed structures, etc.) and it doesn't make any difference, so it's a subtle bug somewhere in the actual code that the compiler compiles perfectly. But I can SEE the difference almost immediately when the games are run on PC/GP2X. A +1 turns into a -1 before the game even starts. Unfortunately the code recurses (calls itself) a lot, so the change could happen at any point. I *do* intend to fix it for v1.0 but it's not done yet. I'm just dreading having to single-step the code through on ARM - just the SDL interface is 4000 lines, before you get to the games themselves!

Having said that, I've got a growing list of "asserts()" (where the programmer has put in a line to say "If this happens, something has gone wrong with my logic") that I've hit on in the original code that are nothing to do with my code (things like games hitting assumptions on generation with certain sizes etc.). At some point, I intend to feed those back to Simon Tatham too, because he should really know about them. I've also hit a couple of definite bugs inside the code where the programmers haven't noticed (mostly in the unfinished games). They should be fixed too. They're things like memory leaks and size assumptions, mainly.

I've also had to fiddle with a few of the games now and will have to fiddle more with the introduction of "interruptible generation", so I'm gradually getting the feel of how it works from the games-end, which I haven't needed to know up to now but which is making finding bugs in the games themselves easier. Just have a look at some of the recursive generation code in some of the games - it's like a mathematician's nightmare smashing headlong into a computer programmer's nightmare.

Anyway, mines is certainly on the agenda, right at the very top, but I assumed people were getting bored of me keep saying it, so I showed you the other stuff I've been working on too. :)
 
Ah-ha!

Right, FINALLY. I got you, you mines-bast**d. FIXED. FIXED. FIXED. Version 1.0 will have working "mines"! Guaranteed.

screenshot.png


Okay, for some reason, the particular version of gcc on ARM that the Open2x development environment uses does not treat an relatively-undocumented (and technically "broken") use of memset on the ARM platform the same as it does on x86. I think it's the alignment of ARM but I can't be bothered to check the exact technical details know that I have found it.

CODE
void * memset ( void * ptr, int value, size_t num);
Sets the first num bytes of the block of memory pointed by ptr to the specified value (interpreted as an unsigned char).


Notice the "unsigned char" bit. So when you do what mines.c was doing: memset(a pointer, -2, a number) it works perfectly on x86 (and all the other supported platforms, including MacOS, Palm, etc.) but does this on ARM:

CODE
"-1 -2 -2 -2 -1 -2 -2 -2 -1 -2 -2 -2"


Which buggers up mines! The fix is not to use memset but to fill the array manually - you get the proper result and mines no longer crashes but "just works". There were three places, only in mines.c, that do similar things. It seems to work fine for the other uses which are mostly -1's.

This fix was found by the following method:

1) Write original author of mines.c a long begging letter with lots of technical details on the problem
2) Recieve reply with basically says "No idea, can you print out the contents of X at line Y for me to look at?"
3) Edit code to print out contents of X at line Y on both PC and GP2X.
4) Gather debug logs from both platforms and compare.
5) Draft another long begging letter which says "This is what I got".
6) Just before hitting Send with large debug logs attached, notice that there is a pattern to the what-should-be-empty array.
7) On a hunch, gradually keep shifting the debug check higher and higher in the code, eventually placing it immediately after a memset.
8) Spot the problem (memset arrays aren't actually uniformly memset)
9) Google the definition of memset which includes the "unsigned char" line.
10) BELLS RING.
11) Search for all memsets with negative parameters and replace with for() loops.
12) Test on PC and GP2X.
13) Rewrite email to Simon Tatham, including a patch and problem description and press Send.
14) Kick self repeatedly and hard.

Anyway... it's fixed. Mines works. Finally. Can't believe it was something so stupid. Multiple human error, because obviously nobody who's touched the mines code had ever noticed the error before and only a compile on an ARM-based device showed it up. Patch winging its way to Simon Tatham for inclusion in the main code. Sigh of relief. Celebration game of mines.

Now, who's got the champagne?
 
Hehe I just looked through the mines code before reading the last message in this thread, hoping to find a misaligned structure of some sort, maybe a cast to int pointer of a char pointer but wow I read the last post after coming back having seen nothing.. Nice work! Would have never guessed memset would display such odd behavior. I want to research this more but can't.. am at the library, no time.
 
Senor Quack said:
I want to research this more but can't.. am at the library, no time.
I posted a complete run-down of the problem in another thread in Developer's Corner... have a look if you're interested. Basically it's the libc in Open2x that is "faulty" and doesn't do memset on ARM properly. Workarounds are simple (starting with "don't do it", and ending with just a simple cast to unsigned in every call to memset) but it's really a lib issue, apparently.
 
Last edited by a moderator:
Back
Top