[squeak-dev] Fork Proposal: Cuis & Killer Apps.
lenglish5 at cox.net
Thu Sep 8 19:29:45 UTC 2011
On 9/7/11 5:56 PM, Juan Vuletich wrote:
> Levente Uzonyi wrote: We should pick good stuff from Cuis (and Pharo)
>> To make the image smaller we should do two things (in parallel):
>> - craving (make packages unloadable, remove dependencies, split
>> - building (use Spoon to rebuild the current image)
> Growing back the image with Spoon is much easier if you already start
> with a clean image, like Cuis. Same for loading packages back: half of
> the work is already done.
For those who haven't tried it, Juan's Cuis 3.3 image is only 6.5 MB. It
would be interesting to see if Craig can use Spoon to make it even more
At the other extreme, when Craig brags that he's gotten a minimalist
Squeak image to run with only 1337 bytes, he's not joking. I loaded it
into a programming text editor (BBEdit) and sure enough, it is exactly
1337 bytes. Very LEET indeed. :-)
As far as what makes a "killer app" goes, the answer is obvious.
Squeak/Pharo/Cuis/Spoon/Seaside are programming *tools*. This community
doesn't have the resources to make a new killer app out of the existing
tools (if they did, they'd be multi-millionaires already), BUT, Squeak
running on Cog/MTCog is sufficiently fast to compete with other
programming environments in order to create THE killer app: tools to
create games for others to use to create games.
Squeak could easily become the next Flash environment if the APIs
existed to manipulate sprites and 3D objects properly. We already have
Teatime, which distributes processing in ways that no other platform can
even dream of (or even understand without some hours of explanation).
Matt Fulmer has managed to get Open Cobalt running in a 4.2 image and
play nice with the Morphic GUI (at the cost of some speed, you can
overlap windows on top of the OpenGL layer seamlessly
I've been looking at a simple, but fun, 2D game called NAEV. It uses C
for the skeleton framework and calls external libraries (most of which
Squeak also calls, or has bypassed to some extent) for speed, and uses
Lua scripting to bind the game logic together. It uses SDL for its
graphics needs -there was a Squeak project to interface with SDL 1.2,
but that apparently died when the main programmer did, but I don't think
we need SDL interfacing, because we have direct access to the entire
OpenGL 1.4 API. Naev is the work of 7 programmers and my impression is
that those same programmers using Squeak + OpenGL would have finished
their project many months ago, instead of being only halfway through it.
What we lack is a wrapper around the various libraries that Squeak
already calls that would be attractive to game makers, both 2D and 3D.
Combine that with squeak's ease of programming, Teatime, and a way of
minimizing the footprint of the image using Cuis & Spoon, and you have
something that could attract literally thousands of wannabe game writers
to the platform.
We have OpenCobalt and OpenQWAK. We need a similar 2D library for
sprite-based games as well.
Just a thought...
More information about the Squeak-dev