OpenWIG development finally slowed down as I approached the more difficult problems - zone and distance detection.
However, they now seem to be finished and working nicely on my SE K610i.
I even implemented "slow hysteresis" to compensate for GPS fuzz: when you are about to walk into a zone (where "zone" is not Wherigo.Zone, but a well defined area, e.g. the proximity space around a Zone, the inside of a Zone, or maybe the space so far away that it's even outside the DistanceRange), OpenWIG waits for five consecutive position samples that confirm your position in the new zone, and only then acknowledges the new position.
It's too late for me to be able to explain it in simple terms, but it actually is simple. And it works surprisingly well, at walking speed at least. But it is five seconds slow. I'll see what I can do about that.
Version 0.2.4 includes precise zone detection, distance detection, OnProximity and OnDistant events (last two from the "basic set" that is used in every other cartridge)
...and... (drums, please) navigation!
Yes, ladies and gentlemen, OpenWIG will now tell you exactly how far away are you and what direction you should take. The instructions are still rather crude, and they are displayed even when you are inside the zone (you can just disregard them, they don't mean anything inside a zone. i use them for debugging), but it does work.
Get it while it's hot!
April 18, 2008
April 10, 2008
they are on to me!!
[panicks] Yaaaaaaahh!!! They're coming! ... must ... keep ... ahead .... !! [panicks again, runs around in circles]
In other news, OpenWIG 0.2.3 is out and it supports various kinds of Inputs, as well as few more dummy functions.
In other news, OpenWIG 0.2.3 is out and it supports various kinds of Inputs, as well as few more dummy functions.
April 8, 2008
OpenWIG news
OpenWIG 0.2.2 is out.
In addition to task support, it can now work with practically any cartridge code - although most cartridges will be unplayable anyway, because of missing functionality. See what is implemented and how to install your cartridge.
Since 0.2.1, it is possible to choose between manual input of coordinates and Bluetooth GPS device.
Misch's gwc decoder appears to be functionally complete, so it is just a matter of time when OpenWIG will be able to open and play cartridges compiled by official tools.
In addition to task support, it can now work with practically any cartridge code - although most cartridges will be unplayable anyway, because of missing functionality. See what is implemented and how to install your cartridge.
Since 0.2.1, it is possible to choose between manual input of coordinates and Bluetooth GPS device.
Misch's gwc decoder appears to be functionally complete, so it is just a matter of time when OpenWIG will be able to open and play cartridges compiled by official tools.
April 7, 2008
OpenWIG: GPS support ready, gwc format possible
Version 0.2.0 of OpenWIG has crude support for Bluetooth GPS modules. Plus a Play Anywhere mode, so you can play the included Zooventure Level Two regardless of where you live.
In other news: misch of geocaching.cz said that the gwc format doesn't look at all difficult to him. And that he would probably be able to decode it.
That means that OpenWIG will probably have support for original Wherigo Player cartridges, and that means that you will be able to play full-featured Wherigo on your mobile phone!
Isn't that just wonderful?
In other news: misch of geocaching.cz said that the gwc format doesn't look at all difficult to him. And that he would probably be able to decode it.
That means that OpenWIG will probably have support for original Wherigo Player cartridges, and that means that you will be able to play full-featured Wherigo on your mobile phone!
Isn't that just wonderful?
April 5, 2008
expert at making things more complicated
Oh Me Oh My.
For whatever reason, Wherigo is designed in a way that perfectly maps to J2ME's gui handling. Commands, actions, dialog boxes, it all looks like somebody designed it to work in a midlet.
Except for one thing.
To quote Wherigo Advanced Concepts on the subject of MessageBoxes and Dialogs:
On the other hand, it's quite a dumb idea to automatically cancel the dialogs when another comes. What if the user doesn't have time to read it? But ... who am I to judge :P
So let's restate the problem.
Strangely enough, it worked, and it worked really well.
Too well, actually.
I apparently missed some of the Advanced Concepts.
It actually does work like that. Dialog is put on screen and the script continues happily on its way. Return values? No sire. There are callbacks instead. Who could have thought?
(anyone who would try it in the builder ... oh well)
In fact, the very Wherigo Level Two cartridge I use for testing is relying on this "feature". Instead of if/elseif conditional blocks, it just displays messages over one another, stopping at the right time.
I was very surprised that OpenWIG showed more messages than the emulator. I even thought that it's a bug in the emulator, or some kind of unspecified if/elseif handling - which would be very, very bad.
Nope, none of that. Once again, I made the problem more difficult for me. If I didn't want to do it "properly", it would have been easier, and correct at the same time. Folks at GroundSpeak apparently don't do things the "proper" way, but the "practical" (easy for the programmer) way. I'll have to get used to it.
But auto canceling the dialogs? Come on. That is dumb. Really.
For whatever reason, Wherigo is designed in a way that perfectly maps to J2ME's gui handling. Commands, actions, dialog boxes, it all looks like somebody designed it to work in a midlet.
Except for one thing.
To quote Wherigo Advanced Concepts on the subject of MessageBoxes and Dialogs:
The Wherigo Player automatically cancels any message box that is buried by another user interface element. This means that the message box will not remain on the screen even after all other UI elements have been closed. However, the message box script (if one exists) will still execute. The author can override this by creating a condition to specify what should happen if the 'Cancel' button is pressed. These conditions will work regardless of whether the player intentionally presses 'Cancel' or the message box is automatically canceled by the application.Funny, I thought, this is going to be rather tough. You have to keep a return value from the message box, but anything can close it anytime. Hello and welcome aboard, race conditions. And what's even better, Lua VM is thread-unsafe. And it would be dumb to lock the whole VM for as long as the dialog is on, because that can be quite a long time.
On the other hand, it's quite a dumb idea to automatically cancel the dialogs when another comes. What if the user doesn't have time to read it? But ... who am I to judge :P
So let's restate the problem.
- Midlet UI works in non-blocking, fire-and-forget mode. Which is basically a good thing for an UI to do, but...
- ...we need to keep return values. Therefore we must block on the dialog.
- Anything can close the dialog anytime. I.e., another thread must tell the first one to continue.
- Lua VM is thread-unsafe, therefore the two must somehow arrange locking. Plus locking of the dialog threads, because a third dialog can come at any time and kill the two.
Strangely enough, it worked, and it worked really well.
Too well, actually.
I apparently missed some of the Advanced Concepts.
in Wherigo, a message box does not pause the cartridge. Instead, the game continues to run while the message box is still displayed on the screen.Just like midlets do. Fire-and-forget, anyone?
It actually does work like that. Dialog is put on screen and the script continues happily on its way. Return values? No sire. There are callbacks instead. Who could have thought?
(anyone who would try it in the builder ... oh well)
In fact, the very Wherigo Level Two cartridge I use for testing is relying on this "feature". Instead of if/elseif conditional blocks, it just displays messages over one another, stopping at the right time.
I was very surprised that OpenWIG showed more messages than the emulator. I even thought that it's a bug in the emulator, or some kind of unspecified if/elseif handling - which would be very, very bad.
Nope, none of that. Once again, I made the problem more difficult for me. If I didn't want to do it "properly", it would have been easier, and correct at the same time. Folks at GroundSpeak apparently don't do things the "proper" way, but the "practical" (easy for the programmer) way. I'll have to get used to it.
But auto canceling the dialogs? Come on. That is dumb. Really.
versioning in NetBeans
How to crash a J2ME emulator (and Nokia phones)
When working on OpenWIG, the mobile phone emulator would always crash (and i mean crash hard, that's segfault for you) before running anything useful. Weird, I thought, and reinstalled NetBeans, then switched to a different JDK, then different operating system, then different WTK (not really different, though; turns out that SonyEricsson's J2ME SDK contains basically unmodified WTK from Sun). Everything would crash. I had to upload the midlet to my phone (SE K610i) for each testing cycle. That worked without problems.
But "debugging" on the phone, without debugger at the ready, is a whole lot of fun. Mainly because on the phone, you don't have backtraces.
(Next time I might try OTA debugging, but right now I don't even know what exactly that is...)
The Lua VM must be triggering some bug in the emulator, I thought, too bad for me. And I released a testing version that worked perfectly on my phone.
Oddly enough, the Lua VM managed to trigger a bug in Nokia phones too. They would freeze or reset when attempting to run the midlet.
Solution? Let me quote a mail from Kristofer Karlsson, developer of Kahlua:
Fortunately, the solution is simple: instead of System.identityHashcode(a), use a.hashCode().
Apparently, the identityHashcode function was slightly broken in older JVM's (and the WTK too, apparently. oh, and in Nokia phones. but oh well, i never liked Nokia anyway) and it couldn't cope with too many internalized strings.
But "debugging" on the phone, without debugger at the ready, is a whole lot of fun. Mainly because on the phone, you don't have backtraces.
(Next time I might try OTA debugging, but right now I don't even know what exactly that is...)
The Lua VM must be triggering some bug in the emulator, I thought, too bad for me. And I released a testing version that worked perfectly on my phone.
Oddly enough, the Lua VM managed to trigger a bug in Nokia phones too. They would freeze or reset when attempting to run the midlet.
Solution? Let me quote a mail from Kristofer Karlsson, developer of Kahlua:
Someone previously mentioned that the function System.identityHashcodeIsn't that funny?
crashed for some strings such as "error"
Fortunately, the solution is simple: instead of System.identityHashcode(a), use a.hashCode().
Apparently, the identityHashcode function was slightly broken in older JVM's (and the WTK too, apparently. oh, and in Nokia phones. but oh well, i never liked Nokia anyway) and it couldn't cope with too many internalized strings.
Wherigo midlet ... or is it?
Once upon a time, there was Wherigo. It was closed-source, closed-format, and worked only on PocketPCs (and some kind of obscure navigation device). It did not work on cellphones and the developers apparently weren't interested in making it work.
Turns out, however, that the Wherigo Builder produces plain Lua source files. It can't be too hard to make that work on a mobile phone, now can it?
Well, let's hope not. Enter matejcik, who just recently bought a bluetooth GPS module to use with his phone. And whose idea of fun is, among other things, staying up late (or early, you might say) coding weird stuff.
Working name of the project is OpenWIG. As of now, it can run nearly all of Zooventure Level Two from the tutorial.
No GPS connectivity yet, but you can input coordinates by hand. I might keep this feature, as it would enable folks without GPS-enabled mobiles to play. Then again, I might not - you know how things go, cheaters are everywhere and this would only make it easier for them.
You can't load your own cartridges yet, and you will probably never be able to load gwc files, as the format is closed and I have no experience in reverse engineering. But once the loading functionality is there, I will probably set up a web service that would take your sources and compile them to OpenWIG-friendly format.
Heart of the midlet is called Kahlua and it is a Lua virtual machine for J2ME. It eats Lua 5.1 bytecode compiled files and works pretty damn well, considering its size. It is also fast enough on all phones I tested.
(Then again, it's not like the Lua scripts in the cartridges do a whole lot of work. Setting variables, conditional branch here and there, that's about it.)
And as an added value, the guy who wrote it was very helpful and the (two) bugs I reported were fixed immediately.
No download link today, but you can find some testing versions in this thread (in Czech).
Update: check out OpenWIG's Google Code page.
Turns out, however, that the Wherigo Builder produces plain Lua source files. It can't be too hard to make that work on a mobile phone, now can it?
Well, let's hope not. Enter matejcik, who just recently bought a bluetooth GPS module to use with his phone. And whose idea of fun is, among other things, staying up late (or early, you might say) coding weird stuff.
Working name of the project is OpenWIG. As of now, it can run nearly all of Zooventure Level Two from the tutorial.
No GPS connectivity yet, but you can input coordinates by hand. I might keep this feature, as it would enable folks without GPS-enabled mobiles to play. Then again, I might not - you know how things go, cheaters are everywhere and this would only make it easier for them.
You can't load your own cartridges yet, and you will probably never be able to load gwc files, as the format is closed and I have no experience in reverse engineering. But once the loading functionality is there, I will probably set up a web service that would take your sources and compile them to OpenWIG-friendly format.
Heart of the midlet is called Kahlua and it is a Lua virtual machine for J2ME. It eats Lua 5.1 bytecode compiled files and works pretty damn well, considering its size. It is also fast enough on all phones I tested.
(Then again, it's not like the Lua scripts in the cartridges do a whole lot of work. Setting variables, conditional branch here and there, that's about it.)
And as an added value, the guy who wrote it was very helpful and the (two) bugs I reported were fixed immediately.
No download link today, but you can find some testing versions in this thread (in Czech).
Update: check out OpenWIG's Google Code page.
Subscribe to:
Posts (Atom)