Version 0.3.07, that's what. It will have all bugs from the previous post fixed, and its navigation arrow will be prettier and move smoother and just be plain old sexy.
Oh, and internal GPS's will be supported!
It will be ready sometime this week.
For the version after that, I intend to try and dig a bit into saving and loading. It won't be perfect, but maybe, just maybe, it will work well enough for most cartridges.
sidenote: there is a midlet called "OpenWIG-blackmagic" sitting silently in my phone. it has all kinds of very evil features that should never have been born. muhahahaa!
sidenote2: The name "OpenWIG" sucks. I need to come up with a different one.
November 24, 2008
fun bits
a.k.a. OpenWIG bugs worth mentioning, and their respective cartridges
Srnčí důl:
the official Players call "OnSet*" before performing the setting. I.e., when you set task.Complete = true, then the player first calls OnSetComplete and only after that actually sets the variable.
The OnSetComplete event in Srnčí důl (Roedeer deep), for some wicked reason, checks for this behavior: if task.Complete == false then (do stuff) So if at the moment of calling OnSetComplete, it's already Complete, there be failurez.
Blair Witch:
so I took the latest and greatest version and headed out, to try and play this cartridge, which is probably best one in CZ, and also the most complex one. So it was kind of baptism of fire for OpenWIG. Plus, this time, i was a member of a group equipped with Colorados, so i could check the behavior against the "right" one.
Found two bugs. In one, i could see all my virtual companions long after we left them behind in a dead zone. The other, at first i didn't think that it's a bug. I just completed a simple task ... then all the coloradists spent half hour trying to complete the very same task and failing spectacularly.
Both bugs were rather easy to find and remove.
First one: when a zone deactivates, it stops evaluating position events. That means that if you deactivate a zone in which you stand, as far as OpenWIG is concerned, you'll stand there till the end of days. Because it will never again check if you are inside or not. It just remembers the last state.
Fixed by forcefully removing a player from a deactivated zone.
Second: in the mentioned task, you have to carry an object outside of an invisible zone that envelopes the visible zone in which you start.
The respective event asks if invisibleZone:Contains(Player). Welll..... Yes, if the zones overlap, the player can be in more than one zone at once. That works fine. But when doing that, I apparently overlooked something: it doesn't go the other way around. Player is in multiple zones, but only one zone Contains() the player. So when i was in the inner visible zone, the event never found out that i was also in the invisible zone, and let me throw the task object away without hassle.
Fix was fairly trivial, i just needed to override zone's Contains method... ah, why would i write all this, you can figure it out.
...and for a time, it was good...
Petřínská Wherigovka:
This cartridge also has that habit of deactivating zones that you stand in. But it turns out that when fixing the problem from Blair Witch, i overlooked something again.
There are two internal states for a zone: contain says whether you are present in (close to, distant from) the zone, and ncontain aka "next contain" says whether you are going to be present in the zone in the next five seconds, unless something happens. So most of the time it's the same as contain.
When "forcefully removing" the player, i reset the value of contain, but not ncontain. In the next timestep, zone realized that the player is going to be inside it real soon, and invoked the OnEnter event.
Which had a rather lengthy dialog. Which ended in a question. Which, if answered correctly, would deactivate the zone. Which would lead to another OnEnter... you see where this is heading.
Also i found out that even when the zone is inactive, quite a lot is going on in it.
So i put a stop to it, and that's the end of this nasty little bug.
...or is it?
Srnčí důl:
the official Players call "OnSet*" before performing the setting. I.e., when you set task.Complete = true, then the player first calls OnSetComplete and only after that actually sets the variable.
The OnSetComplete event in Srnčí důl (Roedeer deep), for some wicked reason, checks for this behavior: if task.Complete == false then (do stuff) So if at the moment of calling OnSetComplete, it's already Complete, there be failurez.
Blair Witch:
so I took the latest and greatest version and headed out, to try and play this cartridge, which is probably best one in CZ, and also the most complex one. So it was kind of baptism of fire for OpenWIG. Plus, this time, i was a member of a group equipped with Colorados, so i could check the behavior against the "right" one.
Found two bugs. In one, i could see all my virtual companions long after we left them behind in a dead zone. The other, at first i didn't think that it's a bug. I just completed a simple task ... then all the coloradists spent half hour trying to complete the very same task and failing spectacularly.
Both bugs were rather easy to find and remove.
First one: when a zone deactivates, it stops evaluating position events. That means that if you deactivate a zone in which you stand, as far as OpenWIG is concerned, you'll stand there till the end of days. Because it will never again check if you are inside or not. It just remembers the last state.
Fixed by forcefully removing a player from a deactivated zone.
Second: in the mentioned task, you have to carry an object outside of an invisible zone that envelopes the visible zone in which you start.
The respective event asks if invisibleZone:Contains(Player). Welll..... Yes, if the zones overlap, the player can be in more than one zone at once. That works fine. But when doing that, I apparently overlooked something: it doesn't go the other way around. Player is in multiple zones, but only one zone Contains() the player. So when i was in the inner visible zone, the event never found out that i was also in the invisible zone, and let me throw the task object away without hassle.
Fix was fairly trivial, i just needed to override zone's Contains method... ah, why would i write all this, you can figure it out.
...and for a time, it was good...
Petřínská Wherigovka:
This cartridge also has that habit of deactivating zones that you stand in. But it turns out that when fixing the problem from Blair Witch, i overlooked something again.
There are two internal states for a zone: contain says whether you are present in (close to, distant from) the zone, and ncontain aka "next contain" says whether you are going to be present in the zone in the next five seconds, unless something happens. So most of the time it's the same as contain.
When "forcefully removing" the player, i reset the value of contain, but not ncontain. In the next timestep, zone realized that the player is going to be inside it real soon, and invoked the OnEnter event.
Which had a rather lengthy dialog. Which ended in a question. Which, if answered correctly, would deactivate the zone. Which would lead to another OnEnter... you see where this is heading.
Also i found out that even when the zone is inactive, quite a lot is going on in it.
So i put a stop to it, and that's the end of this nasty little bug.
...or is it?
November 3, 2008
OpenWIG 0.3 beta
Released this night. Head over to the openWIG project page and get it (link is on the right side).
It has its own functional file browser, and a pretty preferences screen. It mostly looks the way i described it a while ago.
No big changes on the player side of things, though, only some minor bugfixes.
Caveats:
It has its own functional file browser, and a pretty preferences screen. It mostly looks the way i described it a while ago.
No big changes on the player side of things, though, only some minor bugfixes.
Caveats:
- It's a beta and i didn't really test it (mostly because of the emulator stuff mentioned in last post). It just might be that it is severely broken in some stupid way and unfit for general use.
- It can no longer load files from JAR archive. That functionality might be restored, but as of now, i don't see any reason to do that.
testing FileConnection with the J2ME emulator
...is difficult at best, and impossible most of the time.
UPDATE: ...CAN be very easy, IF you "specify the security domain" in NetBeans (and choose Manufacturer, for best results). All the problems mentioned below disappear, because the emulator stops asking questions. But if you want to test behavior on regular phone with no rights, you'll have to test on an actual phone - read on.
one: unlike most (if not all) phones, the emulator runs confirmation windows in the same thread as commandActions.
That means that if you try to do anything file-related from a commandAction, a security confirmation pops up and you can't dismiss it, because your command thread is (dead)locked waiting for the result of this confirmation.
Oh well, I made my file browser run the file commands in a background thread.
two: unlike all phones, the emulator wants a security confirmation for each and every method call on the FileConnection object. And it does not remember permissions. Therefore, listing a directory takes three confirmation clicks, and every time you want to re-read a file, another confirmation (which is likely to deadlock you, for reason one).
three: the emulator (at least version 2.5.2 in linux) creates a brand new tree structure for each run. And it appears that you can't choose what will appear in that structure. So if you want to test opening a specific file, you have to copy it into the proper location every time.
(although i remember that it behaved slightly differently on my notebook. i'll have to check that out too)
and all's good when the end's good, four: do not ever in your life try to "mount" parts of your filesystem into the emulator by linking them to the temporary filesystem root.
Upon exiting, the emulator happily descended into my directory and recursively deleted it. Fortunately, there wasn't anything irreplaceable, or i haven't noticed yet; but i lost a good hour of work.
Good to know, though, is that there is now a way to undelete files from an ext3 filesystem. Didn't help me, though; the software insisted on segfaulting. It's apparently a known problem with "large partitions on some 32bit systems".
UPDATE: ...CAN be very easy, IF you "specify the security domain" in NetBeans (and choose Manufacturer, for best results). All the problems mentioned below disappear, because the emulator stops asking questions. But if you want to test behavior on regular phone with no rights, you'll have to test on an actual phone - read on.
one: unlike most (if not all) phones, the emulator runs confirmation windows in the same thread as commandActions.
That means that if you try to do anything file-related from a commandAction, a security confirmation pops up and you can't dismiss it, because your command thread is (dead)locked waiting for the result of this confirmation.
Oh well, I made my file browser run the file commands in a background thread.
two: unlike all phones, the emulator wants a security confirmation for each and every method call on the FileConnection object. And it does not remember permissions. Therefore, listing a directory takes three confirmation clicks, and every time you want to re-read a file, another confirmation (which is likely to deadlock you, for reason one).
three: the emulator (at least version 2.5.2 in linux) creates a brand new tree structure for each run. And it appears that you can't choose what will appear in that structure. So if you want to test opening a specific file, you have to copy it into the proper location every time.
(although i remember that it behaved slightly differently on my notebook. i'll have to check that out too)
and all's good when the end's good, four: do not ever in your life try to "mount" parts of your filesystem into the emulator by linking them to the temporary filesystem root.
Upon exiting, the emulator happily descended into my directory and recursively deleted it. Fortunately, there wasn't anything irreplaceable, or i haven't noticed yet; but i lost a good hour of work.
Good to know, though, is that there is now a way to undelete files from an ext3 filesystem. Didn't help me, though; the software insisted on segfaulting. It's apparently a known problem with "large partitions on some 32bit systems".
October 6, 2008
today's most interesting bug
Which, as stated before, didn't look like one.
True, the midlet would die on me when the GPS was forcefully disconnected ... but isn't that what midlets do? You take away their bluetooth connection, they die, right?
Wrong, apparently. And it wouldn't make sense, too - why should an application die just because of lost bluetooth connection?
For some reason, i started thinking about it yesterday, spent a good hour googling for the explanation and found none, so i finally gathered my courage and posted a question on SonyEricsson developer forums.
First answer solved my problem.
Two lessons to be learned here, apart from the "if google doesn't know that a problem exists, there's something wrong with the problem"...
First, Exception isn't the root of all that can go wrong. Throwable is. Replacing my Exception handling code to handle all Throwables revealed that there actually is a Throwable being thrown, and it's an OutOfMemory one.
Which also explained why the application died - when an OutOfMemory condition happens, dying is the sane thing to do. (Really. Trust me on this one.)
And second... well, not really that much of a lesson, except maybe "don't trust (foreign) code, even if you read it and thought that it's fine". That OutOfMemory was caused by a loop that continuously read from the bluetooth link and saved results into a ByteArrayOutputStream (which was rather stupid thing to do in itself, but oh well), until it found a newline.
Except that when the link died, stream did not vanish (that was handled, but honestly, what would you think if a stream just vanished from under your program? i wouldn't write something like that, but when i was reading it, it looked like proper error handling) and instead started reporting "end of stream". Which it did by returning -1.
The loop happily filled the byte array with -1's and happily ran out of memory in the middle of doing that.
Simple bug, simple fix.
Once you realize that it is a bug and not a status quo.
True, the midlet would die on me when the GPS was forcefully disconnected ... but isn't that what midlets do? You take away their bluetooth connection, they die, right?
Wrong, apparently. And it wouldn't make sense, too - why should an application die just because of lost bluetooth connection?
For some reason, i started thinking about it yesterday, spent a good hour googling for the explanation and found none, so i finally gathered my courage and posted a question on SonyEricsson developer forums.
First answer solved my problem.
Two lessons to be learned here, apart from the "if google doesn't know that a problem exists, there's something wrong with the problem"...
First, Exception isn't the root of all that can go wrong. Throwable is. Replacing my Exception handling code to handle all Throwables revealed that there actually is a Throwable being thrown, and it's an OutOfMemory one.
Which also explained why the application died - when an OutOfMemory condition happens, dying is the sane thing to do. (Really. Trust me on this one.)
And second... well, not really that much of a lesson, except maybe "don't trust (foreign) code, even if you read it and thought that it's fine". That OutOfMemory was caused by a loop that continuously read from the bluetooth link and saved results into a ByteArrayOutputStream (which was rather stupid thing to do in itself, but oh well), until it found a newline.
Except that when the link died, stream did not vanish (that was handled, but honestly, what would you think if a stream just vanished from under your program? i wouldn't write something like that, but when i was reading it, it looked like proper error handling) and instead started reporting "end of stream". Which it did by returning -1.
The loop happily filled the byte array with -1's and happily ran out of memory in the middle of doing that.
Simple bug, simple fix.
Once you realize that it is a bug and not a status quo.
bitrot
Last time i did something with openWIG, it was a rather nifty little midlet that did some cool stuff.
When i fired it up today, it didn't do anything. Plus it seemed that it only has parts of my most recent work. Or something.
Apparently, it has gone bitrotten from not being touched in few months. I'll have to dust it off, clean it up, look for the missing parts on my laptop and push out a version.
In other news, i've fixed the bug where the midlet would die instantly if you disconnect the GPS. Funny thing, i never thought that it's a bug in the application, i thought that it's just the way things are. Oh well.
When i fired it up today, it didn't do anything. Plus it seemed that it only has parts of my most recent work. Or something.
Apparently, it has gone bitrotten from not being touched in few months. I'll have to dust it off, clean it up, look for the missing parts on my laptop and push out a version.
In other news, i've fixed the bug where the midlet would die instantly if you disconnect the GPS. Funny thing, i never thought that it's a bug in the application, i thought that it's just the way things are. Oh well.
July 24, 2008
anti-iPhone-DRM campaign
I'm a DefectiveByDesign subscriber, because I have a strong distaste for DRM.
Recently, DefectiveByDesign launched a campaign against iPhone, and generally, they fight against iPod and Apple products, because of the DRM employed in them.
Well.
You know what's sad?
Apple products rock. Seriously, they do. Did you ever hold an iPhone? Touched it? Typed on its wonderful multitouch-aware onscreen keyboard? That thing is damn sexy. And it Just Works (tm). And it's precise. There is no other device with the same degree of input precision on a touchscreen (yes, that is because of the multitouch capability, i.e. completely different principle of touch recognition), few devices with built-in gyrostat to detect device tilt, and none of them use it as well as iPhone does.
I mean, yes, there are "alternatives". They might be more powerful, more open, more compatible, better engineered or whatever.
And none of them holds a candle to iPhone's amazing usability and user experience. Plus, none of them can help you pick up chicks. iPhone can. Because iPhone is sexy.
I have a Cowon D2 player and i wouldn't trade it for an iPod. It has longer battery life, plays basically any format you throw at it, has a true DSP, works as mass storage, its firmware is updated regularly, blah, blah. Oh, and a touchscreen, of course. Yes, it outfeatures iPod in almost everything you can think of. But it's nowhere near as sexy.
And tell you what, average joe user does not give a rat's ass about features of D2. He has his Windows (or Mac) box with songs in mp3 format, and all he wants from a player is to actually play those songs. iPod does, and it does it sexy. Massively sexy.
I could go on for hours and hours about how Apple inovates while looking good. We all know it's true, even though some of us deny it. (Perhaps they are not Apple's original ideas, but it's Apple who shows them to the unwashed mass.)
The folks at DBD can bitch all they want, and they are right. The iPod and iPhone are bad, because they are all locked down and DRMed and stuff.
What is sad is that no other manufacturer takes on the challenge! Show me a single phone as cool as the iPhone. Show me a single player as cool as the iPod. Tell you what, there is none. iRiver Clix2 gets close, but not close enough.
DBD wants to pressure Apple into unlocking - "if you don't unlock, we'll go to the competition".
But the fact is that we won't, because iPhone is so damn cool.
Why, oh why, doesn't somebody pressure the competition into outsexying Apple?
Recently, DefectiveByDesign launched a campaign against iPhone, and generally, they fight against iPod and Apple products, because of the DRM employed in them.
Well.
You know what's sad?
Apple products rock. Seriously, they do. Did you ever hold an iPhone? Touched it? Typed on its wonderful multitouch-aware onscreen keyboard? That thing is damn sexy. And it Just Works (tm). And it's precise. There is no other device with the same degree of input precision on a touchscreen (yes, that is because of the multitouch capability, i.e. completely different principle of touch recognition), few devices with built-in gyrostat to detect device tilt, and none of them use it as well as iPhone does.
I mean, yes, there are "alternatives". They might be more powerful, more open, more compatible, better engineered or whatever.
And none of them holds a candle to iPhone's amazing usability and user experience. Plus, none of them can help you pick up chicks. iPhone can. Because iPhone is sexy.
I have a Cowon D2 player and i wouldn't trade it for an iPod. It has longer battery life, plays basically any format you throw at it, has a true DSP, works as mass storage, its firmware is updated regularly, blah, blah. Oh, and a touchscreen, of course. Yes, it outfeatures iPod in almost everything you can think of. But it's nowhere near as sexy.
And tell you what, average joe user does not give a rat's ass about features of D2. He has his Windows (or Mac) box with songs in mp3 format, and all he wants from a player is to actually play those songs. iPod does, and it does it sexy. Massively sexy.
I could go on for hours and hours about how Apple inovates while looking good. We all know it's true, even though some of us deny it. (Perhaps they are not Apple's original ideas, but it's Apple who shows them to the unwashed mass.)
The folks at DBD can bitch all they want, and they are right. The iPod and iPhone are bad, because they are all locked down and DRMed and stuff.
What is sad is that no other manufacturer takes on the challenge! Show me a single phone as cool as the iPhone. Show me a single player as cool as the iPod. Tell you what, there is none. iRiver Clix2 gets close, but not close enough.
DBD wants to pressure Apple into unlocking - "if you don't unlock, we'll go to the competition".
But the fact is that we won't, because iPhone is so damn cool.
Why, oh why, doesn't somebody pressure the competition into outsexying Apple?
Subscribe to:
Posts (Atom)