[squeak-dev] Fork Proposal: Cuis & Killer Apps.

Lawson English 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) 
> instead.
[...]
>> To make the image smaller we should do two things (in parallel):
>> - craving (make packages unloadable, remove dependencies, split 
>> packages)
>> - 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 
lean.

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 
http://www.opencobalt.org/downloads).



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...


L.







More information about the Squeak-dev mailing list