Stppc2x Beta5

[ledow]

The next step on my efforts to port Simon Tatham's Portable Puzzle Collection to the GP2X. This is now a set of 30 addictive logic and puzzle games (3 are new to this release!). Some are old favourites (like sudoku, sliding puzzles and minesweeper) and others you may not have seen before. An awful lot has changed in this release, not just some extra games, so make sure you read this whole thing!

You can download BETA 5 of STPPC2x immediately from the main website or from the GP2X archive (which may take a while to change from Beta4 to Beta5).

PLEASE NOTE: This release is a bit of a leap in how the collection operates. It is recommended that you create a new folder for this version - the directory structure has changed significantly. INI's and SAV's from previous versions are, of course, still compatible but may need a little renaming (same_game.ini to samegame.ini or rect0.sav to rectangles0.sav, etc.)

So, what's new? First, we have a fantastic menu drawn and programmed by juanvvc:

Many thanks to juanvvc for the great work on that, I think it really makes the collection look much neater and more professional. In fact, it works so well with the games that it is now the default menu, even on my own GP2X. Eventually, it'll get merged into the program itself so that there's just one piece of code for the whole thing.

The games are now just one program and one menu to run that program. If anybody still wants to be able to run each of the games individually as they did before, give me a shout, because I still test the games individually on my own machine. If there's demand, I can do two different releases - one with a single executable, one with an executable for each game.

There are also three new games: Slide, Sokoban and Maze 3D.

[cut]
Slide is an "unfinished" game from the original collection that, as far as I can tell, is working perfectly but can be a bit slow to generate new games (if it takes a *long* while to startup or make a new game, don't worry - it hasn't crashed, it's just slow! I had to make a loading screen just so that this game doesn't make people think it's crashed!).

The object of the game is to slide the highlighted piece into the gated area by moving the blocks around. It sounds easy but it's not!

Sokoban is another "unfinished" game. I'm sure you have all seen this before - push each of the brown "crates" onto one of the circled areas. It is working perfectly but the levels it produces are randomly-generated and therefore usually very simple. But it plays well, so why not.

Maze3D is a third-party game from <a href="http://www.edlsystems.com/~eddy/">Eddy Macnaghten</a>. You have to find your way through a 3D maze (2D if you change the options) to find the yellow sphere exit. It can be a little confusing at first. I recommend that you play mazes with "height" of 1 (i.e. a 2D maze) to get the hang of it, before trying smaller 3D mazes (e.g. 3 x 2 x 2, the smallest possible size). You can happily play up to 20x20x20 mazes (it's actually surprisingly fast to generate them), but you'll never find your way out of one that big without the help of the "solve" function, which puts a yellow thread on the screen which you have to follow to find your way out!

Maze3D isn't perfectly suited to the GP2X (it really needs a larger screen, and a better control system) but given that the code for it was last written in January 2006 and that I had to change one (trivial) line to get it to work on the GP2X, it's amazing it works at all! I also tweaked the code a bit more to allow me to put it neatly into the collection and to adjust the colours slightly.

I think Maze3D shows the power of these games as not just "a collection" but an entire puzzle game API that can be used to write lots of different games and get them ported to many platforms simultaneously, without having to write a single line of machine-dependent code. If anyone knows any other third-party games that use this puzzle engine, please shout. If anyone writes a new one that uses this engine (there is example code, documentation and I'll even give you a hand), shout louder!

STPPC2x has also been relicenced as GPLv2. This allows me to add in some useful code from various places. This was prompted by juanvvc thinking the collection was GPL and ended up with me deciding to change the license to GPL!

This beta now has 29 fully-working games, the only remaining one is completely unplayable on the GP2X - mines, a minesweeper clone. Don't run minesweeper - it'll crash. And yes, it's annoying the hell out of me as well that it doesn't work yet.

The full changelog from the previous Beta also includes items such as:

- A single monolithic executable for all the games.
This drastically reduces the size of the collection (from 17Mb to about 3Mb - mostly due to the fact that each game carried 0.5Mb of static SDL code with it). And eventually I'll be merging the menu with the games directly (at the moment, the menu spawns the games individually from the monolithic executable).

- A new "loading" screen because the new game Slide can take forever to load initially and people might think it has crashed.

- Several optimisations to try to reduce CPU use including: Faster and threaded events code, more compiler optimisations, making the main loop sleep a bit more, tricks like the loading screen to make people "think" it's faster, etc.

- Changed the background colour (well, I had to keep juanvvc happy after he made the menu for me!).
White lines are now more easy to see in Bridges, Inertia etc. The GP2X is just colour-inaccurate and the colour difference never showed up properly before (if you tilt the GP2X screen up on the older versions, you can see the white lines were always being drawn but showed as nearly the same colour as the background). I also had to change Maze3D's default colours because on a PC they look fine and on the GP2X, they all look white!

- Lots of tiny interface updates

Feedback is appreciated (especially from F-200 and USB mouse users) and full source code is available from:

http://www.ledow.org.uk/gp2x/

Note that this is an unofficial port - so please don't bother Simon Tatham with any problems, although he is aware of the project's existence.

[/cut]

There is also a "development blog", which will contain articles about developments to come etc.

 

[peelie]

hi

i think there are some files missing in the zip!

 

[ledow]

Bugger. Should be fixed now. At least on the main homepage - archive might have to wait a while. That's what I get for zipping without using the right parameters

 

[Oncer]

It's strange that I missed this game collection for so long. Normally I download everything that begins with Simon without even thinking.

Seriously, this is great stuff. Some of my favourite puzzle games for the GP2X. And then there's still lots of additional ones which I'll have to try.
The only thing I have to say is that the controls are a bit unintuitive for a handheld device. Especially on the F100 where pushing the mouse cursor around is really painful.

 

[MisterBrisby]

This is awesome. Who needs Dr. Kawashima.

 

[senquack]

Hehe this is awesome, great work. I remember, I think it was you, who was a bit unsure of yourself at first and then you steadily bust out versions and now it looks perfect. Can't wait to try it.

 

[ledow]

Hehe this is awesome, great work. I remember, I think it was you, who was a bit unsure of yourself at first and then you steadily bust out versions and now it looks perfect. Can't wait to try it.

Yeah, it's been a LONG time since I did C but it seems to be coming back to me. Fortunately, the collection was all plain C (C++ syntax just makes my head hurt, but I use parts of it like the comment styles, initialise variables anywhere etc. because they just make sense) so I could "re-learn" as I was doing the conversion. I've had some "moments", I tell you, and I still have no idea how "mines" works (or rather, doesn't), or how to stop F200 touchscreen being a pig, but it's been pretty smooth sailing.

It was about as much work as I expected it to be, but I could really do with a proper cradle or something because cabling and setting my F100 up for large testing runs was a pain in the backside. However, most of the time that I've spent on it has been looking up function names, debugging silly things and trying to get things to compile how I want them.

QUOTE

Seriously, this is great stuff. Some of my favourite puzzle games for the GP2X. And then there's still lots of additional ones which I'll have to try. The only thing I have to say is that the controls are a bit unintuitive for a handheld device. Especially on the F100 where pushing the mouse cursor around is really painful.



Yeah, the controls are a bit of a pain because the games are written for mouse-use only, really. Some of them take keypad input but that's even harder to control, although it would be easier to program. About the only conversion I've seen that's any good in terms of control is actually the Palm port for the Palm touchscreen, which doesn't seem to get updated much any more, but even that has nightmarish controls when it comes to right-clicking on something.

I'm sure that if I ripped out the control system and started again, I'd end up with twice as many problems so I'm leaving it alone for now, at least in public releases. That's why there was a one-month delay between beta4 and beta5 - most of that time was trying to find a reasonable compromise between setttings so that both F-100 controls and F-200 controls worked. I didn't find one. One works better with an event thread, one without, one works better with faster scanning of the "mouse" buttons, one doesn't, one works smoother with a pause between each read of the device, one didn't. And there wasn't any combination that I could find that worked well enough for both.

But then, I don't have much left on my to-do list for this collection, now, so maybe beta6 (version 1.0?) will have a new control system and a bit of tidying up. Or failing that, an F-100 version and an F-200 version!

Oh, and people who are worried about the size of the collection - don't be. It's now only 2Mb. If I tried hard, I could even get it to fit on a floppy! That's because there is only one executable now, which can run any of the games. In fact, if you run "stppc2x" through telnet, it'll give you a listing of the compiled-in games and you can run them by using "stppc2x net" etc. That's all that the menu does, by the way. It's rather a small program - the games all draw themselves using shapes (so there is no PNG's associated with the games themselves), the instructions text files and menu screenshots are tiny, in fact the largest things next to the main executable are the DejaVu fonts that I included. I've tried compressing them but you don't save that much. About the only thing I could do to shrink them would be to start removing unused characters from them.

So, hopefully it won't be as long to wait for the next version - I'm planning on making the menu part of the game (it's currently three seperate programs at the moment - the menu where you select a game, a script that gets run from the menu, and the final executable that has all the games), finally fixing the bloody control system and, if I can get mines fixed, that'll be it. Version 1.0.

 

[Manjuu]

Awesome work.

Excellent work on the menu juanvvc.

The new loading screen is nice. A few of the games did take a while to load, so it really helps.

On my F-200, the touchscreen kind of works... but unfortunately, it seems to cause the game to crash. It works fine on taps and really quick strokes, but if it is held down for longer than a second, the game would freeze and no longer respond to any touch or buttons.

Anyway, D-pad controls works fine, and some games do the require the other buttons, so touchscreen isn't a major loss.

Thanks for all your hard work on porting this. (Thanks also to Simon)

 

[senquack]

Awesome work.

On my F-200, the touchscreen kind of works... but unfortunately, it seems to cause the game to crash. It works fine on taps and really quick strokes, but if it is held down for longer than a second, the game would freeze and no longer respond to any touch or buttons.

Do a search on google "site:gp32x.de EVENTTHREAD" and you'll find a mention of a halfway fix for this in this thread several posts down:
http://www.gp32x.de/board/index.php?showt...3819&st=480

 

[ledow]

Okay, for those who like technical stuff:

Yeah, I tried the things mentioned in that thread already. Event Threads had to be enabled for anything touchscreen to work *at all*. I found that out quite quickly once I looked seriously at touchscreen - you just get a whole load of "identical" mouse events at the place where you initially touched the screen, no matter what you do with the actual stylus... I think that's WRONG whether event threads need to be enabled for *smooth* operation or not. The joystick events of the F-100 work perfectly with or without event threads. Mice events work perfectly with or without event threads (unless you flood the event queue, in which case the FastEvents code that I found and included helps out immensely). Touchscreen events DON'T. However, ignoring that, the problem is that even WITH event threads, F-200 touchscreen buggers up on these games.

The input layer is the most complicated part of the games, because I have to convert everything to a set of mouse motion/button events which call the game's internal functions, and take account that, say, the X button is pretending to be the left-mouse-button, but so is the actual left-mouse-button, and so is the touchscreen. And the joystick buttons corresponding to up, up-left, etc. have to be turned into mouse motion, with nice acceleration etc.

I'm not saying that I have good code in this part of the games, but I do have code that I spent a long time getting working for F-100 initially, that also works perfectly with mice on Linux, Windows and GP2x F-100. When I first put it on an F-200 (or emulate one using the tsinput modules of VNCServer) and pressed the touchscreen everything worked completely differently and just hanged the games. I didn't like finding that out. The point of SDL is that it's hardware-independent.

Anyway, I have code where I can control the cursor with any combination of F-100 buttons/a real joystick/a real mouse on either GP2X or a laptop, and I also have code that, when used with an F-200 touchscreen works fine (but you can't then control it satisfactorally with the joypad) but no matter what SDL options I use, I can't get optimum use out of both the F-100 and F-200 simultaneously. It's peeing me off. I use a F-100 to develop on and can "emulate" an F-200 very, very accurately using VNCServer2x's "fake" input modules - I know this works the same as an F-200 because every piece of test code I tried worked identically on "real" F-200's that people have been kind enough to test on.

I know that I have to rip out all the event code and start again (this will be the third time I've done that). The problem is first that there are so many types of input that could be used, simultaneously, to do exactly the same jobs. Secondly, the joystick needs special code to control the mouse cursor (which, because I use WarpMouse, ends up generating SDL mouse events too), such as acceleration, screen limits, handling diagonals etc. Thirdly, the game input code is a bit finicky and not really designed with such shenanigans in mind. Fourth, I get bored very quickly of ripping out the input code each time and then fixing the same bugs over and over in my attempts to get everything working smoothly again.

Currently, the games have a main SDL event loop that catches all events (with config options for eventthreads, SDL FastEvents, Poll/WaitEvent etc. so that you can fiddle with how the events are captured - see the code snippet below). They also have an "input" timer which fires at regular intervals (slightly faster than the actual "game tick timer"). Both timers have configurable intervals that I've set according to some experimentation and following the porting instructions for the games (the game tick timer should ideally be 50ms but I know that it can go as low as 25ms or as high as 100ms without much difference - the input tick timer needs to run more often so that input events are acted upon quickly enough, to debounce the joystick a bit especially for diagonals etc.). The game tick timer is the one which does all the actual drawing, movement, gameplay etc.. The input timer is something I added to get around a lot of problems I hit with the Event code when it comes to turning joystick input into "mouse-like" input.

Inside the code you'll find lots of things like the following, precisely because I thought there might be a "magic combination" that would make everything work. I did so much trial-and-error that I factored out everything I could find so that I could just do a batch of test compiles, run a dozen combinations on a real GP2X and hope to find a compromise for all machines. I never found it. So the code does need re-writing, I know that.

CODE

#define FAST_SDL_EVENTS // Use the Fast Events code
#define WAIT_FOR_EVENTS // Sleep briefly when no events pending
#define EVENTS_IN_SEPERATE_THREAD // Spawn seperate thread to handle events

#define SDL_GAME_TIMER_INTERVAL (50) // Interval in milliseconds for game timer
#define SDL_MOUSE_TIMER_INTERVAL (25) // Interval in milliseconds for mouse timer



Anyway, the "input tick timer" reads the actual joystick hardware and sets variables, then it sends an equivalent "mouse event" to SDL. The mouse (and therefore ALL input) handles itself solely via events, which is where all the touchscreen/joystick input ends up too, and just "converts" SDL events to "midend events" for the games - for mouse/touchscreen, this means that it passes on events as soon as it recieves them and the input timer plays no part at all.

The games can do *anything* with these events (I don't understand about 50% of the in-game code, despite having done a specific course in game-theory, because it's all abstracted behind the midend layer and is heavily based on game-theory, mathematical proofs and an awful lot of badly-named variables!) but the games usually store their own copies and act on them as they see fit in the next "game tick". Basically, most of the joystick-handling code does nothing more than modify a set of local variables that cache the input status - because left-mouse-button is equivalent to screen-pressed which is equivalent to X-pressed, but the midend only "knows" left-click or right-click or middle-click or "mouse moved".

So *actual* joystick events are extremely quick to process and the input tick timer rate-limits them and then converts them to mouse events. The mouse event handler passes on the events to the games (so if you could theoretically hit the keys REALLY fast, the timer would "debounce" all the values and just send the "final result" to the games every 25ms). However, mouse input bypasses all that and just gets sent straight to the games as it occurs. Which is why I don't understand why touchscreen has such problems, especially given that the same code drives a mouse flawlessly. I've even plugged in a graphics tablet to my development laptop to "simulate" a real touchscreen (i.e. being able to click anywhere and only recieve events on actual clicks) and it works perfectly.

Another problem comes from the fact that once you call the "midend" functions (the games internal code), everything leaves your hand and is in the hands of the author of that game. So whenever you collect input-events that you've received from SDL, convert them and pass them to the game, it can take as long as it likes to process them - and you can't "thread" this (the midend functions are not really designed for threaded use), so you're just stuck waiting for them to return. Similarly, every 50ms (so the docs say, and experiment shows that it makes little difference except to smoothness of animation) you have to call the games internal "tick" routine, that goes off and does whatever the hell it wants while you wait for it to return - that's the only "thread-safe" bit of the whole code. Hence, getting "smooth" motion is a real pain in the bum.

You can't necessarily jump enormous distances unchecked with the mouse cursor, either, because sometimes you'll make things jump off the screen which crashes the midend (the first three beta's suffered from this problem but people didn't notice in normal gameplay). Thus, the code constantly "fights" the real mouse cursor and drags it back to reality - sometimes you can get graphical artifacts on the edges of the games that "drag" things around. The joystick events also need to move the mouse, so you need them to be at regular intervals and/or debounced. Otherwise, "wiggling" the stick on a diagonal generates twice as many events and the cursor moves much faster.

So, for joystick, you're stuck with reading inputs every Xms, working out which way the D-pad/Joystick is pointing, adding a certain (small) distance to the mouse cursor based on that (and current acceleration/velocity data), checking the final point is within bounds, jumping the mouse cursor to there, getting the mouse input event from that, processing that, sanitising it and passing it on to the games and hoping that you did it all quick enough for the game to be smooth.

If you fire the input tick timer too slowly, the F-100 "mouse" slows to a crawl and you need to make larger jumps each time, which gives you jerkiness and extra code to handle the situation. If you fire the input timer too fast, you flood the event queue, the mouse rockets everywhere and you end up trying to slow it down. You also have input events get ignored because the input tick happens multiple times before the game tick.

That bit all works fine (it works much better than you actually see in the published beta's). But when you just try to jump into that code with a real mouse event, it works perfectly for real mice and terribly for touchscreen, so you end up trying to make compromises for it. Mouse events happen super-fast and you can literally throw the mouse across the table and have it catch up. But touchscreen mouse events do weird stuff. The only methods I've found to handle them satisfactorily slow all input down, or somehow cripple elements of the input (i.e. you get a one-time decision about what device to use).

On a side note, if you remove the input timer entirely and rely solely on SDL events, you can get sluggish movement from the joystick because the code run on each event is so heavy (and early versions lost events, so buttons "stuck", but I think I know why), so you end up filtering every event, and you also end up sending the midend so many events that you've just shifted the problem into code you can't play with. Additionally, you get into a state of confusion over what is currently being pressed and what isn't.

The timings I've used are chosen to give smooth movement on the F-100 joysick. However, I've had to patch in little fixes here and there because sometimes stupid things happen. Each time I redesign, I have to take account of all the stupid things and put them into the new input code. I'm not saying that I couldn't rip out the input layer and rewrite it so that it worked perfectly but it's a real pain that requires an awful lot of testing - 30 games that all have different ways of working with input, some require dragging, some expect keyboard input, some work in different resolutions and so require different mouse speeds, some have heavy "animation" on each click, etc - at least three different types of input devices, across three different hardwares (PC, F-100, F-200). And a poor little 200MHz processor sitting in the middle of it all while trying to run some very complex puzzles.

For those who are interested, I'm about to update the SVN code I have stored on Google Code to the actual code for beta5 (Ignore the "beta5" tag currently up there, because that's code *destined for* beta5, not the actual code FOR beta5) and you can browse through sdl.c from there. Warning - it will look messy in places. Don't even think of looking at the config-option handling code, for instance! My own repositories are much cleaner, honest. You might want to search-in-page for "Main_SDL_Loop".

I do think that input problems have plagued these games since the outset and I do want to fix them. It's just such a testing burden all the time, especially when you get "code fatigue" from looking at the same problems/lines day-in, day-out.

I also want to fix mines once and for all but I can't track down where the code is hitting problems effectively - it seems to be a signed-char/unsigned-char, signed bitfield/unsigned bitfield problem but I can't find WHERE and gcc's flags to force it one way or another don't fix anything. On each startup, the squares that *should* contain "1" (denoting a *covered*, grey square with a single mine touching it) are identified as -1 (denoting a square the player has flagged as a mine). I might have my -1's and 1's the wrong way around because I'm working from memory but the principle is the same. There shouldn't be ANY squares with -1 in them when a game starts at all because the player hasn't done anything yet! Thus, the thing crashes the second you touch anything. It always crashes on the same assert at line 599 (because it KNOWS that there shouldn't be any -1's in there yet!) but I can't trace which line is causing the sign-reversal. And it ONLY happens on ARM. I can give you an identical x86 version, from the same source, for Linux/Windows that works perfectly.

I asked Simon Tatham for help and to say he was disinterested would be an understatement - I didn't even hear back from him. Working for ARM, you'd think he'd want to help a little, even if it's just because I've done something stupid in the Makefile or something. Anyway, NOTHING in my code can affect mines' initialisation, because the problem is already in the data before you get to do anything with the frontend (it's in the internal representation of the minefield, which is initialised at game startup, and controlled solely within mines.c/mines.h which I haven't edited a single character of). I really need to do a program trace from scratch on this problem but it's such a pain because the code it happens in is iterative and poorly documented.

Anyway, I'm planning on making the next version the last. Not just for GP2X, but overall. I want to fix every bug, get input working properly, get mines running and get a codebase that people can use for, e.g. a Pandora conversion. I want to get working on my Castle Of The Winds conversion/clone instead.

 

[senquack]

Okay, for those who like technical stuff:

I also want to fix mines once and for all but I can't track down where the code is hitting problems effectively - it seems to be a signed-char/unsigned-char, signed bitfield/unsigned bitfield problem but I can't find WHERE and gcc's flags to force it one way or another don't fix anything. On each startup, the squares that *should* contain "1" (denoting a *covered*, grey square with a single mine touching it) are identified as -1 (denoting a square the player has flagged as a mine). I might have my -1's and 1's the wrong way around because I'm working from memory but the principle is the same. There shouldn't be ANY squares with -1 in them when a game starts at all because the player hasn't done anything yet! Thus, the thing crashes the second you touch anything. It always crashes on the same assert at line 599 (because it KNOWS that there shouldn't be any -1's in there yet!) but I can't trace which line is causing the sign-reversal. And it ONLY happens on ARM. I can give you an identical x86 version, from the same source, for Linux/Windows that works perfectly.

Hmm, might be an alignment issue. ARM requires all int's and pointers (not the address pointed at, just the pointer) and dwords to be aligned on an address evenly divisible by four. Fairly sure it also requires shorts and words to be aligned on addresses that are even. That means code like this is very likely to store bad data into junk_data_here. X86 will properly assign the data and can handle unaligned stuff, however.
CODE

int dummy_var; //GCC will guarantee this is 4-byte aligned
char temp_char = 100; // ok, this variable is *probably* not aligned to a 4-byte boundary being only one byte and directly following an int declaration.

int *ptr_to_int = &temp_char;
int junk_data_here = *ptr_to_int;




I've also run into strange problems on the ARM when a programmer wrongly assumes the size of a structure like the following is, say, 3 bytes, when initializing it with memset or malloc'ing storage for it:
CODE

type struct not_3_bytes_on_arm {
char a, b, c;
};


On X86, this is 3 bytes long. On ARM, however, it is actually 4 bytes because GCC pads it to keep things aligned for the finicky ARM. There are flags you can pass that will issue warnings when code is detected that requires padding or when a pointer to a char or short is dereferenced in a way that might cause alignment problems.

I know what you mean about getting burned out on a project. I recently spent a loooong time trying to get Abuse-SDL working properly on the GP2X. After many dozens of hours debugging tricky memory crashes I finally fixed quite a few alignment problems like the above, only to encounter even stranger crashes in the built-in LISP interpreter. I do NOT know how to fix an undocumented/uncommented LISP interpreter!

 

[ledow]

Hmm, might be an alignment issue. ARM requires all int's and pointers (not the address pointed at, just the pointer) and dwords to be aligned on an address evenly divisible by four. Fairly sure it also requires shorts and words to be aligned on addresses that are even. That means code like this is very likely to store bad data into junk_data_here. X86 will properly assign the data and can handle unaligned stuff, however.

Yeah, I tried a couple of gcc tricks to get around this, but I couldn't get anything better out. Given the number of compiler/linker flags, though, it wouldn't surprise me if there was one I missed. I think I tried the "packed" attribute for struct's too. And I couldn't see any hard-coded struct-size assumptions either. The code is very "clean" in that respect, it adheres to strict C standards for the most part. I guess I'll have to get a proper debugging inspecting it on both ARM and x86 and shout as soon as there's some line that produces a difference (there are already routines to seed its own rand() functions, so it should be fairly predictable on all architectures).

I know what you mean about getting burned out on a project. I recently spent a loooong time trying to get Abuse-SDL working properly on the GP2X. After many dozens of hours debugging tricky memory crashes I finally fixed quite a few alignment problems like the above, only to encounter even stranger crashes in the built-in LISP interpreter. I do NOT know how to fix an undocumented/uncommented LISP interpreter!

Pity. Abuse is one of those things I'd love to get going as well but, like you say, there are lots of weird errors if you just try and compile it for another architecture - I know, I gave it a shot once myself. God knows what they were on when they wrote that game, but it must have been good stuff (probably why the company was called Crack Dot Com in the first place!). A game running on a LISP interpreter... FFS... why didn't they just go it all in ALGOL and have done with it?


Edit: Senor: Just noticed that you did part of TTD2x - good man! I love OpenTTD (there's even a trivial patch or two of mine in there somewhere, pre-SVN - things like MD5 checking of GRF's etc.). Any news of an updated version of that, or has that stagnated too?

 

[senquack]

Edit: Senor: Just noticed that you did part of TTD2x - good man! I love OpenTTD (there's even a trivial patch or two of mine in there somewhere, pre-SVN - things like MD5 checking of GRF's etc.). Any news of an updated version of that, or has that stagnated too?

Yeah, I think ZodTTD is off in iPhone land for good so it will probably be up to me to bring it up to 0.6.1 from 0.5.3. I am also working on a port of Crosswords (also known as XWords for the palm, a nice Scrabble clone I used to play a lot of when I had one)

 

[juanvvc]

I have been playing intensively these games during my last train travel. Man, I love these games. Thanks for your hard work

Most games work just great, but I usually change the default configuration to a harder mode or larger table. Experience, I suppose Little comments for some games:

- Thanks for the new colors! They are way, way better than the old ones!
- Map: not your fault, but I cannot distinguish between areas that were automatically colorized and my colors. That's imporant because initial colors cannot be changed.
- Maze: the font of the configuration menu is so tiny that is not legible.
- Rectangles: one of my faves and it does not work any more It always returns to the menu without showing the loading screen. It is the only game with this behaviour.
- Slide: once I got an eternal loading screen. It was only the first time, the next ones the loading time was "long" (five seconds) but not "as long" (30 seconds, and I switched off the Gp2x)

Thanks for these games! I specially appreciate the new sokoban, and never found the exit in a 4x4 maze

 

[senquack]

Touchscreen events DON'T. However, ignoring that, the problem is that even WITH event threads, F-200 touchscreen buggers up on these games.

I am looking at the source code to Paeryn's modifications and see some areas I'd like to experiment with. I see one group of divisions by 65536 (not by a constant, though) that, if that value rarely changes, can be sped up drastically by a simple right-shift by 16 / mov instruction. I am probably going to look into changing some of it into ARM assembly.

 

[ledow]

Thanks for the feedback, juanvvc.

Harder difficulties - Yeah, the default difficulty is just the same ones that the desktop games default to. That's why I added saving of configurations, so you could set it to a challenging level for yourself without having to rely on what **I** think is easy/difficult. There is a feature that I've not finished - "difficulty levels" that the games supply - every game has presets for Easy, Medium, Hard, Impossible puzzles etc. built-in but the GP2X version doesn't use them directly yet. They will hopefully be an option in the next version, seperate from your "saved" configuration.

New colours - They are better, I have to agree. I didn't really want to play with the defaults but I never realised that the GP2X was showing them so darkly. I literally had to add 10% or more extra brightness to colours to get them to show - if you were to run maze3d on a PC, for example, the walls are almost pure Red, Blue, Green, I've had to tweak them so much. The "default" colours for maze3d actually showed up as white, white and white on the GP2X!

Map - Yeah, that's part of the game. Given that these "locked" countries are drawn before the player gets a chance to do input, there is a nice "barrier" to colouring them however you want. I expect it's trivial to plant some sort of icon into their centres before the game starts, and keep it in the in-game bitmap. I'll have a look. This will be map-only code, so the patch for it might even get into Simon Tatham's mainline.

Maze - Yeah, it has to run at 640x480 where all the other games do 320x240. I'm putting in a fix in the next version. The text and everything should scale okay (I abstracted the text size out of the code) so it's just a matter of detecting that the game requires a large screen and scaling up the menu accordingly.

Rect - Mmm. Okay. Thanks for the warning. I'm wondering if I buggered something up, because I had it working on my one. Maybe I didn't copy the final "release" version over properly, or something? It's also possible that you have got mis-named files for the help (the name of this game changed from rect.txt to rectangles.txt, so it might be that). If you get a chance, can you run the following command via telnet/Termula2x in the STPPC2x folder:

CODE
./stppc2x rectangles


That should at least give you an error message which will help pinpoint the problem.

Slide - I doubt you ever got an "infinite" loop, just an incredibly long one - I had one that took over 10 minutes once but it eventually completed. Slide is EXTREMELY inefficient at generating the puzzles, that's all. Basically, it fills the game area with tiny 1x1 blocks and then randomly glues them together into large pieces. At EVERY step, it then tries all possible moves in order to check if that particular pattern is "solveable". If it is, it finishes. If it isn't, it backtracks or glues more bits together. That takes FOREVER on a 200MHz processor - even the solve process itself can take a little while on the default size settings! Slide is actually marked as "unfinished" in Simon Tatham's repository exactly because of this, but otherwise it's fine. Believe it or not, Slide was the reason I put a loading screen on! DO NOT RUN SLIDE WITH A LARGE AREA, not if you want the GP2X to finish before the next century, anyway!

A lot of games suffer from this problem, though, but "slide" is the absolute worst - if you do a large "bridges" puzzle with all the options whacked up, you can kill even a 3GHz processor.

In technical terms, some puzzles are O(n), O(n^2) or even O(n!) in their complexity for initially generating the puzzle, where n is the size of the puzzle you've requested. So an O(n) game on a 100-square board will take somewhere around 100 "operations" to generate, an O(n^2) game will take about 10,000 "operations" to generate. However a O(n!) (where n! = 1 x 2 x 3 x 4 x ... x n) game on the same size board will take somewhere around 3,628,800 "operations"! Each of those "operations" can be anything from one instruction up to several million actual processor instructions

"Slide" is one of these latter types (I don't know if it's O(n!) but it's certainly a high-order function) - large puzzles take an INORDINATE amount of time to build. However, some of the games are only O(log n), where a 100-square puzzle would take about 2 operations, or O(1), where the size of the puzzle makes virtually no difference to the time it takes to generate - it doesn't much matter how large a puzzle you do in "net" or "guess", for example, it'll return almost instantaneously.

QUOTE
I specially appreciate the new sokoban, and never found the exit in a 4x4 maze


Sokoban I didn't really enjoy, because the generated puzzles were a bit simple, but it took about 30 seconds to get working once I decided to add it - I had to tweak the input code a bit, I think, because it wanted Numpad control. But then, getting a *computer* to design a sokoban level that is solveable, but difficult to solve, is nowhere near an easy task. This was another "unfinished" game from the original collect, precisely because of this reason.

And maze is a brilliant game that I think is an extraordinary achievement for such a limited drawing interface but which even I get lost in (and I did years of solving mazes as part of my university courses!) - it is, however, the ONLY third-party game I found that uses the puzzle collection framework, so I thought it was worth including even though it has a lot of quirks (it was built against an older version of the framework and needed some tweaking of variables, and it also demands a higher screen resolution to work properly - I had to re-vamp all the drawn text within the game because it was designed for higher-resolution screens).

Always do a 2D maze first (depth=1), so that you get the idea of how it draws the maze. Then do a 3D maze of depth 2 and use solve to help you work out how to move up/down levels. Quite often it's the fact that you are "turning" in the maze (so you "turn" upwards, rather than move up one level) that throws people.

And, Senor Quack, anything that you think might make touchscreen run smoother in SDL will be greatly appreciated. I see no reason that touchscreen shouldn't work AT ALL when you don't use Event Threads, but that's the way I saw it when I tested it.

 

[juanvvc]

I found the problem with rectangles: stppcgui.data still points to rect, not rectangles. Changed and the game works ok, of course. Weird, I though I changed all files with the new ones...

 

[ledow]

I found the problem with rectangles: stppcgui.data still points to rect, not rectangles. Changed and the game works ok, of course. Weird, I though I changed all files with the new ones...

So, you wrote the menu, gave it to me, I edit the code a bit and change a name within the text file data, give it you back (with a large warning to replace all files) and you're the only one to mess it up! :lol:

(Admittedly, I had to change the file structure a lot for this beta, so I'm only pulling your leg. It's not surprising that people who have older versions can mess up if they copy over the top, especially when we've gone from a 17Mb collection to a 2Mb one that actually contains more games and a menu as well - I'm aiming to keep the whole thing under 2Mb for the final release if at all possible and to reduce the number of files, so the menu will get merged into the main program, the instructions might move into one big text file, the splashscreen might get sucked into the executable etc).

 

[ledow]

- Map: not your fault, but I cannot distinguish between areas that were automatically colorized and my colors. That's imporant because initial colors cannot be changed.
- Maze: the font of the configuration menu is so tiny that is not legible.

Just a heads-up to let you know that the above problems have been fixed (they were very trivial) and will be included in the next release. Unfortunately the "map" fix is a bit ugly and not easily turned on/off at the moment (although I'm working on it)... basically it just prints a letter O in the centre of any "country" that is locked.

Maze has had its menus scaled up to suit it's 640x480 mode, which meant a bit of revamping of the menus.