BETA 4 News

Okay, BETA 4 is taking a little longer than I want it to but not for any particular technical reason, I'm just doing other things and chasing stuff that's not "visible" to users (e.g. I've been working on game saving for ages but none of the BETA's have yet had any code related to that in them). Mostly refactoring stuff so that the code is more readable and a bit more structured, debugging is simplified, and the menu drawing code isn't *quite* so horrible as it currently is.

When it *does* arrive, it'll have:

- Centered puzzles on the screen (finally - sorry it took so long)
- "Save Default Config" - pressing X on the pause screen saves that configuration (provided it is a valid one) into a human-reabable INI file, which is loaded each time the game is first run. Removing the INI file reverts to the game defaults. On unwritable systems (e.g. write-protected card or one where you don't want to save the config), the game just uses the current defaults but still lets you change them (obviously you can't save them in that case!)
- "Save Game" - You can save the current state of a game (not just the config) and resume it later. At the moment, it's more of a "quicksave" in that there's only one save slot that you can save/load. Handy, though, if the battery light starts to flicker, you can just hit the save option and resume it once you've changed the batteries.
- Tweaked the font sizes etc. a bit
- Mouse acceleration (primitive but it works)
- A couple of memory leaks plugged, a couple of minor bugs fixed, a bit of memory saved.
- Fixed a stupid bug where pressing Solve while you were paused buggered up the screen a bit.

There is one INI file per game, that gets created when you press Save if it doesn't already exist. If you don't press Save nothing is ever written to your SD card. As soon as the INI file is written, the cache is flushed so that the data hits the disk ASAP. Once you get a message to say it saved successfully, it should already be on the disk.

Everything will be saved into these INI files - Saved games (yes, you can save a game into an INI file), Settings, "Presets" (saved blocks of settings), help text, the lot.

The savefile format is plaintext (which gets "INI-ised" when it gets saved), so it's even "editable" from outside the game. Basically it consists of a complicated string to describe the starting point, options, size, game, etc. and then a list of moves that have already been made. The game "replays" the moves when it loads and you end up where you left it. I think I may have to disable access to mines, though, because it's still doing weird stuff and I don't want people to press Save while the game is in a weird state - the game may throw a wobbler when you try to write out a weird save state. Savegames are tiny - you can happily save dozens in each game without adding to the size of the folder noticeably.

Loading in a weird game state isn't a problem - the INI parser library just ignores any rubbish in the file and passes on what it can. The games then each check that the savegame / options are completely valid before they try to play them. This is to try to stop people loading corrupt save games, or those that have been "played with".

I'm trying to avoid playing with the menus at the moment because that code is getting a well-deserved shake-up but once it's done, I hope to introduce more save slots and a way to change between them, and a way to save configuration presets. That may or may not be in BETA 4 depending on how quickly the work progresses and how well I can squeeze them into the menus.

Unicode, font, SDL and graphics.

I have just added the feature to allow people to configure the games in STPPC2x. On the way, knowing that my graphical design skills are somewhere in the realm of a small five-year-old with a large crayon, I wanted a quick way to "pretty" up the interface without having to draw anything myself.

I needed a checkbox, which is quite an easy thing to draw anyway. I wanted one that I could tick, cross or leave blank and which wouldn't look like I'd drawn a square box around a poorly fitting line-based cross or tick.

In the end, I looked at what resources I already had included in the project (allowing code re-use, not to mention keeping necessary dependencies to a minimum) and I already had SDL_ttf and the DejaVu font. The font was a random choice because I just wanted a "free to distribute" font that was small and easy to read, but it turned out to work very well.

Hidden away in the depths of the Unicode specification, there are a multitude of symbols that hardly anyone ever uses or even sees. These, apparently, include things like several styles of cross/tick (including "ballot" styles, made to look like a hand-drawn cross/tick), chess figures, dominoes, dice, and all manner of symbols, logos and signs. The mathematical symbols were also out of this world, line-drawing characters, "disabled" symbols, you name it. There are even circled numbers and letters, which prevent having to "guess" how big a number is going to render, fudging the font size and then circling it manually.

As it turned out, the DejaVu fonts have remarkably good Unicode support (the only other real competitor that I have personally seen is Arial Unicode, but obviously there are distribution problems with that one) and included all of the symbols that I felt like using.

But someone could easily write a board game, or avoid spending hours recreating a symbol in a vector format, using the Unicode characters, precise sizing and the DejaVu font. And, obviously, being a font it scales well to all sizes, can be coloured etc to your heart's content and can be rendered inline with text without causing problems. And the DejaVu fonts only take up half-a-megabyte, if that, and contains thousands of pieces of "clipart".

So, with SDL and SDL_ttf, it was simply a matter of changing my conservative SDL_RenderTextSolid to SDL_RenderUTF8Solid and figure out how to include the characters in a C string (Gucharmap on Slackware Linux was a big help here because it gives you the C escape codes for the UTF8 versions of any character in a Unicode font). No more memory is used, no more code is needed if you already have font-rendering code in there, and only a tiny amount of disk space is used for the whole thing. It was a great find and it's improved the look of the menu I was writing immensely.

More Pre-Beta 3 news.

Okay, BETA3 is nearing.

- Help and instructions for the games are included in a basic form (basically a text file printed to the screen). In later versions I may include further windows with general controls and pretty graphics, but for the moment, you can press "Help" under the Pause menu and you get the snippet from PUZZLES_QUICKSTART.TXT that I wrote for the first beta. The text files are editable and once BETA 3 is out, people are welcome to submit an explanation for any game that they think they can explain better (Plain text, 60-columns max, 20 lines max, don't use spaces or tabs for ASCII art).

- Game configurability is in, again in a basic form and I'm working on making it prettier without adding more rubbish into the executables (Unicode dingbats and the Deja Vu font are helping a lot!). All three types of option work ("string", or selecting a number, "boolean", ticking true/false, and "choose", selecting from a dropdown list of predefined options). You can configure all the games but sometimes a particular game has too many options and one or two go off the bottom of the screen ("net" is one culprit - you can edit size, difficulty etc. but not an option on the very bottom), and sometimes you have to select a "probability", between 0 and 1 - that's a pain that I have to manually detect and counteract on a per-game basis (Yuck!). But you can quite happily play and configure virtually all the games to your heart's content. I'll probably leave the fix for the "off-the-bottom" options until another BETA because it requires a revamp of the menuing system.

- Pause menu, which has taken the functionality of New Game and Restart Game out of the Start/Select keys to stop accidents. This is also where configuration, help, etc. can be accessed without affecting the game. If someone has a nice FREE (as in Creative Commons or better) background that would work with black or white text over it, I'd look into the possibility of using that as the pause menu background.

- Background colours have been tweaked ever so slightly. Most people probably won't even see the difference.

- CPU usage is reduced, but you may not notice because it's in areas that don't affect display. I'm hoping to clock down the GP2X quite low when it's on the Pause menu and when the game isn't doing anything (i.e. no animation timer activated, no clicks received) in order to save people's battery life.

- Executable size is significantly reduced. The games are about 50% of the size of previous Beta's with no loss of functionality or visible increase of startup speed. This saves about 15 or more Mb of the size of the total collection when put onto the GP2X, but you won't notice a difference in the already-ZIP'ed download size.

- Patched a couple of possible memory leaks/segfaults that were plaguing post-Beta-2 versions.

I've got a few more prettifying things to do, but I have these on my own GP2X F-100 that I take to work every day and they are very solid and the configuration works really well.

Some more news on the STPPC2x front:

Beta 3 will hopefully contain help and instructions for the games. If it takes too long, I'll be pushing that back so that people get to use the new configuration menu system first. I was going to use the existing puzzle instructions and some Wiki graphics for controls to help this along but nobody's quite sure of the license for the wiki graphics and the existing instructions are probably too long.

I'm aiming for a single window per game, accessible from the normal pause menu, which gives you the basics for that particular game (How to play) and a single generic window specifying information common to all games (Controls, how to pause, quit, etc.). It would most probably be a text file for the game, so new games can have instructions written by anyone. Unfortunately, it would have to be manually updated for each game which is a bit of a pain, but you can't have everything.

I was *toying* with the idea of some background music (obviously, with an on/off switch) but I don't know if I want to waste my time on that. It started when I thought that a "mouse-click" sound might be a good idea to put into the game. It seems incredibly simple to do, especially with SDL_Mixer, but I usually hate such unnecessary padding.

My plan, if I do implement sound, will be to have, in this order of importance:
An on/off switch for all sound.
Volume control for all sound.
Music in the menus, sound in the game.
A basic MP3/Ogg file in the game folder that people can change to their hearts content (e.g. "backgroundmusic.mp3", "clickeffect.mp3", etc.) so that if they prefer a different tune, they can have one.
A free (Probably creative commons) piece of music and sound effect included with the download (ideas welcome - but with my playing, probably the Mission Impossible theme tune would be best... )

I'm planning to look at saving/loading of games for Beta 4. It's annoying to get through a large game of bridges, only to have the battery die and you can't get it back. Saving/loading looks simple (the puzzles tend to do everything necessary except actually open the file and write to it) but it's the *first* line of code in the games that writes to disk, so I want to be incredibly careful. I'm not sure how it would work just yet but probably it would save to a sequential filename (e.g. net0001.sav, net0002.sav, bridges0001.sav etc.) each time you save and present them in reverse order for loading (sadly, there is no RTC on the GP2X otherwise I would have them named with the date).

CPU usage and speed is also on my list for the next Beta (although Beta 2 made tremendous leaps in that area especially where puzzle creation is concerned) - I'm setting up a code profiling system at the moment so that I can find the hotspots in the SDL code. For sheer number-crunching, the latest GP2X code can generate a 30x30, Hard, 4-bridges-max game of bridges in the same time (or less) as a 600MHz laptop, so I don't think I'm doing too bad on that front (a credit to ARM processors!). The display/animation is a little slower because of software drawing/scaling but the games have adjusted to take account of that since day one (you get less fps when it's animating a move than you would on a PC) - hardware acceleration would solve that problem but it has its downfalls too. Ideally, I'd like to be able to clock the GP2X right down to 66MHz when it's not generating a game or performing an animation (which is about 99% of the time it runs for).

Also, executable size is up for a revamp - I already have #define's for things the GP2X doesn't need, and I strip the executables but I think there's a lot more I can do to shrink them. There is some unnecessary but *seemingly* used code in them which the linker/strip doesn't like to remove, there is no end of fancy tricks to reduce the size including using an executable compressor like UPX on them. There are other things you can do but they all tend to cost you more in terms of memory (even UPX is an initial memory usage vs executable size trade-off), such as zipping the fonts, etc. Even if I save myself, say, 10 Mb on the entire collection without visible differences, I think it's worth the effort.

Anyway, look out for Beta 3 coming "soon", with game configuration menus, pause and (hopefully) instructions inside the game.

Teaser snippet from the Changelog for the next Beta 3 (not released just yet, a few more tiny bugs to iron out):

2008-04-13:
- Implemented pause on the Start button.
- Implemented game-independent colour routines to define black and white for text no matter
what the game uses, so that the status bar always shows up.
- Added game configurability for all games under the Pause menu.
This greatly increases the potential of the puzzle collection and lets you configure
the types of puzzles in all manner of ways. So you can play bridges on a giant board,
cube with an octagon, dominosa with more dominoes, solo in a number of different ways,
net so that the board "wraps" and a million others.
The Pause menu hides all the confgiuration, and you have to start a new game from there
for the options to take effect. The games will tell you if you have set options
incorrectly, e.g. tried to play on a -1 x -1 board etc.
Most games work flawlessly with the options, but some are still flaky because:
- It really needs scrolling for the games with more options (e.g. bridges).
- Some games want you to be able to enter non-integer numbers (e.g. 0.1) but
it's almost impossible to distinguish them from the frontend.

Yes, you can change, width, height, difficulty and every setting possible in the games to suit your taste.
It all "just works", the screen shrinks down and does what it's supposed to do, so don't go too mad and
try and play 30x30 bridges on the GP2X because the chances are that you won't be able to see anything because it will all shrink to fit.

You'll even be able to try new versions of Solo that so far only the SVN version has (so they are not even available in any "official" release from the author himself yet! :-)

Oh, and if you think this port was worth the time and effort you had to wait for it, please have a quick look at my website where you'll find a "donate" button. Got £0.87 left in your Paypal from your recent eBay refund? Why not send it to a programmer!

Beta 2

New beta 2:

STPPC2x Beta 2

Just thought I'd give people an update since STPPC2x Beta 1. The following features will make it into BETA 2, which would almost be v1.0 if it wasn't for mines not working at all - the only game with remaining gameplay issues.

2008-04-07:
- Fixed map's and inertia's drag-drop display problem.
I'm a pillock. Having your source and destination the wrong way round means
that any amount of checking of your parameter values is useless if you don't
check the ORDER of arguments as well. I still say that the functions use
a "backwards" nomenclature for "blitter save/load" but once I switched them
around, it all started working properly without any other hassles.
- Fixed pegs and sped up all games by putting screen updates in the right places.
I'm still a pillock. Although it still draws lots of primitives, we *now* don't
update on every one of them, just the final "drawing". So instead of many
intra-frame updates, we get one end-of-frame update. The documentation wasn't
at all clear on this but I should have debugged it properly earlier.
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. I didn't do this before for
debugging reasons and because it worked without it but for the sake of completeness
it now keeps copies of fonts in multiple sizes in RAM in case it re-uses them rather
than constantly load/destroy/load/destroy fonts as the sizes in use changes.
It still doesn't distinguish "types" of fonts (monospaced etc.) but that's only a
minor addition.
- 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.
- Removed a few bits of unused / unnecessary SDL code.
e.g. initialising audio, overzealous locking, freeing of surfaces that get freed
anyway,...
- Tested code with proper hardware accelerated surfaces.
Little to no performance difference but strange problems related to dragging in
untangle, for example, which gives "jittery" cursors when using page-flipping.
Reverted until cause can be found (not a high priority given the small advantage).
- More error checking and bailing out with a nicer error on certain failures.
e.g. fonts not being present, blits failing, etc.
- Looking again at mines quickly but it's still weird.
- Made sure that the cursor doesn't linger after the game has quit.

I've just fixed another round of bugs/new features:

- I now have working "status bar" display, so you can see how many moves you've taken, whether you've completed the game or not etc. The same code will be used to display which number is currently selected for input in filling, solo and unequal.

- I've just found an incredibly stupid bug of mine that was loading a font every time it was used without closing it properly (a code path problem that I hadn't noticed). This meant that "fifteen" was getting to about 50 moves and then running out of memory (50 x 20fps x [number of characters in game] x [size of font characters in RAM] x [probability that it would take the bad code path] > [RAM in GP2X]!). How it survived for so long, how it didn't show in other games, how it doesn't make the machine run out of memory quicker, I have no idea. But quitting the game made it clear up after itself and you could run it again or load any other game without problem!

That's now completely fixed and I've gone through the whole code again looking for missing/skipped free's and close's to make sure it doesn't happen with anything else. SDL does a damn good job of clearing up after itself anyway, so memory leakage isn't a problem if you quit a game and then run any other, but I don't like stray pointers. The games don't write *anything* to "disk", i.e the SD card or NAND, but that's no excuse for not checking that everything frees itself properly. I thought I'd been particular careful but apparently my wife makes a very good bug-finder despite never having coded in her life.

- I've linked against Paeryn's SDL libs instead of the default Open2x and it appears to work absolutely fine. However, this opens up the possibility of using hardware accelerated surfaces to do fancy zooming tricks and work the F-200 touchscreen without having to change any code. Again, people with actual F-200's would need to test to make sure. This also allows "panning" of the game area, although I haven't implemented that yet. So, in theory, you could have a 640x480 playboard and move around it by touching the edges of the screen. This would make "pattern", in particular, much easier to play.

- The mouse is now much smoother and faster but still seems to have problems with the way it moves on F-100 at least. You should now be able to switch between left/left-up/up without problems but on the F-100 it sometimes stops for no reason and you have to press the direction again. I've tried several of the "joystick biases" from the Wiki but I can't stop it happening. Anyway, it's much more comfortable to play now.

The following are not implemented (deliberately) on any game but usually run to no more than a handful of lines of code each, plus a GUI to do them in:

- Saving/loading functions (I don't like writing to other people's disks from C... However, the games automatically save/load themselves to an ASCII string using built-in functions and it's just a matter of putting that string somewhere and then letting the user get that string back... that will almost certainly involve GUI work which I'm not interested in doing, or passing command-line parameters from a menu with a GUI that I'm not going to make either)

- Clipboard functions (GP2X hasn't got one!)

- Changing game parameters, like size, difficulty, etc. (a simple matter of querying the midend for parameters available, collecting the parameters from the user and passing to a function... this is all code that isn't affected by my SDL code but someone would have to design an SDL menu that adjusts to each game or another way of presenting the user with a list of options and passing them to a function. I have tested it briefly and the games will automatically adjust to the size and difficulty specified as that is all done within the game code, not the display code)

Icons inside the executables (I can't be bothered to figure out how to do it, but there are .png icons already supplied with the game and I'm really not that interested, especially because I run the games through wrapper scripts which can't have icons! And people using things like GMenu2x or similar can just use the game's icons, I assume).

I'll be submitting a "beta" version of the entire collection once I've had a few more attempts at fixing the outstanding problems (mostly with mines, because that's the only one that's completely unplayable). That will most probably be synched to the latest SVN version as well but the only things that have changed since the revision I'm using are some MacOSX fixes, a tiny "fix" for code cleanliness and allowing you to "drag" and set multiple squares at a time in "filling", so it may not be worth it if it breaks anything at all.

The full collection is 27 games (Eek! I never realised it was that many). 22 are fully-working with just minor display issues that don't affect gameplay. 2 have drag-drop display issues (map, guess) that don't affect actual gameplay. 1 is incredibly slow but works (pegs) and I believe is down to the same drag-drop display issues but exacerbated by the dragged bitmap being larger. 1 sometimes has problems if you use a particular feature (bridges, locking an island with right-click) but it otherwise playable. 1 has fonts too small due to the nature of the size of the game (pattern) but if you squint you can read it. And 1 is unplayable (mines, quits safely on startup with an assert error inside the game code, not the interface code). I don't consider that a bad track record, personally, given that I've built a whole new frontend.