Stppc2x V1.1 Released.

[ledow]

Ledow has released version 1.1 of STPPC2x!

The latest version of my efforts to port Simon Tatham's Portable Puzzle Collection to the GP2X. This is a set of 31 addictive logic and puzzle games. Some are old favourites (like sudoku, sliding puzzles and minesweeper) and others you may not have seen before.

You can download STPPC2x immediately from the main website or from the GP2X archive. The music pack is unchanged and can be downloaded from the main website too.

So, what's new?

Collection:

Display - Show whether a game supports numeric input, a solver, etc. on the main menu, removed a couple of incorrect screen updates that could make the menu flicker, game preview images now centre properly (e.g. Maze3D's).

Gameplay - All games now have cursor-mode control, status-bar messages now "time out" rather than linger forever.

Input - Digit input for large games that need characters rather than just numbers.

Memory - Can now take advantage of the upper 32Mb of RAM should we ever run out of memory on the GP2X.

Screenshots - Now disabled by default, enable and press Stick-Click to use them.

Size - The size of the executable has been reduced by a number of means: removal of unused code, better final compression, shortening of static buffers, etc. Also, the images have been compressed more using pngcrush. This should save up to 500Kb on the GP2X.

Games

Cube - Massive memory usage (spotted by me) now fixed (by Simon Tatham).
Dominosa - More presets.
Guess - Fixed potential crash.
Loopy - improve generation of "Great-Hexagonal" games, quicker solvers.
Map - "Show immutable regions" option now removed - you can just press Y and the regions that can't be changed highlight in red.
Mosco - Fix completion bug, add end-of-game flash, clicking on the edge tiles highlights squares that could "point" to them, non-square grids and new presets.
Solo - Show intermediate lines properly, enable 4x4 etc. presets, add "Killer" Sudoku mode.

Feedback is appreciated and full source code is available from:

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

 

[LineOf7s]

Wow, this has come a long way since you first began it as a bit of a dalliance.

Thankyou very much for your efforts.

 

[slaanesh]

This is brilliant stuff. I love puzzle games like this. Thank you very much. Now I understand why you want Logic Pro on MAME.

 

[Manjuu]

Thanks for the update.

I don't remember reading it, but it's great to have usable touchscreen support (i.e. game selector, in-game, & in-menu).

Weird... why do I see a white symbol-like blot at the upper-right portion of the in-menu? :huh:

Anyway, good work and thanks again.

 

[rokdcasbah]

Awesome, much appreciated.

 

[ledow]

Thanks for the update.

I don't remember reading it, but it's great to have usable touchscreen support (i.e. game selector, in-game, & in-menu).

Weird... why do I see a white symbol-like blot at the upper-right portion of the in-menu? :huh:

Anyway, good work and thanks again.

The "blot" is actually a hand holding a pencil... it's indicating that you're in "touchscreen / mouse" mode. If you go to Global Settings... Cursor Control, it should change to a little keyboard.

I admit it's not very clear on the GP2X, but it's drawn using the font that I use for all the text... so it "costs" nothing to have and is easy to print... it's just a Unicode character. For some strange reason, on a PC at the same resolution, it looks fine!

This is brilliant stuff. I love puzzle games like this. Thank you very much. Now I understand why you want Logic Pro on MAME.

And I got it! Franxis was kind enough to include it in the lastest versions, and both Logic Pro and Logic Pro 2 work, along with a few other games. All hail the great MAME master...

 

[senquack]

Thanks for the new release, will try it out this weekend.

 

[Manjuu]

The "blot" is actually a hand holding a pencil... it's indicating that you're in "touchscreen / mouse" mode. If you go to Global Settings... Cursor Control, it should change to a little keyboard.

I admit it's not very clear on the GP2X, but it's drawn using the font that I use for all the text... so it "costs" nothing to have and is easy to print... it's just a Unicode character. For some strange reason, on a PC at the same resolution, it looks fine!

Oh... so that's what it was.

I tried staring at it again; still can't see a hand or a pencil. It gets cut off a bit at the top (the keyboard symbol too), so that makes it harder to recognize. :lol:

I didn't know about the keyboard controls. I like the keyboard controls better for most of the games I tried it with.

The only exception so far is for Untangle. Why does it require two button presses to just switch to the next node, and to show the node numbers (middle-click) require that the nodes be selected for it to function, making it two button presses. (The color of the node becomes the same as the background too.) <_< I'll be sticking to cursor or touchscreen for this.

Thanks again.


EDIT: Fixed some of the stuff the board broke.

 

[slaanesh]

I have a bug report for one of the puzzle games. I found the problem in "Filling". When I set the grid to 26x18 (the default is 13x9) it seems to crash.

 

[ledow]

I have a bug report for one of the puzzle games. I found the problem in "Filling". When I set the grid to 26x18 (the default is 13x9) it seems to crash.

Just done this on a dual-core 2.5GHz running the same code, waited ten minutes and it's still going at 100% CPU... it just takes *FOREVER* to generate a solveable puzzle of that size. This is the same with both my code and the original puzzles under GTK / Windows /etc. It's *possible* that it's a bug in the code generation but given that several other games suffer from long generation times (e.g. Slide, etc.) I'm more inclined to believe that it's just an extraordinarily difficult puzzle to generate.

(And, in fact, my laptop did just successfully generate a puzzle of that size with both my code and the original code but it's 2.5GHz and it took longer than it takes me to call my car insurance company, be on hold, sort out car insurance, etc. and change the baby... Now recall that the GP2X is one TENTH of that speed at best, assuming everything else, bus speed etc., stay the same)

Thanks for the report, though. It's just a sad fact that going too high on the settings for a lot of the games will cause out-of-memory errors or exceedingly long generation times. Prior to this release, cube on a GP2X could run out of memory on a large grid after about 50 moves and just seem to crash - in actual fact, it just took more than 32Mb RAM to hold a puzzle of that size. That's been fixed in this release by Simon Tatham modifying cube for me to reduce it's memory use, and by allowing upper memory access on the GP2X when we get low on RAM.

I didn't know about the keyboard controls. I like the keyboard controls better for most of the games I tried it with.

The only exception so far is for Untangle. Why does it require two button presses to just switch to the next node, and to show the node numbers (middle-click) require that the nodes be selected for it to function, making it two button presses. (The color of the node becomes the same as the background too.) <_< I'll be sticking to cursor or touchscreen for this.

Keyboard controls are basically only in the last two versions and only "useful" in this version. It's taken a lot of work to make them work properly and they aren't perfect, which is why the setting exists (you can save the global config so that by default you're always in keyboard mode if you want).

Keyboard controls are better for a lot of games but I've had to hack up the keyboard control myself for a couple of the games (e.g. Maze3D, Mosco, Slide, Untangle). Hopefully as times goes on, more keyboard control patches will go into the upstream collection and then they'll get sucked into this version. Until then, you'll have to suffer sub-optimal keyboard control in untangle (unless, of course, someone wants to have a look at my code and take a shot at it themselves - http://code.google.com/p/stppc2x you'll want untangle.c and look at the interpret_move function, specifically any bit that mentions "CURSOR").

Untangle and Map are the only games where keyboard control doesn't really make sense, but Map is "officially" supporting this mode upstream and Untangle isn't, so you have to suffer my dirty hacks, I'm afraid.

 

[slaanesh]

that it's a bug in the code generation but given that several other games suffer from long generation times (e.g. Slide, etc.) I'm more inclined to believe that it's just an extraordinarily difficult puzzle to generate.

(And, in fact, my laptop did just successfully generate a puzzle of that size with both my code and the original code but it's 2.5GHz and it took longer than it takes me to call my car insurance company, be on hold, sort out car insurance, etc. and change the baby... Now recall that the GP2X is one TENTH of that speed at best, assuming everything else, bus speed etc., stay the same)

Thanks for the report, though. It's just a sad fact that going too high on the settings for a lot of the games will cause out-of-memory errors or exceedingly long generation times. Prior to this release, cube on a GP2X could run out of memory on a large grid after about 50 moves and just seem to crash - in actual fact, it just took more than 32Mb RAM to hold a puzzle of that size. That's been fixed in this release by Simon Tatham modifying cube for me to reduce it's memory use, and by allowing upper memory access on the GP2X when we get low on RAM.


Have you considered using the upper memory area for storing large structures and such?

As for the games, I was enjoying "filling" and thought I'd make it double (quadruple the area) and see how I go. I may just bump it up less than that. Thanks for the information. It's a great set of puzzles, my wife is totally into the game too. It's the first time she's ever wanted to play with my GP2X.

I really like the game "net" as well - especially making it somewhat larger - 5x5 is pretty small default. Upping it to 9x9 or larger is fun.

What's your favorite game?

 

[ledow]

Have you considered using the upper memory area for storing large structures and such?

As of this release, the puzzles all use UpperMem if / when they run out of lower mem. Most of the puzzles do not use more than 10Mb even if you set the settings to sizes that are humanly-impossible to solve or too big to fit on the GP2X screen. It's just the odd one or two that need to build game trees in their generators/solvers that suck up RAM. For instance, "Cube" used to store the entire game again every time a move was made - this made 50x50 Icosahedron games crash after about 50 or so moves, if not before. I pointed this out to Simon Tatham and within hours, he'd changed Cube to use one full board copy and a lot more pointers/reference counters and brought the memory requirements from about 250Kb per move to about 4Kb. But he says that was just a one-off because he had forgotten to do it on that particular game - I take that to mean that he takes such petty RAM usage very seriously (he works for ARM, I think) and has tried his best to reduce memory usage in the puzzles.

As of v1.1, when the lower RAM is exhausted on the GP2X, the games automatically and seamlessly use as much of the upper RAM as they can until they run out of memory entirely (I've overloaded the implementation of malloc/free so that the games don't even need to know about this - and the same malloc/free are used by the interface, the INI library, etc.).

Unfortunately, the solver/generators for some types of games are so extraordinarily complex (and usually recursive) that it's CPU-bound and not RAM-limited, so it's hard to fiddle with them at all, and it's unlikely you'll get very good puzzles if you just randomly play with them. I'm afraid that you're probably just stuck with the sizes that generate in a reasonable time.

I would recommend that what you do is not just double the size, because that can mean an exponential increase in the time required to generate the puzzle. Select the largest preset, see how long it takes to build. Then manually add a few bits onto the preset (i.e. 9, 10, 11... not jumping straight to 20) and check again. You'll soon notice if the generation times are getting silly.

Most games, you're absolutely fine. Slide is the worst and you can easily kill it with low numbers (technically, it's marked as "Unfinished" because of this very problem). Filling is particularly bad too. Solo can get silly if you go too mad with the options (e.g. large puzzle, with Killer and Jigsaw modes on). Bridges can get silly too, but I regularly play 20x20 hard and even larger on that. Dominosa suffers sometimes, as does Rectangles. Loopy is usually okay. Net you can go quite large without worrying. Unequal is suprisingly good. The rest you can normally go as mad as you like and you'll run out of screen space before you'll hit long generation times, normally. The best one is probably Mosco, because I wrote that and it doesn't have a "proper" generator (it just generates NxN random bytes which translate into arrow-directions, strikes one out if it's been used too often, then splats them straight into a grid, works out the numbers about the edges and finally stores the random bytes in case you press Solve - the longest part of that is generating the random numbers and checking there aren't too many of them) so it can happily go to absolutely silly numbers and still generate a valid (if naive) puzzle quite quickly (e.g. a 32x32 or 64x64 are perfectly generatable but you'll have problems viewing them!).

I really like the game "net" as well - especially making it somewhat larger - 5x5 is pretty small default. Upping it to 9x9 or larger is fun.

What's your favorite game?

5x5 Net? 9x9 Net? You wimp. I regularly do 20x20 Net with no barriers, unique solution and wrapped walls. If I'm on the PC, I usually go larger than that.

If I'm on the train, I usually play the games in menu order, excluding the ones I don't like. That usually means a quick game of Blackbox (don't like the larger/harder settings), followed by a nice large Bridges, I play Dominosa on default settings if I have a lot of time to spare, Filling (also on default settings), Inertia (provided that I have good control of the GP2X and the train isn't too bumpy - I often play the highest presets for this), Lightup, Loopy (nothing fancy, just the defaults), a quick game of Map, a quick game of Mines, a quick game of Mosco (all on defaults), a lovely large game of Net, then a nice standard game of Rectangles, a quick game of Slant, a quick game of Tents, an Unequal (which I often don't finish), and an Untangle if my brain is hurting.

Net is probably my favourite, and was the reason I wanted this on GP2X. There's also a version that comes with KDE, I believe called something like KNetwork or similar. Bridges I discovered quite early on and have played a lot. Loopy I find quite interesting and new and it makes me think. I don't like Guess (it's boring). I like the Mosco puzzles but I really need to make them more difficult so you can play small, difficult ones. A few of them are fun time-fillers but don't really make you think once you've spotted the pattern - Net is one of these, Rectangles is quite easy too, Slant, Tents and Untangle are usually too easy. It's a shame that Sokoban can only generate some quite pathetic levels. Cube just annoys me because I've only ever completed it about twice, even for a simple dice-shape. Flip I just can't do AT ALL (or Twiddle). Maze3D really needs a better display/control system but seeing as I pinched the code and changed one line, I'm not going to complain! Netslide I've only ever played about two games of, same with Fifteen and Sixteen. Tents I find quite fun and can usually complete.

I forced myself to complete every game at least once in order to test my port. That wasn't fun.

What I like best about the collection (now), though, is that you have 31 games in a tiny program that loads quite fast. Do one, mess it up, go back to menu, pick another, etc. Some games can be played in minutes, some take hours, so it's easy to adjust to the situation. I almost never use savegames unless I'm testing them, although I have done things like quickly save because my train is coming and I have an interesting puzzle. I heavily use saving custom settings, because I like to have certain games on very large settings.

I'm a maths graduate who studied (and loved more than anything) a particular course - Graph Theory. Most of these puzzles involve some element of Graph Theory and, in the case of things like Untangle and Map, are actual well-known mathematical puzzles - Map demonstrates the 4-colour theorem, for example - no matter how large a map, or how many countries, or what shapes they are, you can *always* colour it in using no more than 4 colours without any two touching countries having the same colour. So I have a love of these puzzles for that. But mostly, they are quick, simple to understand, make you think, they don't draw anything that isn't necessary for the game (no fancy graphics, like the pay-for iPhone ports of the same games which use the same base code!) and the puzzle generators are surprisingly good at making good puzzles (which is much harder than you might think).

 

[ledow]

Oh... so that's what it was.

I tried staring at it again; still can't see a hand or a pencil. It gets cut off a bit at the top (the keyboard symbol too), so that makes it harder to recognize. :lol:

The hand symbol should be this (but in DejaVu Sans Condensed Bold):

http://www.fileformat.info/info/unicode/fo..._bold/u270D.png

The keyboard symbol should be this:

http://www.fileformat.info/info/unicode/fo..._bold/u2328.png

Unfortunately, at 12-17pt, they are fairly unrecognisable on the GP2X screen and the keyboard might "look" like it's had its top cut off because of the scaling. On the PC, they're not too bad. I've tried with 25pt and it doesn't seem quite so bad, so I may up the font size in the next version. If nothing else, you helped me spot a small bug in the choice of font size anyway!

 

[slaanesh]

Since my 9x9 post, I have upped it to 15x15 - which is still comfortable viewing on my GP2X and a better longer challenge. Yes, I love Net. I tried 21x21 last night but the squares were getting a bit small. It's funny with Net, i find I don't really need to think too hard with it, unlike Tent.
I also like Map, like you said. The colors are fun to put down and I just get a feel for it and can usually complete it easily.
I also like Untangle. I usually set this to 16. Quite fun. How the hell does the algorithm "know" when it's complete?
Tent is fun - reminds of a cross between Picross/Sodoku for some reason.

EDIT:
I can't help but think how excellent this would have been on a Zodiac with it's "instant on".

 

[ledow]

I also like Untangle. I usually set this to 16. Quite fun. How the hell does the algorithm "know" when it's complete?

Counting edge-crossings on the graph. It's actually quite simple once you get used to dealing with graphs (untangle basically *is* a mathematical graph - nodes and edges) and you don't need to do any guesswork - you know exactly whether or not an edge crosses another just by the connectivity of the graph (Node X connects to Node Y) and the relative positions. Identical techniques are used for both 2D and 3D collision detection in high-end physics-based games.

You'd be amazed the applications graph theory has - designing mobile phone networks (is it better to put on huge mast on a hill, or two smaller ones either side), finding optimal paths for, e.g. parcel delivery (is it better to drive to Town X and then to Town Y, or park up in between the two and do the short journeys in between back to the van?), planning optimal routes around obstacles (Internet routing uses this all the time, plus things like Satnav, finding your way out of Mazes, AI players in games working out how to follow you etc. ), solving puzzles (almost every puzzle and board game has an associated graph and finding the optimal route through that graph is equivalent to solving the game - there is a large cross-over with Game Theory), even sending messages to space (the crossover between Coding Theory is enormous, and let's us reliably send messages to outer space, input barcodes or read data from a CD using what most people call Error Detection / Correction Codes, checksums, hashes, etc.).

The beautiful thing about graph theory is that virtually any graph can be made to a simple, if large, graph (collection of edges and nodes that they connect)... so 3D doesn't matter... you can always make a 2D graph equivalent. And simple things like "colouring each edge differently" tell you a HELL of a lot about the graph, so what looks like child's tinkerings actually end up helping to solve chess endgames, proves some puzzles are unsolveable (like the three houses connecting to the three utilities on a 2D plane without crossing each other), etc.

P.S. Guess what three courses I took in University and loved the most...

 

[slaanesh]

I know virtually nothing about graph theory, just what you have written about. It sounds incredibly relevant to the games industry. Can you recommend any good introductions to it (website or book?)

Also, I found that there *IS* a PALM version of STPPC2x simply called puzzle.

My wife has a Zodiac so now I can get my GP2X back from her.

EDIT: Been playing Galaxy now as well. Another beauty.

 

[ledow]

I know virtually nothing about graph theory, just what you have written about. It sounds incredibly relevant to the games industry. Can you recommend any good introductions to it (website or book?)

Also, I found that there *IS* a PALM version of STPPC2x simply called puzzle.

My wife has a Zodiac so now I can get my GP2X back from her.

EDIT: Been playing Galaxy now as well. Another beauty.

The problem with the Palm versions are that they tend to get out of date and are INCREDIBLY hard to build (you have no idea how hard it is to get a working compiler for Palm and even then half the code has to be manually chopped into segments in order to fit in with some arcane memory slicing that the Palm compilers do). I tried to rebuild the Palm versions several times (so that I could just throw in the new code I have and it would work just like the original Palm versions but with extra games, etc. and also to fix a touchscreen bug on Palm T|X) and each time I've never managed to get a working .prc out of it. So, I just nicked some parts of the Palm code that handle things like drag/drop and cursor keys and stuck them into the GP2X version...

As far as graph theory goes, I learned it all direct from my professors at the time, but I'm sure there must be a good intro somewhere - it's creeping into A-Level maths now, according to my brother who is a private tutor. I'll have a look around and see if I can find a nice tutorial for you.

 

[slaanesh]

I've found that the Palm version is also incredibly slow. The Zodiac is a 200Mhz ARM device which is fairly fast.
I'd say that it's been compile in 68K mode - pity that it's not an ARMLET - or whatever they're called.
I'd say that your GP2X version is the better of the two - though I don't have a touchscreen GP2X so the input is nice on the Palm. I'd imagine that it's similar on the F200.

 

[ledow]

I've found that the Palm version is also incredibly slow. The Zodiac is a 200Mhz ARM device which is fairly fast. I'd say that it's been compile in 68K mode - pity that it's not an ARMLET - or whatever they're called.

Yes, my wife complains of this too. She has a TX and some puzzles don't handle the "right-click" properly either (actually a click-and-hold on Palm, but some puzzles support it on TX and some don't), so she doesn't really play it on Palm. Plus it can get horribly out-dated - at one point I saw it was nearly a year out of date.

I'd say that your GP2X version is the better of the two - though I don't have a touchscreen GP2X so the input is nice on the Palm. I'd imagine that it's similar on the F200.

I don't have a touchscreen GP2X either, but I've been told it's more than playable by several people who do (I always try and get someone with a F200 to test it before I release a new version). It's even quite playable on a laptop and, just lately, I got it working under Cygwin so I have my own Windows version too. I'm considering generalising the whole program so that it's not locked into the GP2X screen size, input etc. and producing my own SDL fork of the puzzles. I've had some interest shown about PSP etc. ports using my code, because it's based on SDL so it's still quite portable.

Basically, if you can compile C on a device, ports of the original puzzle set will run (there's one for Palm, Android, even Java now) but you may have to write the "frontend". Games like Maze3D, Mosco, Sokoban and Slide can be plugged into any port if someone is willing to add them in (there is almost zero work associated with this). The only tricky bit is the frontend - there's one for GTK, one for MacOS, one for Windows, one for Palm etc... Writing them means providing primitive-drawing (line, square, circle), file-access, timers, etc. and some sort of menu system to allow them to run, save, load, etc. You tend to find, though, that people make a bare-basics frontend and that's that. They don't bother to add anything else to it, they don't write new games, they just create a frontend that works the same as all the others and they recompile once in a blue moon and only ever from the official repository.

I created a non-standard SDL frontend so that it could run on the GP2X, slapped a few extra games in (those mentioned above, one of which I wrote myself) created my own menu system and other pretty touches and added a lot of fixes for things like cursors, dragging, joystick-control, etc. I recompile my own version with every update of the original puzzle collection (and hence, my port has things like Killer and Jigsaw Sudoku where a lot of ports don't - Killer was added only days before v1.1 was released). It can run on a whole slew of devices if someone just edits the keys and the screen sizes (I'm actually hoping that a Wiz version needs nothing more than a recompile if they've kept the same screensize / joystick button assignments in the SDL headers).

Simon Tatham said that he didn't want to take an SDL port unless it emulated the menu systems already in place (e.g. the same as GTK, Windows, Palm, etc.), but SDL doesn't really use native menus (i.e. you don't have SDL programs on Windows creating Windows menus, Linux ones creating X11, GTK or KDE menus etc. unless you write the code for each platform yourself) so you probably won't see a "real" SDL port in the official upstream any time soon.

So... I'm disappointed that more doesn't get into the upstream repository (ST has some pretty-strict requirements on what goes in there and I can understand that, but from my point of view, I just want to play puzzles - I don't care if I can mathemetically prove that the solver works in tiny corner-cases, or whatever), that there aren't more puzzles written for the system (I found one third-party game, Maze3D, and made one myself), that ports are only ever bland frontends or, the other extreme, pay-for iPhone apps that consist entirely of a single puzzle from the collection which has been spruced up graphically and had sound and Internet high-scores added to it! (PuzzleManiak). Hence, my SDL/GP2X version.

P.S. Anyone that can program in C (or, theoretically, any language that can be compiled with the GNU Compiler Collection and call / be called from C functions) that wants to make basic one-player puzzle games should really have a look at the API for these puzzles - if you can generate the puzzles algorithmically (not just read in 100 ones that you know are solveable from a file, although you *can* do that if you want), can draw them using primitives (line, rectangle, circle, polygon) and don't want the hassle of writing all the back-end stuff or flashy graphics, it's really a good place to start.

You literally write a "generate puzzle" function, an "interpret input" function, a "draw game" function and everything else is handled for you. Input is sanitised, graphics are redrawn and resized when necessary, it will work on any SDL-supported, Java-supported, GTK-supported, etc. platform provided you don't do anything too silly. You can have software timers, undo/redo/save/load is automatically handled for you (you just write a string in an "execute_move" function that describes in any way you like what happened that move, and an "interpret_move" function that can take the description of a move and perform it and the system handles everything else for you by "replaying" the game's history to do load/redo). There are a lot of functions for handling game tree's, random numbers, depth-first-search etc. I wrote Mosco, with no previous experience of the API from the puzzle-creator's side, in under a few hours and most of that was me trying to figure out how to make the *puzzle* work, the implementation was trivial. Mosco instantly "automatically" works on any port of the puzzles that bothers to include it.

 

[slaanesh]

Thanks for your detailed reply.
If I had the time I'd try porting Net and Galaxy to the GP32 - assuming they don't take up more than 8MB of RAM - well substantially less then that. Probably more like 6.5MB I'd guess as a maximum.