Simon Tatham's Portable Puzzle Collection


Still working on cleaning it up. Have removed about 1000 lines of code lately, testing each time I remove a block to make sure I'm not buggering anything up. Removed about 500 extra lines of old code, comments etc. Tested more with joystick (drag-drop works well even with the joystick but for some reason is incredibly slow in "pegs" but not "untangle" or "map"? Dunno what's going on there).

They are going to be released one puzzle at a time because they compile as seperate executables anyway and some of them need little control tweaks to work nicely on the GP2X. If anyone is interested, could they tell me which games out of the collection they most want - and please consider how the control system would work on a GP2X. There is a list of them here:

http://www.chiark.greenend.org.uk/~sgtatham/puzzles/

"Net" is certainly going to be released first (my favourite). Then probably "untangle" (which by sheer chance is fully working even with the drag-drop and isn't at all affected by the off-by-one display errors). Then probably "Bridges". "Map" is way down the list because it's the one that's causing me the most problems because I can't figure out how it's drawing the mouse cursors and it just smears coloured circles whenever you drag - it plays right but displays bloody awful - as far as I can tell all the clipping/blitting is being done correctly but it just looks horrid - I may have to "patch" the game a bit and remove the cursors so they just look like a mouse cursor.
 
Okay, so it looks like the order of release will roughly be the following. I'm hoping to get them into some sort of distributable state over the Easter holidays, which for me is the next three weeks. Don't take that as fact, though.

Most tested and verified working through lots of complete games:

Net (most tested, works very well without any problems)
Bridges (very well tested, works very well without any problems)
Mines (user request, works very well without any problems)
Untangle (works very well without any problems)
Cube (works very well without any problems)
Fifteen (works very well without any problems)
Blackbox (works very well without any problems)
Tents (works very well without any problems)
Pattern (font display a bit too small for some puzzles, but otherwise fine) - I'm not too worried about this one given that the excellent GhostPix is the same type of game and infinitely better.

Only basic testing has taken place (i.e. I played with them for a little while by clicking around and checking things changed, and completed the ones that I was able to complete, without any major problems showing up) for these ones:

Dominosa
Flip
Galaxies
Guess
Inertia
Lightup
Loopy
Netslide
Rect
Samegame
Sixteen
Slant
Twiddle

These ones will have to wait until I have released most of the above due to some problem with them:

Map (drag-drop display problems make playing it very ugly)
Pegs (needs looking at to find a quite annoying slowdown when dragging that wasn't there until a few revisions ago, probably SDL Timer related - it looks like it's trying to draw circles over circles over circles as you drag the "mouse")
Solo (requires keyboard input of numbers, so I'll have to bodge that with GP2X controls)
Filling (requires keyboard input of numbers, so I'll have to bodge that with GP2X controls)
Unequal (requires keyboard input of numbers, so I'll have to bodge that with GP2X controls)

If anyone would like to suggest a mapping for the keyboard, or express a preference for right/left/middle click buttons on the normal games, I'd be open to ideas. At the moment, I'm using shoulder buttons but I think it might be easier long-term if I use the top three buttons (A,B,X?) of the right-hand side for "mouse clicks". L+R shoulder buttons will probably change numbers in those games that need them. Select will probably be "restart this game". Start will probably be "new game", with vol+/vol- being "quit".

I'm hoping that F-200 users will get touchscreen but I can't guarantee it as I don't have one (and, honestly, don't really care that much about it so long as it's playable in some fashion, although I am being careful not to use stick-click and other F-100-only features) - but if it's seen as an SDL mouse or it's easy to code, then it will be so. From the look of it, I can open a device file, read an entry and get X,Y co-ords which is enough for "click" but then I'd worry about how you'd right-click or middle-click (probably holding down the relevant button while pressing the screen but then that's more coding to differentiate between F-100's and F-200's and F-200 users who want to use F-100 style controls, etc.).

Changing sizes/difficulty of the puzzles will have to be done by supplying command-line parameters (so a simple menu system could take that away from the actual program executable quite easily), and saving/loading/playing a particular numbered game I really don't care about and stripped out, so all that code would have to be reintroduced by someone else. I suspect the easiest way would be to supply a command-line argument again.

In the future, users would have a "puzzle menu" (which could be quite a simple C / SDL program but I'm not going to write it) which would allow them to select games, change difficulty, size etc. and then run a game. When the game quit, it'd go back to the "puzzle menu". Without such a menu, these programs would have to be run inside script-wrappers if they are to re-execute the main GP2X menu. I'll include those because I care about that, but I don't want to get involved in making a "puzzle menu".
 
For those following the development of these games, I've just fixed the following bugs and I'm gearing up for a release of all the games. Unfortunately, a few still have problems but I see no reason to hold back and do single-releases for much longer.

- You can now input numbers using the L and R buttons and X. This allows you to play filling, solo (sudoku) and unequal. Solo plays fine but unequal needs a specific fix because by default it only uses the numbers 1-4 as far as I can make out. As Solo needs 1-9, this is a pain and means I need game-specific code to make it work with the L/R/X control system. I just need to make something show what number you have selected because at the moment you have to put the number in to find out, then change with L/R. It stays on the same number until you press L/R though so numeric-input games are playable if you can remember a single-digit number.

- I've fixed a few bugs here and there related to mouse/keyboard input. Most people probably wouldn't have noticed as they only affected games that haven't been released yet.

- I've fixed the absolutey idiotic mistake of mine that makes the wrapper-scripts point to the wrong path (I'm a prat). The directory structure will change for the "full release" and I forgot to change it back for the individual release.

- Mines is giving me more problems than anything else, now, despite running perfectly within the development environment. For some reason on the GP2X it doesn't play correctly from the very first second, even though there is NO GP2X-specific code run up until the point it errors out with an "assert". I've looked at the code around the assert (which is in mines.c and I've NEVER had to do anything to the game code, only the SDL interface code) and I have no idea what's wrong.

Running mines on plain Linux with the exact same code, screensize, bit-depth, SDL libraries etc. doesn't give you any problems. It's either a very subtle timing bug or a problem with memory (but I would expect memory errors in that case). Mines, unfortunately, may have to be pushed to the back of the queue.

- I've made it so that L+R now quits, because it's easy to hit Vol+ accidentally if your finger slips off the control pad on the F-100 (I was SO close to finishing my game of dominosa!). I might change that to Vol- / Vol+ in future.

For the games not mentioned below, I haven't tested them thoroughly but they seem to play fine. I'll reserve judgement until I can complete a whole game on them just to make sure but I think they are all releaseable.

Bridges - I have a slight problem with "locking" squares but that just seems to be the way the game works. Once a circle is locked, it's a pain to unlock it. It can be finnicky on my Linux PC too, maybe the lower clock speed exacerbates the problem a little?

Cube - In a state that I could release it.

Fifteen - In a state that I could release it. Sometimes a little slow on animation - using hardware SDL surfaces or overclocking might speed that up but I'm not too worried as it just "skips" animation frames rather than slow the game down.

Blackbox - In a state that I could release it.

Tents - In a state that I could release it.

Pattern - font display a bit too small for some puzzles, but otherwise fine.

Dominosa - In a state that I could release it.

Flip - In a state that I could release it. Sometimes a little slow on animation, like Fifteen.

Guess - Drag-drop problems like Map but playable. I'll probably just edit the game code to remove the cursors, because I've tried lots of different things to stop it doing it and none of them have made the slightest difference.

Lightup - In a state that I could release it.

Netslide - In a state that I could release it. Sometimes a little slow on animation.

Rect - In a state that I could release it.

Samegame - In a state that I could release it.

Sixteen - In a state that I could release it. Sometimes a little slow on animation.

Twiddle - In a state that I could release it. Sometimes a little slow on animation.

Map - drag-drop display problems the same as Guess.

Pegs - drag-drop display problems the same as Guess but which also lead to an enormous slowdown when you drag, making it unplayable. This is the only problem with pegs, though.

Solo - In a state that I could release it.

Filling - In a state that I could release it.

Unequal - In a state that I could release it. Sometimes a subtle bug crops up.


Anyway, expect a release of all the games in their current state "soon". First, I have to fix the mouse once and for all, then get rid of the drag-drop problems that stupidly stop two games from working when the drag-drop display is totally unnecessary. Then I may add a few little touches such as showing the current digit for the L-R buttons, maybe a quick menu for all the games.

I'm also intending to do a full source release with the full collection, with full LICENSE files, a nicer directory structure, all of my build and test scripts, even the exact Open2X toolchain and libs that I used to get it all working.

At least one person wants to take that and try to port the collection to PSP using my SDL code.
 
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.
 
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.
 
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!
 
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... :D )
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.
 
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.
 
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.
 
Sounds great. Will be looking forward to that.

Keep up the good work. :)
 
Beta 4 now released.

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

Massive changes including:

Fixed the crash caused by dragging off the screen in map/pegs/guess (why did nobody tell me about this?!)
Centered all puzzles.
Added default configuration saving.
Added game saving (10 saveslots, use L and R while paused to select slot, Select to save and Vol-/Vol+ to load).
Fixed timers while paused (only affected mines anyway which still isn't working).
Revamped all mouse code.
Saved a bit of memory here and there.

I'll upload it to the archive when I can but it takes forever to upload and forever to be "approved", so that'll come later. When it's up, I'll officially announce it on the news page.
 
You must log in or register to reply here.

Similar threads

J
Simon Thatham's Portable Puzzle Collection
2
Replies
22
Views
5K
Quiest
Quiest
EvilDragon
Simon Tatham's Portable Puzzle Collection
Replies
1
Views
2K
Abaddon666
A
ledow
Simon Tatham's Portable Puzzle Collection - Net
Replies
3
Views
3K
ledow
ledow
ledow
Simon Tatham's Portable Puzzle Collection - Untangle.
Replies
7
Views
5K
ledow
ledow
A
Stppc For Caanoo
Replies
10
Views
5K
u9i
u9i
Back
Top