Stppc2x - The Complete Collection - Beta 2

[ledow]

An update to the earlier Beta 1 on my efforts to port Simon Tatham's Portable Puzzle Collection to the GP2X. This is a a set of 27 addictive logic and puzzle games. Some are old favourites (like sudoku, sliding puzzles and minesweeper) and others you may not have seen before.

This is the second beta release of the entire collection of the games, which I now call "STPPC2x". This beta has 26 fully-working games, the only remaining one is completely unplayable on the GP2X - mines, a minesweeper clone. I'm trying to get help from Simon Tatham himself to fix this as I think it may be that the "Portable" puzzle collection isn't as portable as you might think.

[cut]

If you tried the earlier Beta 1, all of the working games are working much faster, cleaner and better. I've revamped cursor control again and hope that it works properly for touchscreen (however, I'm still working blind without a F-200 myself and without help from many F-200 owners). The full changelog from the previous Beta includes items such as:

• Slightly improved status-bar drawing
• Coloured the whole background on startup instead of just the puzzle background.
  I may revert this, I'm not sure yet.
• Narrowed down mines behaviour to ARM peculiarities.
  ARM's signedness and endianness are different and this causes problems with the only
  game to use signed/unsigned char's (specifically comparison to negative integers) and
  bit-shifting. So it looks like this is outside the scope of this port until the
  upstream files are fixed. I've sent an email to the author for help with this problem.
• Added code and a new font to support monospaced fonts.
  Nothing uses it yet but this is for completeness in case anyone adds new games to the
  puzzle collection that requires monospaced fonts.
• Fixed a slight bug which could see information from a free()'d surface used.
  Although a "victimless" bug so far, it was possible that a temporary surface for text
  would be free()'d and then the size of that surface used to calculate how much screen
  to "blank" next time (often ending up by blanking nothing at all). Re-ordered the code
  to stop it doing that (strange that nothing complained, though).
• Re-jigged mouse cursors again
  Hopefully put a stop to the F-200 touchscreen / USB mouse weirdness. Also, I changed
  some timings back now that I've stopped timing-related mouse problems. Smoother
  animation may or may not result.
• Moved the initial mouse cursor to the centre of the puzzle instead of the top-left corner.
• Added font alignment.
  Only seems to be used for tents and only produces a slight shift to the bottom row
  of text. But, again, for the sake of completeness, it's done.
• Fixed map's and inertia's drag-drop display problem.
• Fixed pegs and sped up all games by putting screen updates in the right places.
  Also, implemented proper "partial updates" instead of full updates all the time.
• Implemented re-use of loaded fonts.
  Increases speed of text games at a cost of memory.
• Better descriptive text for errors/startup.
  You won't see them unless you are using Sterm / Telnet to run the games but when
  something goes wrong, you're more likely to get a useful error message.
• More error checking and bailing out with a nicer error on certain failures.
  e.g. fonts not being present, blits failing, etc.
• Made sure that the cursor doesn't linger after the game has quit.
• Updated to SVN 7977.
  Nothing new, except for some hidden new style of solo that you can't play yet.
  Just for the sake of making sure that upstream changes don't break anything from a
  development point of view.

Feedback is appreciated (especially from F-200 and USB mouse users) and full source code is available from:
http://www.ledow.org.uk/gp2x/. I'm also looking for help from any SDL/C coders to create a nice standalone menu program, add some more features, etc.

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.

You can download STPPC2x here: http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,25,2543[/cut]

 

[Lineus]

Wow, nice work, I shall check this out!

 

[rokdcasbah]

sweet, gonna try this tonight.

 

[juanvvc]

I really like these games, they are the only games that I played this week. I've got an F100 and I'm using the selector screen of GMenu2x with big snapshots as a nice interface for these games. Comments:

- You really need to draw a darker gray in Galaxies and Inertia. The gray slots are almost equal to the white slots in this games. Gray in Filling or Rect is ok, for example.
- Can you configure Slat to fill the whole screen? That would mean a rectangular table of 12x8, I suppose.
- Can you center games on screen?

Thanks for porting these games! They are really, really fun to play.

 

[Ze_ro]

Excellent stuff! I haven't tried all the games yet, but here's a few problems I've noticed, most of them due to the "squashed" graphics:

• Loopy - Marking an x results in something that looks more like a dot, making it very difficult to distinguish from the actual dots that signify intersections.
• Solo - There are supposed to be darker (ie, thicker) lines separating the 9x9 playfield into 9 3x3 playfields... however, these lines don't appear any thicker on the GP2X, making the game more difficult. If the resolution doesn't allow for thicker lines, maybe a different color would work?
• Mines - Crashes back to the GP2X menu when I try to left click, leaving the mouse cursor on the screen. Even after playing another game and then exiting, the cursor still appears over top the GP2X menu (and any other program ran thereafter).
• Pattern - The numbers are so small that they're almost impossible to read.
• Rectangles - While selecting boxes, the lines seem to jump around a bit.

It would be really neat to see this wrapped up nicely with a menu system that allowed you to read the instructions for each of the games and such.

--Zero

 

[ledow]

Thanks for the feedback everyone, I don't get much feedback but what I do get, I try to work from. Obviously STPPC2x is still a work-in-progress, given away by the BETA tags - I'm not yet brave enough to assign it a whole version number.

First, understand that the puzzles are self-contained and not written by me (I don't even know how some of them work). They just "talk" to the GP2X/SDL frontend (the bit that I did write) to do things like draw shapes, take input from the mouse etc. That's the only part that I want to play with to fix problems (and virtually every problem is fixable that way) - I don't want to get into hand-editing the individual puzzles to fix bugs.

[*]Loopy - Marking an x results in something that looks more like a dot, making it very difficult to distinguish from the actual dots that signify intersections.

Yeah, there's not a lot I can do about that. That's how the games scale their own screen. They are "playing" on 640x480 but they scale themselves to the GP2X's 320x240 just before they ask to be drawn on screen. I have plans to implement hardware scaling so that they can play on a "real" 640x480 screen but you can "pan" around the screen on the GP2X- this will be vital to the games once they have their configuration options implemented, because if you want to do anything but a "default" size puzzle, you run into these problems in most games. I'm hoping on using "Select" as a zoom-in, zoom-out key and moving Select's current functionality to a menu system that I'm in the process of making.

[*]Solo - There are supposed to be darker (ie, thicker) lines separating the 9x9 playfield into 9 3x3 playfields... however, these lines don't appear any thicker on the GP2X, making the game more difficult. If the resolution doesn't allow for thicker lines, maybe a different color would work?

Yes, this is nearly the same problem. However, before I implemented a certain feature for Beta 2 (proper display updates), this effect was visible even on the GP2X and now it isn't any longer. I don't want to revert that because that's what makes "pegs" work and I don't want to keep two seperate sets of code for pegs and solo, for instance. I'm pretty sure I have an off-by-one error in the line drawing routine which is responsible for this. That's also why "map" has little stray lines at corners. I'm working on it.

Because of the nature of the puzzle framework, I'm unwilling to change a single puzzle to fix a particular bug (e.g. put red lines in "but only in solo" etc.). I work on the "frontend" code and haven't needed to touch any of the puzzles or even check which puzzle is running for it to do it's work. I don't even know how the code for some of them works and I wouldn't be able to, say, pick out the line of code where Solo draws these lines because I've had no need to look inside the file "solo.c" at all.

However, by keeping to a single frontend that doesn't change for each game, this makes things better in the long run because new games and improvements to existing games don't change the way the collection works as a whole (e.g. Solo just underwent a massive update in SVN to add a new style of game which, once I get game configuration options working in a nice way, everyone will be able to play and get a "new" game for zero additional effort on my part... in the future all "upstream" updates from Simon Tatham will just work with the framework, even if he changes every game and introduces new configuration options - this is my goal for a v1.0 release). However, I'm pretty sure we can "fix" this particular bug by improving the general frontend code instead of changing the code for Solo because I have had it working before.

[*]Mines - Crashes back to the GP2X menu when I try to left click, leaving the mouse cursor on the screen. Even after playing another game and then exiting, the cursor still appears over top the GP2X menu (and any other program ran thereafter).

Yes, mines DOES NOT WORK AT ALL YET. It's the only one that doesn't and I don't think it's my fault. This is, I think, a bug in the mines code, not my frontend code. The games run in their own code which just "calls" my GP2X code to draw, take input from the mouse etc. so I can't do much about this. I'm waiting for an email back from the puzzle author because I think this is his issue - it's to do with the way the ARM chips work which hasn't been taken account of in the code (even though it's supposed to be "portable", meaning it'll work on all chips) - basically mines would never work in it's current on certain types of machine and the GP2X happens to be one of them. The EXACT SAME CODE that I run on the GP2X runs perfectly on a Linux PC and plays mines properly. It's just down to this silly bug in mines. Basically, the GP2X expects numbers to be a certain way round and it doesn't get them in mines which is the only puzzle to do things using "unsigned chars" and "bitshifts", so things screw up big-time in that game.

I believe that it's a simple fix, though, and if I get time I'll have a stab at patching it myself and sending the patch upstream. Fixable, but fixable outside the GP2X frontend.

[*]Pattern - The numbers are so small that they're almost impossible to read.

Yes, because the font HAS to be that small to fit on the screen. The games choose the font size that they need to fit on the screen, the GP2X frontend just does all the font-scaling to get them to that size. However, hardware panning on a 640x480 screen will solve that, hopefully.

[*]Rectangles - While selecting boxes, the lines seem to jump around a bit.

Yes, due to the same problem as your first one, I think. Off-by-ones in the line drawing code. And this is why Solo messes up when it should be drawing thicker lines.

It would be really neat to see this wrapped up nicely with a menu system that allowed you to read the instructions for each of the games and such.

Which is exactly what I'm working on at the moment. When you press Start you will get a menu that pauses the game and lets you Configure.., Load, Save, Restart, Quit. Instructions could easily be put on there too. Configure will let you change all game options such as size etc. but the chances are that some games would only be playable at certain sizes. Pattern, for example, is pretty much at its screensize limit. And bridges can take MINUTES to calculate a new game if you go too mad on the size. But Net seems to be very scalable without taking a speed hit or losing gameplay until you hit very large puzzles.

I really like these games, they are the only games that I played this week. I've got an F100 and I'm using the selector screen of GMenu2x with big snapshots as a nice interface for these games.

I'm glad you enjoy them. And thanks for letting me know they work with GMenu2x, I don't use it myself but I thought it would work just fine.

- You really need to draw a darker gray in Galaxies and Inertia. The gray slots are almost equal to the white slots in this games. Gray in Filling or Rect is ok, for example.

The colours are based on the default colours in the Linux GTK frontend. Basically, the games give the frontend a list of colours they want to use and the frontend sends back a message saying "These are the closest colours I have", so that people running in 256 colours can still use their desktop. The GP2X frontend does the same thing but the only colour it "insists" on is the light gray that is used as background - that was swiped from the default GTK window background colour. Everything else you see is the exact colour that the game requested (the GP2X is running in 16-bit (65536 colours) mode for the puzzles and the puzzles only "demand" about six or eight colours).

Now, I can "tweak" the colour array from the frontend to fix these sort of problems by telling the games to use a slightly different colour. I'll have to have a look and see what I can do. But I must say that Galaxies and Inertia are two of my least favourite games, so I hadn't noticed to be honest.

Can you configure Slat to fill the whole screen? That would mean a rectangular table of 12x8, I suppose.

I don't know what "slat" is but I assume you mean "slant". When the configuration window is ready for general use, you'll be able to configure anything that the games let you configure. If "slant" on PC lets you configure this (and it looks like it does), then you'll be able to do it then and even save it as the default for that particular game. The games you see in Beta 2 are just using their default settings but I can send configuration values to them to make them do anything that they allow themselves to do. I can do 30x30 games in bridges on the GP2X today, and for the past few months actually, (and everyone will be able to do the same when the menu system is ready).

Can you center games on screen?

You're not the first to ask and yes I can and it's very easy to do. I just have to add "fe->ox+" or "fe->oy+" to any line of code which draws to the screen, which is about 200 insertions. It's just a pain, that's all. I'm planning on having this in the next Beta. Changing the background to all-grey was done in Beta 2 for exactly this reason - the next one will centre the puzzles inside the grey area.

Thanks for porting these games! They are really, really fun to play.

Thanks for playing them!

 

[ledow]

Beta 3 *will* have game configurability from a menu when it is released. I have it working perfectly but I don't want to release it just yet until I've fixed some more bugs elsewhere.

This will let you make some games fill the whole width, play lots of different "styles" of each game (harder, larger, different forms) etc. The menu system is also incorporated to do this and so I can now implement "help" text as requested. I'm only going to include game basics on the instructions but at least that's something.

 

[juanvvc]

Beta 3 *will* have game configurability from a menu (...) I can now implement "help" text as requested.

I'm really looking forward to downloading beta 3

Thank you!

 

[Ze_ro]

* Loopy - Marking an x results in something that looks more like a dot, making it very difficult to distinguish from the actual dots that signify intersections.

Yeah, there's not a lot I can do about that. That's how the games scale their own screen. They are "playing" on 640x480 but they scale themselves to the GP2X's 320x240 just before they ask to be drawn on screen. I have plans to implement hardware scaling
Ah, so the collection has it's own scaling algorithm then? I thought it was a little odd, since the GIF you posted in the first post is only 150x150, yet the numbers are still fairly legible... in fact, none of the screenshots in that GIF seem to show the artifacts I've mentioned. Letting it render to 640x480 and scaling it yourself might turn out better... Some anti-aliasing would really help. Mr. Tatham probably never expected ports to have to scale DOWN.

QUOTE
Because of the nature of the puzzle framework, I'm unwilling to change a single puzzle to fix a particular bug (e.g. put red lines in "but only in solo" etc.). I work on the "frontend" code and haven't needed to touch any of the puzzles or even check which puzzle is running for it to do it's work.

Fair enough. I wasn't sure how deep you planned to go into making changes. I also didn't realize that he was still making changes to the games themselves.

QUOTE
The EXACT SAME CODE that I run on the GP2X runs perfectly on a Linux PC and plays mines properly. It's just down to this silly bug in mines. Basically, the GP2X expects numbers to be a certain way round and it doesn't get them in mines which is the only puzzle to do things using "unsigned chars" and "bitshifts", so things screw up big-time in that game.

Ah, code is expecting a little endian processor, while the ARM is big endian. That would certainly explain it. If you do manage to fix the problem (the correct fix in this case making it endian-agnostic rather than just porting it to big endian), you might want to submit the changes to the original author... after all, it's supposed to be portable, right?

Good luck! I look forward to future releases!

--Zero

 

[Exophase]

Oh man, I wasted so many hours on the picross clone a few years ago. Helped distract me through some really, really hard times you could say :/ I even took screenshots of a bunch of my 35x35 games (http://exophase.devzero.co.uk/bigbigwin.png, http://exophase.devzero.co.uk/bigbigwin2.png through http://exophase.devzero.co.uk/bigbigwin7.png if anyone cares, which I know no one will XD), pretty sad huh? 35x35 isn't a stock option, you have to pick it as custom. And it takes a LONG time to generate it.

Too bad I don't have an F200.. I can't imagine playing it with gamepad.

Oh, and ARM is almost always little endian, GP2X is no exception.

 

[MK2k]

Nice work ledow!

 

[ledow]

Ah, so the collection has it's own scaling algorithm then? I thought it was a little odd, since the GIF you posted in the first post is only 150x150, yet the numbers are still fairly legible... in fact, none of the screenshots in that GIF seem to show the artifacts I've mentioned. Letting it render to 640x480 and scaling it yourself might turn out better... Some anti-aliasing would really help. Mr. Tatham probably never expected ports to have to scale DOWN.

Yes, it scales itself. And SDL can also be set to scale it. But the problem is, as you say, the games were never really intended to scale down well. They were intended to scale up for newer computers with larger desktops, I assume. The scale code is pretty primitive and tied into the games themselves, but it's quite easy to do stuff like: render to a 640x480 surface, then do *some-fancy-scaling-algorithm* to bring it back to 320x240 for the GP2X. I've played about a little and the effect you get isn't really worth the effort (and it *is* a lot of messing about to get it to work nicely). I've seen much better success in replacing some of the functions I use to do anti-aliasing but the "midend" (i.e. games) only expect certain things to be AA'd - sometimes they like to draw a white line over a black line to wipe it out and that doesn't work properly if you have AA'd lines. But circles, polygons, etc. can be AA'd (I literally just put "aa" at the beginning of a name for a function in SDL_gfx and it works). I might include it by default at some point if I can be sure it doesn't mess up the games. I'm also looking at AA-text but I doubt that will help at all.

Anyway, I'm after speed and battery effeciency mainly, not pretty-looks. If I can clock down to 66MHz for most of the time, I'll be much happier than fixing an off-by-one-pixel error, unless it affects gameplay.

QUOTE
Fair enough. I wasn't sure how deep you planned to go into making changes. I also didn't realize that he was still making changes to the games themselves.


I don't mind making changes to the "frontend" (i.e. the SDL, drawing, input and GP2X-specific layer), but I don't want to do "if game=net then work around this bug" etc. That's just cheating and it'll break as things update, games get renamed, game get more options, new games need the same tweaks etc. Having said that, the configuration menu is fully-working but with one caveat - some games ("net" and something else) want you to enter "probabilities" from 0 to 1 and I have no way of telling which configuration options need that (instead of whole numbers) without literally hard-coding it. That's a pain in the butt. You can't even tell if a string in a config option is supposed to be a string or a number. Fortunately, in all the currently-released games it doesn't matter because they all use numbers but I doubt it will be long before someone reads the documentation, sees that part and then writes a game that lets you enter strings for some fanciful reason. That'll bugger me right up.

QUOTE
Ah, code is expecting a little endian processor, while the ARM is big endian. That would certainly explain it. If you do manage to fix the problem (the correct fix in this case making it endian-agnostic rather than just porting it to big endian), you might want to submit the changes to the original author... after all, it's supposed to be portable, right?


Yep, endianness and comparison of signed/unsigned char's. ARM suffers from them both. And the only game they affect is "mines", so I'm hoping that an upstream fix (even if it does end up coming from me) will be the solution. I've tried the gcc options to force certain things but it seems that it's not sufficient to fix the problem (it just changes the effect it has). Unfortunately, the "mines" logic code is some of the ugliness and most inconcievable I've ever seen (despite being perfectly good C, it's just horrible to try to work out WHAT it's doing, and I did courses in graph theory and game theory!). I know the line it stops on, I know why it stops there (a variable doesn't change even though it's supposed to have in the previous line), I've read through all the code that it runs, I've tried blanket-replacing a lot of the problem lines with different variable types but still I have know idea WHERE exactly it goes wrong. So it's on a backburner for now.

I'm hoping for an SVN update from the original author (who is still developing these puzzles and added a new "type" of Sudoku to the collection only the other day, not to mention update for graphical problems, compilation programs, MacOS X features etc.). I believe Simon Tatham works for ARM now, which would make it all the more embarassing if his "Portable" puzzle collection doesn't port nicely to ARM.

35x35 isn't a stock option, you have to pick it as custom. And it takes a LONG time to generate it.

You should try it on the GP2X, it takes forever! Having said that, the generate times are actually quite impressive seeing as they are just sheer number-crunching. They are favourably comparable to a 600MHz Linux laptop that I develop on and sometimes the GP2X wins!

Picross is one of my favourite games too. I've done all the gameboy versions, I've tired of Ghostpix (too much random guessing) and I'm waiting for a port of Logic Pro for MAME so I can get some more Picross action!

 

[paxl13]

[...]
Picross is one of my favourite games too. I've done all the gameboy versions, I've tired of Ghostpix (too much random guessing) and I'm waiting for a port of Logic Pro for MAME so I can get some more Picross action!

WOW ! I loved picross but i didn't though there was a mame game with this. Its pretty cool.

Thanks for the reference !
paxl

 

[ledow]

[...]
Picross is one of my favourite games too. I've done all the gameboy versions, I've tired of Ghostpix (too much random guessing) and I'm waiting for a port of Logic Pro for MAME so I can get some more Picross action!

WOW ! I loved picross but i didn't though there was a mame game with this. Its pretty cool.

Thanks for the reference !
paxl


Note only is it picross, it's two-player picross! The wife loves it, she does one half of the screen, I do the other, or she does the downs and I do the acrosses. I'm dying for a GP2X port. It's so fun when you are pressured by time and your partner messes up and you can shout at them and then YOU mess up and lose even more time... And it has bonuses and pickup's and all sorts that clear entire lines, etc. (but we generally avoid them unless we know it's only going to be a five minute game).

Logic Pro 2 is also good but not quite as fun, I feel.