If you have a slower computer (although i'm extremely reluctant to call my P4@2.8GHz "slower", it's a fact that my work computer with a Core2 just feels that much snappier) and want to play DOS games in dosbox, you might experience this:
The overall game performance is good, your CPU is not even fully taxed, sounds generally work as expected - all nice and fun, except for the MIDI music. Which crackles and skips and stutters and is generally unpleasant enough that you want to turn it off.
Fear not, for i have found a cure!
Open your dosbox.conf (you don't have one? head over to google and find yourself a nice set of instructions on how to create it and where to place it), locate the [mixer] section and increase the prebuffer value. I set mine to 50 (default seems to be 10) and the music is smooth like a cleanly polished watermelon. Or something.
December 14, 2009
August 2, 2009
openwig news
Version 0.3.92 is underway.
Biggest spectacle of this is cartridge saving and loading. A few moments ago i have successfully stored and restored a game of Wherigo Player Tutorial.
Technical details about the solution will follow in a separate article.
And that's pretty much it. There's the usual bunch of random bugfixes, minor improvements and extended Wherigo functionality (did i tell you that you can now see a zone map?), but probably nothing to write home about.
Oh, and i switched back from NetBeans' default proguard 4.2 (obfuscator/optimizer) to older 3.9. The new one is too aggressive in optimizing and still has some bugs. I identified and reported one, but it's not yet fixed, so i can't really continue the search. And i don't need the stress of hunting bugs that aren't there.
Biggest spectacle of this is cartridge saving and loading. A few moments ago i have successfully stored and restored a game of Wherigo Player Tutorial.
Technical details about the solution will follow in a separate article.
And that's pretty much it. There's the usual bunch of random bugfixes, minor improvements and extended Wherigo functionality (did i tell you that you can now see a zone map?), but probably nothing to write home about.
Oh, and i switched back from NetBeans' default proguard 4.2 (obfuscator/optimizer) to older 3.9. The new one is too aggressive in optimizing and still has some bugs. I identified and reported one, but it's not yet fixed, so i can't really continue the search. And i don't need the stress of hunting bugs that aren't there.
tidbits
S40 Nokias do weird things when you put a StringItem on a form, give it a label but no text. It will prevent users from scrolling that form.
S60 Nokias do some weird stuff too, but only sometimes. Best not to do this.
SonyEricssons, on the other hand, retain image size on ImageItem when you setImage(null). You have to set a dummy 1x1 image first (or instead).
And last but not least, with certain bluetooth devices (GPSr's, in this case), Nokia phone would perform a bluetooth service search, but return error instead of the service.
When you're searching for a serial port service (UUID 0x1101) and get an error instead, just take "btspp://" + RemoteDevice.getBluetoothAddress() + ":1" as a connection url and you have a solid chance of connecting successfully.
(That means BT address + channel 1. On single-purpose devices, you'll most likely find the only service on channel 1. Makes sense, eh?)
S60 Nokias do some weird stuff too, but only sometimes. Best not to do this.
SonyEricssons, on the other hand, retain image size on ImageItem when you setImage(null). You have to set a dummy 1x1 image first (or instead).
And last but not least, with certain bluetooth devices (GPSr's, in this case), Nokia phone would perform a bluetooth service search, but return error instead of the service.
When you're searching for a serial port service (UUID 0x1101) and get an error instead, just take "btspp://" + RemoteDevice.getBluetoothAddress() + ":1" as a connection url and you have a solid chance of connecting successfully.
(That means BT address + channel 1. On single-purpose devices, you'll most likely find the only service on channel 1. Makes sense, eh?)
June 12, 2009
thoughts on Nokia class loading mechanism
situation:
Imagine you have your basic midlet class (say gui.Midlet). This class references another class (gps.InternalProvider) which implements a specific interface (gps.LocationService). Note that there is no reference to the actual class gps.InternalProvider, except for instantiation, and that is pretty well hidden in a function under several ifs and switches. Everything else is done through the interface.
Class gps.InternalProvider references classes from an api (JSR-179) that might or might not be present on your target device (S40 Nokia). It uses them rather extensively, but of course, it can't use them until it's instantiated. (no static codeblocks, nothing like that)
issue:
When such midlet is started on such device, it instantly dies with NoClassDefFoundError on the JSR-179 classes. It doesn't even start, I'm pretty convinced that none of my code is executed.
Definitely not the part that would instantiate the offending classes.
solution:
Create a distraction. Add a class (let's call it gps.InternalProviderRedirector) that has only one static method:
thoughts:
This is easy to grasp intuitively (for me, at least), but in some situations, that is not enough. So i studied the JVM specification, especially the parts about class loading and linking, and tried to come up with a scientific explanation to this phenomenon. Here's my best effort - note that it is only an educated guess and might not relate to reality in any way.
The spec says that when you are loading a class, you get symbolic references to all classes in use. Then, in the linking step, you can (but don't have to) resolve those symbolic references by trying to load the referenced classes.
I say that Nokia does this. That means that when linking the Midlet class, the class file for InternalProvider (or InternalProviderRedirector) is already loaded.
Then, either in the initialization phase or when the first code from a class is run, Nokia JVM attempts to link all the referenced classes. That means that those classes now try to load and resolve their symbolic references.
When you start the midlet, the class Midlet is loaded. Then it's linked, triggering loading of InternalProvider. And then it's instantiated, triggering linking of InternalProvider. That triggers loading of JSR-179 classes, which are not present, so the instantiation itself fails.
When you insert InternalProviderRedirector into the chain, InternalProvider is never linked (only loaded), so JSR-179 is never loaded. And all is well.
Imagine you have your basic midlet class (say gui.Midlet). This class references another class (gps.InternalProvider) which implements a specific interface (gps.LocationService). Note that there is no reference to the actual class gps.InternalProvider, except for instantiation, and that is pretty well hidden in a function under several ifs and switches. Everything else is done through the interface.
Class gps.InternalProvider references classes from an api (JSR-179) that might or might not be present on your target device (S40 Nokia). It uses them rather extensively, but of course, it can't use them until it's instantiated. (no static codeblocks, nothing like that)
issue:
When such midlet is started on such device, it instantly dies with NoClassDefFoundError on the JSR-179 classes. It doesn't even start, I'm pretty convinced that none of my code is executed.
Definitely not the part that would instantiate the offending classes.
solution:
Create a distraction. Add a class (let's call it gps.InternalProviderRedirector) that has only one static method:
public static LocationService instantiate() {
return new InternalProvider();
}Then instead of doing this directly in the Midlet class, call InternalProviderRedirector.instantiate(). Magically, it will work.thoughts:
This is easy to grasp intuitively (for me, at least), but in some situations, that is not enough. So i studied the JVM specification, especially the parts about class loading and linking, and tried to come up with a scientific explanation to this phenomenon. Here's my best effort - note that it is only an educated guess and might not relate to reality in any way.
The spec says that when you are loading a class, you get symbolic references to all classes in use. Then, in the linking step, you can (but don't have to) resolve those symbolic references by trying to load the referenced classes.
I say that Nokia does this. That means that when linking the Midlet class, the class file for InternalProvider (or InternalProviderRedirector) is already loaded.
Then, either in the initialization phase or when the first code from a class is run, Nokia JVM attempts to link all the referenced classes. That means that those classes now try to load and resolve their symbolic references.
When you start the midlet, the class Midlet is loaded. Then it's linked, triggering loading of InternalProvider. And then it's instantiated, triggering linking of InternalProvider. That triggers loading of JSR-179 classes, which are not present, so the instantiation itself fails.
When you insert InternalProviderRedirector into the chain, InternalProvider is never linked (only loaded), so JSR-179 is never loaded. And all is well.
May 19, 2009
openwig news
Well well well. It sure has been a long time.
Today i have released a new and improved experimental version 0.3.90 (yup, that means pre-0.4), codenamed "Threadless". Why? Well, it's not because it makes t-shirts. It's because it doesn't use threads. Not too much of them, anyway.
Before this release, OpenWIG relied on threads for event synchronization. Whenever I needed to call an event handler, I spawned a thread that would perform the Lua code and die. Which is all good and nice, but can bring a lot of trouble. For one, when you use many threads, you need to care about (dead)locking. For two, some j2me implementations are somewhat inferior to the rest *cough*Symbian*cough*. Their garbage collection is simply not good enough. So it's better not to create too many objects, if you know what i mean.
Also, for the same reason, there is now a pre-allocated instance of each of the screen types (like "item details", "zone navigation", "dialog" etc.) and no new screens are created.
Oh, and screen switching is now stateless. That means that each screen knows in advance which screens can follow it. And that's cool! Lots of problems with screen refreshing disappeared this way.
And lot of them appeared. Oh well, for every bug you fix, three new are born.
In other news, we now have the latest and greatest Kahlua revision, which means that we support more obscure code. Inventories and AllZObjects are now accessible from Lua as tables. And some minor thingies, i don't remember exactly.
Anyway, the new version is very cool and you should all download it.
Today i have released a new and improved experimental version 0.3.90 (yup, that means pre-0.4), codenamed "Threadless". Why? Well, it's not because it makes t-shirts. It's because it doesn't use threads. Not too much of them, anyway.
Before this release, OpenWIG relied on threads for event synchronization. Whenever I needed to call an event handler, I spawned a thread that would perform the Lua code and die. Which is all good and nice, but can bring a lot of trouble. For one, when you use many threads, you need to care about (dead)locking. For two, some j2me implementations are somewhat inferior to the rest *cough*Symbian*cough*. Their garbage collection is simply not good enough. So it's better not to create too many objects, if you know what i mean.
Also, for the same reason, there is now a pre-allocated instance of each of the screen types (like "item details", "zone navigation", "dialog" etc.) and no new screens are created.
Oh, and screen switching is now stateless. That means that each screen knows in advance which screens can follow it. And that's cool! Lots of problems with screen refreshing disappeared this way.
And lot of them appeared. Oh well, for every bug you fix, three new are born.
In other news, we now have the latest and greatest Kahlua revision, which means that we support more obscure code. Inventories and AllZObjects are now accessible from Lua as tables. And some minor thingies, i don't remember exactly.
Anyway, the new version is very cool and you should all download it.
Subscribe to:
Posts (Atom)