Back on the Map

Last time around I did some updates to libmikmod and the sdl-mixer library.  Considering my previous lack of testing on them, I decided it'd probably be best to be a wee bit more thorough this time.  So I tracked down some oldschool galaga style games and gave them a zipit makeover.  I'd really prefer to get a nice version of centipede, joust, or one of the many zelda clones on the zipit, but didn't see anything that struck me as easy, so space shooters was it this time.

I started with dodgin' diamond and all went well.  Even the two player mode seen above appears to work, although it's difficult to get 2 different hands on the zipit keyboard at the same time.   Next I decided to give the fancier looking powermanga game a try.  I thought I maybe powermanga would be a more challenging port, given the code size and some floating point bits, but it was pretty smooth right out of the box on the medium sound quality setting.  So I'll take that as a win and move on.

I still wanted to leverage my success with the fixed point supertux patch into something more substantial, so I decided to see if I could do anything with protracker.  I'd like a few more tracker options on the zipit, and my little piggy tracker port was stuck on a blank screen for some reason.  Meanwhile protracker looked almost feasible.  I did a quick and dirty screen hack to remove the pixel doubling and chopped last 15 rows of the display to fit it onto the zipit screen.  It actually looks fairly decent, but appears to require the fake mouse controls on the dpad buttons, and all sorts of internal mixer and filter code needs a conversion to fixed point if I ever want to hear more than an occasional squeek out of it.

Unfortunately, about halfway through the float to fixed point conversion, we hit the Christmas holiday season and the zipit irc channel came alive with chatter.  Someone mentioned the pspmaps location lookup appeared to be broken.  My attention deficit disorder took control and off I went into fixit mode.  It didn't take long to discover that google had shut off the V2 googlemaps API a while back.  The V3 options were JSON or XML.  No sign of the CSV and KML options from V2.  Oh well.  I'd been meaning to tinker with JSON again someday.  And now that day had arrived.  I checked out a few small JSON libraries for C, but I'd seen cJSON before in the opentyrian code, and it looked simple enough, so I went with that.  After a modicum of testing, I had a working fix for both the location and driving direction lookups, so I bumped the version number.

Someday I'd like to add an option to use the OpenStreetMap lookup as well.  That way there's a backup solution, just in case google decides to obsolete their API again.  Also, I suspect openstreetmap might make it easier to add support for more permanent offline map sets.

I noticed the original pspmaps site was gone, but there was a github project with a few odd fixes from just before the google API change.  So I forked it, got back up to speed with git (after maybe two years of rust), and rebased the openwrt-zipit pspmaps project off my github fork instead of the dead link to the past.  I still haven't restored my openwrt-zipit build system after the recent hard disk crash, so hopefully somebody will notice and rebuild the openwrt pspmaps package.

Here's the goodies:

dd2-iz2s.zip

powermanga-iz2s.zip

I still need to package up pspmaps.  For now here's a new executable and urls.txt file for pspmaps on openwrt.  Just untar it in the pspmaps directory.

pspmaps-update_2_4_wrt.tgz

Do the same for the iz2s executable.

pspmaps-update-2_4-iz2s.zip

I'll have to do another blog post if ever get one of those trackers working.

In the meantime I should probably say something about the Navit GPS/map program since it came up in the same IRC conversation as pspmaps.

By following the TomTom build recipe I got it to compile for iz2s, as a possible offline map alternative to pspmaps.  Apparently it wants to be in Germany?  However it crashed when I attempted to bring up the internal gui, so it clearly still needs some work...

Update:

Ok, I fixed the crash and found the maemo build recipe, which had some more clues on how to configure it better for the zipit, like converting the svg icons to png, and discouraging floating point math.

I still have a few more icons to track down and convert, but most of the menus look all right now.  Perhaps it's time to fetch some more map data, other than that sample patch in Germany.

So I visited the Navit Planet Extractor website and fetched me a rectangle of OpenStreetMap data.  The smallest chunk it wanted to give was around 80 megabytes, so I went with that.  It sorta worked.  I could search for towns and streets contained within the map data, but the map itself was a mess.  It was very slow to update and missing (or simply not displaying) features that I know should be there.  Perhaps the 32 megabytes of RAM on the zipit is not enough?  I've read some notes that suggest Navit is not the most efficient app in the world.  I'll have to play with it some more and see it there's any way to make it feel like a useful tool on the zipit.  Or maybe I'll just grab the 700MB prepackaged blob of north east corridor USA map data from the Planet Extractor and see if I can make the zipit pop...

Or maybe I should try to use something like gmapcatcher to fetch map tiles for pspmaps.  I might have to reorganize the pspmaps cache to be compatible with the directory structure though.  It looks like it might be close.

Update 2:

It actually was pretty close.  Well, not really.  The pspmaps cache is a simple list of N numbered png files.  The meaning of those files is stored in a separate disk.dat file as a list of x,y,z coordinates (and a number for the specific map service), one entry for each numbered file in the cache.   It's these entries that match the directory and file structure of the gmapcatcher data, exactly.  They also match up with the OpenStreetMap Slippy map tilenames convention.  That meant it required just a few new lines of code in tile.c to convince pspmaps to check the offline gmapcatcher data before resorting to a network lookup.

Here you can see where pspmaps used some offline tiles saved by gmapcatcher.  I used two different map servers so I could be sure.  On the bottom left is a tile fetched from google by pspmaps.  The rest of the image is made up of tiles pulled from the offline files saved by gmapcatcher.  I forget which map service it was using, but you can easily see the difference.

Anyhow, I'll eventually put some sort of Navit package for iz2s here, and another revision of pspmaps too.

Update 3:

I've run out of vacation time so I zipped up a Navit package for iz2s.

navit-iz2s.zip

I haven't yet tried any of the large pre-made data sets, so I don't really know if it's actually useful.  I'll get back to it eventually.

Meanwhile, I think pspmaps has a lot of untapped potential.  I put the code in my github repository and added my offline map code to work with the OSM_tile data from gmapcatcher.  I also fixed it to remember a preferred default map service, and tweaked the code to allow you to skip map services that don't interest you.  

I've got a few other small changes that I'd like to make.  The simplistic linear searching disk cache implementation could use some work to allow it to scale up.  Maybe hash table lookups, or at the very least least make it do a binary tree search.  I'd also like to add some simple versions of the gmapcatcher functions.  A small radius local area capture with a few autozoom levels would be nice.  And an OSM_tile format offline map export function would make it possible to use the zipit instead of gmapcatcher in a pinch.  And of course I still want OpenStreetMap location and driving directions lookup as an alternative to google.

Some wilder ideas include better driving directions, with access to the text version of the route, and maybe markers for the turns.  Point of Interest data might also be fun to play with.  Maybe OpenPOIs or the OpenStreetMap Overpass_API would work?  I could probably use some of the 16x16 png icons from Navit as the markers...

Hopefully I'll have something worthy of a release soon...

Ok, this has the offline stuff and allows you to comment out map services that you don't want in urls.txt.  See the readme.txt file for details.  Once again it's just an updated executable with urls.txt and a readme file, not a full package.

pspmaps-update-2_4-1-iz2s.zip

Same for the wrt update...

pspmaps-update-2_4_1-wrt.tgz

Update 4:

As life would have it, I actually got a chance to try out pspmaps in a real world situation. I had to visit a company near Boston to get me some nifty software training for work.  Christmas flew by and I still don't have a smart phone with a data plan, so I loaded up the offline cache in pspmaps on the zipit.  I also generated some driving directions.  It worked, but just barely.  The screen is just a wee bit small to see enough of the map while driving, the thin blue directions line was barely visible at night on the road, and I really could have used the text directions.

I can't do much about the screen size, so I widened the blue line in the code and got to work on parsing the text out of the JSON driving directions.

 Wider is better

I'm using the SDL_rtf sample app as a mockup for the display.  It works reasonably well for my purposes (and I still dream of a minimal word processor app on the zipit someday) so I think I might stick with it when I fold the code back into pspmaps.

While I'm at it, maybe I should try to hook up the flite speech synthesis from the bard package to read the text out loud.  At the very least I should try and feed this sample text to flite and see if the pronunciation is intelligible.  That should be an interesting exercise.

Update 5:

Ok, I haven't tried to hook up flite, but I did fold the SDL_rtf driving directions code back into pspmaps.  I really like the way it autowraps the text for me because I wasn't looking forward to writing that part myself.  I had a bit of confusion with latin1 text until I realized the rtf unicode escape sequence \uN is apparently not yet supported in sdl_rtf.  However testing reveals I can simply convert the directions to extended ASCII from the 8 bit latin1 codepage and use that, as seen here.  

 Better watch out for the speed cameras!

The last release of SDL_rtf is more than 10 years old, but it's had a few unreleased updates on the SDL mercurial repository.  I fetched the most recent update for SDL-1.2, from 2012, but didn't see anything that looked like unicode escape sequence support.  So for now I'm sticking with the SDL_rtf v0.1 code.  I added SDL_rtf to the list of openwrt-zipit packages but I don't have a compiler set up to build an actual package for it.  Because of that, I decided to static link SDL_rtf into some pspmaps executables.  

Here's another round of executable updates (and the urls.txt config files).

pspmaps-2_4_2-iz2s.zip

pspmaps-2_4_2-wrt.tgz

The Backspace key gets you to the text directions screen on the zipit.

Faking it, Part 2

Last week I had some pretty good luck with a quick and easy build of the wetspot2 game that I discovered on the gcw zero recent news page.  So I thought maybe I'd go for a twofer and cherry pick another easy target off that list.  I measured things up and decided the last-mission game also looked ripe for the picking.  Naturally, things weren't nearly so simple.

Remember last month when I confessed to pushing a fake build of libmikmod in order to fascilitate a quickie build of SDL_mixer, which I needed to get sdlbasic running?  Well, it turns out libmikmod wasn't the only joker in the pack.  Apparently I also skimped on the SDL_mixer build itself.  I vaguely remember that was somewhat of a challenge to compile because I wanted it to use libmpg123 instead of libsmpeg.  But that involved a bunch of finicky hand patching.  When I finally got that going I failed to check out the other build options.  Turns out the default ogg support is the floating point version, not the fixed point libtremor code that works on the zipit.  Oops.

Which brings us back around to the last-mission story.  I was getting nowhere.  It would load a blank black screen, and then appeared to hang.  So I added some debug printfs and discovered it was actually running behind the black screen, loading a bunch of ogg sound files at something shy of a snails pace.  If I waited long enough, just short of an eternity, it would actually bring up the splash screen and allow me to attempt a game.  Sorta, kinda.  Press a button, then wait a minute for the the floating point ogg code to process the associated squeek or beep sound.   Repeat.  Not much fun at all, really.

I checked the SDL_mixer readme file and sure enough there was an option for libtremor that I hadn't selected.  That might work better than the fake floating point support on the zipit.  So I did a rebuild on the library and now the game loads and plays at reasonable speed on the zipit.  As an added bonus, the new SDL_Mixer lib also fixed up playmus to work on ogg files.  I wonder what else I might have missed.  Say, doesn't supertux use ogg?  Perhaps I should take another look at that.

Meanwhile I've got a new SDL_mixer and last-mission package to put up here...

libSDL_mixer-iz2s-tremor.zip
last-mission-iz2s.zip

Update:

So, I fetched supertux and applied the 4 patches from the openwrt-zipit project before compiling.  The resulting executable took a while to load, but it ran and the music played ok.  However the controls were sluggish and the frame refresh rate was pretty darn awful.  Digging into the code revealed floating point math all over the place.  Oh well.  But wait, I don't give up that easy.  I ran some internet searches and found a fixed-point patch for a slightly older version of supertux that was done for the zaurus.  I also found some tantalizing hints that someone might have updated them to the newer code, but could't locate the goods.  The outdated patch was pretty large, but I gave it a shot and then attempted to manually merge the rejected parts.

As far as I can tell so far it seems to work.  The controls are smooth and the game is much more playable.

So now I just gotta pack it up and make an updated version of the patch...

supertux-iz2s.zip
supertux-0.1.3-fp.patch

Two Steps Back...

Seems like only yesterday I installed a brand new 500GB harddisk in my tired old laptop so I'd have plenty of room to work on the zipit stuff.  But apparently it was in there for almost exactly two years last week when it suddenly decided that was enough.  Looking back I suppose it wasn't all that sudden.  It started humming a few hours before it froze, but at the time I thought it was the CPU fan.  Oh well, live and learn.  Shoulda done more frequent backups.

The most recent backup of my iz2s development VM was over 6 months old, and the openwrt backup was even older.  Ouch.  So I dug up a much smaller, slower drive from my junk pile and put the latest LMDE linux on it to get back up and running before the long holiday weekend.  Turns out the 500GB drive wasn't completely dead yet.  I could run it for a few minutes as an external usb drive before it would seize up, just long enough to pull off the iz2s dev stuff.  Phew!  Openwrt was another story though.  I tried a few times, but never got more than half of it.  I gotta think about it before I try again so I don't brick the drive first.  Maybe I can use rsync to resume where the last attempt gave up?  Then I need to come up with a better backup strategy for the long term that plays well with my inherent laziness.  

Meanwhile I had to test the restored iz2s VM and make sure all was well.  I was already running out of holiday so I chose an easy target.  I saw the wetspot2 game mentioned in the recent releases section of the gcw zero forums and thought it might be fun on the zipit.  Since it was developed in C and SDL it looked like a good fit.  The game compiled ok right out of the box, but I eventually tweaked the makefile a teensy bit for the zipit.  Then I changed the 2 player keyboard settings to get a little more separation on the cramped iz2s keyboard, but that was it.

Single player mode uses the dpad arrows to move the crab and the control key (...) to push the blocks.  For two players the tab (Zipit) key is used to move the blocks for player 1.  Player  2 gets the S, Control, Z, and X keys to move the crab, and the space bar to push the blocks.  I actually tried this with one of the kids and it's not too bad.  The player with the arrow keys has a slight advantage though.  I know this because I had the other keys and lost.  It had to be the keys.

wetspot2-iz2s.zip

Oh yeah, I almost forgot.  While the laptop was out of commission I found some time to dig into the iz2s wifi config scripts.  Every so often they'd connect, but fail to get a dhcp lease.  Subsequent retries never seemed to work, and so I was always forced to reboot whenever it happened.  But this time it occurred during my laptop downtime, so I had no excuse not to investigate.  Nothing better to do...

It didn't actually take very long to see what was going on.  The dhcp request failed but the wpa_supplicant demon was left running, and that's what interfered with my retries.  So I patched the script to kill any running wpa_supplicant before starting a new one.  Now a retry usually succeeds.

With that fix in the bag I decided to tackle another nagging wifi issue.  I finally ported the iz2s Easy Wifi Configurator script to work on the jffs.  Sometimes I prefer the dialog driven EWoC script to connect because there's less typing, making it easier to use in a dimly lit location.   The main issue was working out a suitable substitute for awk to fetch the selected line out of the list of SSIDs in one of the dialogs.  A one, two punch of head followed by tail did the trick.  Shoulda thought of that a long time ago...

ewoc-iz2jffs.sh