Methods beginning with an underscore ($_) will have the underscore removed when moving the image to the mobile device. It allows me to have one version for Mobile Smalltalk and a different version for VisualWorks. You can imagine that it would be bad if I re-defined at:put: in VisualWorks. I have an ImageBuilder utility that takes all of the code in the packages "SimTalk Remote Core" (base Smalltalk code) and "SimTalk HexSolve" (the game itself), packages them into a special 64-bit image format and writes the image into a file. I can then use AndroidStudio or XCode to include this image as an asset to deliver to the device along with the interpreter. The interpreter itself is a 64 bit image. It uses immediate objects (tagged objects that fit within the object pointer) for SmallInteger, Character and Float. This allows me to do faster operations on these objects without allocating memory. The game uses Smalltalk primitives to interface to OpenGL ES which runs on both Android and iOS. For text, I interface to Freetype which is compiled and delivered with the game. Freetype will create images for the characters which I can collect and cache in a Smalltalk Image object. I then render these images as OpenGL textures. My mobile Smalltalk is single-threaded - there's no such thing as fork, a Process or a ProcessManager. In fact, Smalltalk runs completely as an OS callback. When the OS determines that something happened (a touch event, a button or a timeout), it runs a callback in my VM. The VM creates an Event object, drops it into a known spot in the image and runs the interpreter. The interpreter then reads the event, dispatches it, re-renders the screen if necessary then calls suspend which returns from the OS callback. Nothing more happens until the next OS callback. Some people have asked me when I'll release this technology so they can use it. I'm sorry to say, but I don't intend to do that. This is for internal use for me to write Smalltalk code for Android and iOS. I have several problems if I try to commercialize the development technology:
- You can't develop code in this environment without a VisualWorks license. I have such a license with Cincom but it's hard to tell other developers that they need a license for VisualWorks plus a license for my mobile development environment and it's hard to enforce.
- I've implemented interfaces to API's I need in the OS but not to everything. Other developers would need probably access to accelerometers, GPS, Internet, cameras and other things. I can't have a good commercial product without those interfaces and it's too much work to write these interfaces on speculation.
- Too many companies have died trying to provide tools for developers to enhance Smalltalk environments. The market isn't big enough to justify the effort.
- To be honest, software developers make lousy customers. They tend to be very demanding on everything they need and usually don't like paying money for what they get. They're used to software development environments being free and open source and don't want to pay for development and maintenance of their toolset.
- I'd rather create fun profitable games than creating development environments for other people to use to create fun profitable games.