Games with Squeak

Hi Lord,

There is more contents on Games with Smalltalk
 at Smalltalking list archive (and in your mother tongue :)

> I spoke about actual VM or Strongtalk because the
> speed of the VM for this things.

There is very small opportunities where you will
 need more speed from a VM like Squeak for
 writing games.
For example:
One of the circumstances will be for providing
 behavior for particle engines; most particle engines
 let you specify callbacks for manageements of attributes
 of each particle during it's "lifetime"... if you serve
 the callback with smalltalk the number of particles
 you can handle will be smaller that using native languages
 ... but your particles can be much more intelligent :-)

IMHO, you must not worry about this situations because
 are situations where you will know how to avoid the
 limitations when they sit in front of your tips.

As said here, most game production groups use scripting languages.
It is sufficient to do informal development of games;
 e.g. it is better than building games with formal design,
 but it is not enough to be competitive, nor to promote
 interdisciplinary development.
Games industry requieres profesionals of diverse areas and
 current tools do not help them to join efforts and expertice.
Smalltalk (as an open system a.k.a. Ambient :-P ) are a serious
 choice for non-formal development to promote
 interdisciplinary development.
Using a Smalltalk environment as a medium of expression
 is very important to help people that are not programmers
 to express in the game media/support.
The activities realized while developing using smalltalk
 are compatible with game development if used surpassing
 the limits of formal design.

best,
Ale.



----- Original Message -----
From: "Lord ZealoN" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Saturday, October 14, 2006 5:33 AM
Subject: Re: Games with Squeak

On 10/13/06, Diego Fernandez <[hidden email]> wrote:
> I would like to create something similar to the Damien's
> ImageForDevelopers but... ImageForGameDevelopers ;)
>
> Packaged with the tools and tutorials to create simple games in Squeak
> (OpenGL and SDL bindings...).
>

I would like to help with this, I develop games for children with Squeak.

We could make a page called "Game Programming" on the swiki. Was about
to do that right now, but I have no password for the swiki. Anyone
knows how to get one?

Currently, we are using Morphic, which works ok for the kind of
"game-making games" we develop (visual programming tools for children,
similar in spirit to eToys). To have the UI-model of Morphic with
support for components, drag&drop, etc, is a big productivity
advantage for us. Have also been experimenting with Tweak which is
really nice, but as I understand it Tweak, like Morphic, uses standard
Squeak Forms and Display to render graphics.

What concerns me is the blit speed of Form and Display. Have searched
the mailing list and the swiki and obviously there are lots of issues
that have been up for discussion previously, like conversion between
pixel formats, endianness, etc. Have seen mention of FXBlt,
ExternalForm, and ExternalScreen, which seems to be in the Balloon3D
package (which has been replaced by Croquet?). Also found the
NuBlt-project about speedier blits (between Forms in the image, not to
the screen?).

I am confused about the current status of Squeak technologies for high
speed graphics. From what I understand, Croquet is the most recent
work in this area, based on OpenGL.

I have found SDL to be a very good library, have been working with SDL
in Python, using the Pygame library. It has good blitting performance
(will post some performance tests later on, comparing Pygame to
Squeak). Pygame/SDL uses bitmaps in the current format of the display
screen, and I would like to look at how this could be done in Squeak.

As I understand it, there are two ways of using libraries like OpenGL
and SDL in Squeak:

1. As an "add on" that bypasses the Display, and renders "on top of"
Morphic/Tweak. This is how I understand that Croquet works. Drawback
is you cannot use Morphic/Tweak but have to do your own UI system
(like the one in Croquet).

2. As an integrated part of the VM, making Display and Forms use the
native display format. Then you could use Morphic/Tweak with the best
performance.

I have a feeling that it is not as simple as just throwing in SDL as
the graphics engine for the VM, as class Form in the image has its own
platform-neutral format. While it seems to be challenging to be both
platform independent and get maximum graphics performance at the same
time, have there been any work in this direction? I have seen
discussions about converting Forms to native format, but this has an
impact on BitBlt? What is the current status regarding these issues?
What happened to ExternalForm and ExternalScreen? I know many of you
have been working on these things for years, and it would be
interesting to hear your thoughts.

Yes, I would be interested to look at it. How do you use SDL with
Squeak? Do you open a separate window/screen as with wxSqueak? Or do
you render graphics on the Squeak window and use Squeak events for
input? What are your thoughts of using SDL vs. OpenGL for Squeak
games?

There is information about our upcoming game here, there is also a
page with English text: http://www.kreativaspel.se/

Best regards, Micke

Am 05.11.2006 um 12:27 schrieb Mikael Kindborg:

> Have also been experimenting with Tweak which is
> really nice, but as I understand it Tweak, like Morphic, uses standard
> Squeak Forms and Display to render graphics.

Tweak does not use Display directly. This allows for rendering to  
multiple display surfaces simultaneously, like when using Host  
Windows (a.k.a. Areithfa Ffenestri). Also, an experimental version of  
Tweak exists that uses Rome for rendering, although this also writes  
to Display in the end for now.

> What concerns me is the blit speed of Form and Display. Have searched
> the mailing list and the swiki and obviously there are lots of issues
> that have been up for discussion previously, like conversion between
> pixel formats, endianness, etc. Have seen mention of FXBlt,
> ExternalForm, and ExternalScreen, which seems to be in the Balloon3D
> package (which has been replaced by Croquet?).

No, FXBlt has been rolled into regular BitBlt. You can use BitBlt to  
render to any surface registered via SurfacePlugin. Like, RomePlugin  
registers Cairo surfaces that can be used as source or destination of  
BitBlt.

> I am confused about the current status of Squeak technologies for high
> speed graphics. From what I understand, Croquet is the most recent
> work in this area, based on OpenGL.

Yes, which also is a severe limitation for general use as there is  
one important platform lacking good general OpenGL support.

Actually, Tweak or Morphic run fine as an overlay inside an OpenGL  
window. That's how Plopp implements its UI, for example.

> 2. As an integrated part of the VM, making Display and Forms use the
> native display format. Then you could use Morphic/Tweak with the best
> performance.

Actually I think Forms are outdated now, you really want a vector  
graphics API. So what would be best IMHO is opening a host window and  
a canvas on its surface, then using canvas commands to draw onto it.  
I think we have almost all needed bits in place (Host Window Plugin,  
Rome Plugin), they just need to be integrated.

- Bert -

Micke:

Just a few random comments:

Re the swiki, the user name and password are something like
squeak/viewpoints; when I last checked, they exist to keep vandals out,
not regular readers of this list.  A quick search should help if the
preceding pair does not work.

Croquet indeed appears to be the current direction for 3D in Squeak.
Ideally, I would hope to see its retained mode (drawing objects instead
of merely triangles) engine factored for use in Squeak.  It is possible
that it won't matter, but I still think it would offer flexibility for
both Croquet and Squeak.  I had some reasonably intense 3D graphics
running in Wonderland under programmatic control with the camera
controls suppressed, but a bug fix (IIRC for the class builder) more or
less killed it.  With a steady population of objects, it runs quite
well, but after the fix, creating new objects causes disruptive delays.
That aside, the Alice description of objects is designed for end users,
so I was constantly translating from jargon to layman's language to get
it to work.  Alice is very powerful, just not quite in the way one might
want.  Croquet's approach to 3D seemed to be much more direct.

Bill




Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: [hidden email]
Tel: (352) 846-1285
FAX: (352) 392-7029

On 11/5/06, Bert Freudenberg <[hidden email]> wrote:
Ok, that sounds great. I will look at how Tweak does its rendering. I
was thinking it used Display since a Tweak Morphic window works
together with other Morphic windows, but that is perhaps a special
case, when running Tweak in Morphic, or perhaps I miss something about
how the rendering process works.

I will look at the surface plugin, sounds promising!

> > I am confused about the current status of Squeak technologies for high
> > speed graphics. From what I understand, Croquet is the most recent
> > work in this area, based on OpenGL.
>
> Yes, which also is a severe limitation for general use as there is
> one important platform lacking good general OpenGL support.
>

What platform is that?

Well, that is extremely nice, does that boost performance of
Tweak/Morphic or is it mainly a way to integrate the UI with the 3D
objects?

Ok, great! I have to learn how this works. Why are forms outdated? Are
there other, better, options when working with bitmapped graphics?
Like rendering bitmaps in OpenGL? If I draw on the canvas (I assume
you mean a Squeak canvas) then it renders transparently onto the host
window surface?

Many thanks indeed for your pointers!

Best, Micke

Thanks! I also got the Swiki password from Giovanni.

There is now a page on the Swiki to put Game programming material:

http://minnow.cc.gatech.edu/squeak/5891

Best, Micke

On 11/5/06, Bill Schwab <[hidden email]> wrote:

Here are performance tests that compares blit speed of Squeak and
Pygame, a game programming library for Python built on top of SDL
(www.pygame.org).

Test were done on an IBM Thinkpad T40 1.2 MHz, running latest Squeak
3.9 on Windows XP, and latest version of Pygame.

The extent of the image 'Waterfall.png' is 1024@768.
The extent of the image 'Jewel.png' is 140@194 (this is a sprite that
has transparency).

Squeak test code follows here:

background := (Form fromFileNamed: 'Waterfall.png') asFormOfDepth: 32.
sprite := (Form fromFileNamed: 'Jewel.png') asFormOfDepth: 32.
buffer := Form extent: 1024@768 depth: 32.

bb := BitBlt current new.
bb
        setDestForm: buffer
        sourceForm: sprite
        fillColor: nil
        combinationRule: Form over
        destOrigin: 0@0
        sourceOrigin: 0@0
        extent: sprite extent
        clipRect: buffer boundingBox.

t := [1000 timesRepeat: [bb copyBits]] timeToRun.
Transcript show: 'Time for 1000 sprite blits Form over: ', t asString; cr.

bb combinationRule: Form paint.
t := [1000 timesRepeat: [bb copyBits]] timeToRun.
Transcript show: 'Time for 1000 sprite blits Form paint: ', t asString; cr.

bb combinationRule: Form blend.
t := [1000 timesRepeat: [bb copyBits]] timeToRun.
Transcript show: 'Time for 1000 sprite blits Form blend: ', t asString; cr.

bb := BitBlt current new.
bb
        setDestForm: buffer
        sourceForm: background
        fillColor: nil
        combinationRule: Form over
        destOrigin: 0@0
        sourceOrigin: 0@0
        extent: background extent
        clipRect: buffer boundingBox.

t := [1000 timesRepeat: [bb copyBits]] timeToRun.
Transcript show: 'Time for 1000 image blits Form over: ', t asString; cr.

rect:=  0@0 extent: 1024@768.
t := [1000 timesRepeat: [
        Display forceToScreen: rect]] timeToRun.
Transcript show: 'Time for 1000 screen updates: ', t asString; cr.

Here goes the Python code:

import pygame
from   pygame.locals import *

GScreenWidth = 1024
GScreenHeight = 768

pygame.init()

screen = pygame.display.set_mode((GScreenWidth, GScreenHeight))

background = pygame.image.load("Waterfall.png")
background = background.convert()

sprite = pygame.image.load("Jewel.png")
sprite1 = sprite.convert()
colorkey = sprite1.get_at((0,0))
sprite1.set_colorkey(colorkey, RLEACCEL)
sprite2 = sprite.convert_alpha()

buf = pygame.Surface((1024, 768))
buf.convert()

startTime = pygame.time.get_ticks();
destPoint = 0,0
for i in xrange(1000):
    buf.blit(sprite1, destPoint)
endTime = pygame.time.get_ticks();
print "Time for 1000 sprite1 blits:", endTime - startTime

startTime = pygame.time.get_ticks();
destPoint = 0,0
for i in xrange(1000):
    buf.blit(sprite2, destPoint)
endTime = pygame.time.get_ticks();
print "Time for 1000 sprite2 blits:", endTime - startTime

startTime = pygame.time.get_ticks();
destPoint = 0,0
for i in xrange(1000):
    buf.blit(background, destPoint)
endTime = pygame.time.get_ticks();
print "Time for 1000 image blits:", endTime - startTime

startTime = pygame.time.get_ticks();
for i in xrange(1000):
    pygame.display.update()
endTime = pygame.time.get_ticks();
print "Time for 1000 screen updates:", endTime - startTime

pygame.quit()

Here are the results from the Squeak tests:

Time for 1000 sprite blits Form over: 250
Time for 1000 sprite blits Form paint: 775
Time for 1000 sprite blits Form blend: 1051
Time for 1000 image blits Form over: 8579
Time for 1000 screen updates: 21955

Here are the results from the Pygame tests:

Time for 1000 sprite1 blits: 50 (very fast transparent blit)
Time for 1000 sprite2 blits: 373
Time for 1000 image blits: 7090 (Squeak is not that slower)
Time for 1000 screen updates: 7031

I have looked a bit at the Windows VM sources and in sqWin32Window.c
in function ioShowDisplay it seems that the Windows call
SetDIBitsToDevice is used to put the pixels on the display. Is this a
bottleneck when it comes to the display update speed? I guess
SetDIBitsToDevice converts the DIB to the pixel format of the graphics
card?

Best, Micke

Hi again,

I discovered that when you have many smaller non-overlapping animated
morphs (sprites) the display rate suddenly drops in an unexpected way
when adding new sprites. That was puzzling me, but then I stumbled
across a method in class DamageRecorder and found that when having
more that 15 dirty rectangles they are merged. That causes a much
bigger area of the screen to be redrawn, casing the drop in update
rate.

Attached is a change set that adds a class method to DamageRecorder
that makes it easy to experiment and change the maximum number of
invalid rectangles to fit with the game/application at hand.

Best, Micke

Hi Diego,

On 10/13/06, Diego Fernandez <[hidden email]> wrote:
>
> So I was looking for SDL bindings, I've found some mentions in the
> swiki and in the mail archive, but they seems outdated and I didn't
> found anything in Squeaksource or SqueakMap.
> So in my spare time  I started an SDL binding using FFI (Andreas FFI
> is great :) thanks!!!).
> I didn't finish it yet but I could publish it "as is" into
> squeaksource.. so others can help me :)
>

I have looked a bit at how to access surfaces from Squeak using the
SurfacePlugin pointed to by Bert. Found some useful information in an
email from Andreas, which I have put on this page:
http://minnow.cc.gatech.edu/squeak/5891

What do you think about doing an SDL plugin and draw on SDL surfaces
via the SurfacePlugin?

Which approach did you use for your SDL binding?

Best regards, Micke

On 11/5/06, Mikael Kindborg <[hidden email]> wrote:
> On 10/13/06, Diego Fernandez <[hidden email]> wrote:
> > I would like to create something similar to the Damien's
> > ImageForDevelopers but... ImageForGameDevelopers ;)
> >
> > Packaged with the tools and tutorials to create simple games in Squeak
> > (OpenGL and SDL bindings...).
> >
>
> I would like to help with this, I develop games for children with Squeak.

Great!! :)

> We could make a page called "Game Programming" on the swiki. Was about
> to do that right now, but I have no password for the swiki. Anyone
> knows how to get one?

I've created a project in SqueakSource, with public Read&Write
permissions, so we can share our "experiments" there:

MCHttpRepository
        location: 'http://www.squeaksource.com/GameDevTools'
        user: ''
        password: ''

There you can get the pre-pre-pre-alpha version of the SDL bindings.
They doesn't do anything useful yet, only Init, SetVideoMode and
LoadBMP.
I'm doing this in my spare time, so the advances are really slow, so
if you want to help we can learn more about FFI, SDL Surfaces et. al.
together :)


> 1. As an "add on" that bypasses the Display, and renders "on top of"
> Morphic/Tweak. This is how I understand that Croquet works. Drawback
> is you cannot use Morphic/Tweak but have to do your own UI system
> (like the one in Croquet).

This option is more simple for us (the developers of the SDL bindings :) ).
So this is my first approach, develop the interfaces to interact with SDL.

> 2. As an integrated part of the VM, making Display and Forms use the
> native display format. Then you could use Morphic/Tweak with the best
> performance.

I don't know is there is a performance gain in using SDL for this.
SDL is only an "adapter" for the OS libraries (DirectX, OpenGL, etc).
So I don't want to use SDL as the graphic engine for the VM.

My intentions are at first much much less ambitious: collect a series
of packages for game development in Squeak, and put them together,
with tutorials and examples.

I started the SDL bindings because I didn't found the ones mentioned in:
http://minnow.cc.gatech.edu/squeak/1833

Regards,
Diego,-

Hi!

On 11/6/06, Diego Fernandez <[hidden email]> wrote:
Great, updated the SDL page on the swiki with this info, and made a
link from the game programming page:
http://minnow.cc.gatech.edu/squeak/5891

Anyone knows if previous work on SDL-bindings is available somewhere?
Would be useful as a reference.

>
> > 1. As an "add on" that bypasses the Display, and renders "on top of"
> > Morphic/Tweak. This is how I understand that Croquet works. Drawback
> > is you cannot use Morphic/Tweak but have to do your own UI system
> > (like the one in Croquet).
>
> This option is more simple for us (the developers of the SDL bindings :) ).
> So this is my first approach, develop the interfaces to interact with SDL.
>

I see, but it would be good to also  improve the speed of Morphic/Tweak.

The performance tests I did with Pygame shows that in terms of blit
speed, both between images/forms and to the display, we could have
something to learn from SDL. I am wondering if the generality of
BitBlt is what makes it perform less well than Pygame/SDL, or if other
aspects are involved.

For blitting between forms it could be worthwhile to continue the
development of NuBlt, and make a speedy blitter for specialised cases
of 32-bit forms and Form over and Form paint operations.

For high-end games Morphic/Tweak support might not be relevant, but I
wonder if the previous SDL-bindings where using SDL as the engine for
the VM, or if they were using your approach.

Also, with the Surface Plugin, it should be possible to use SDL
surfaces transparently as Forms in Squeak. Then again, OpenGL might be
a better option, as you and Bert discussed previously.

> > 2. As an integrated part of the VM, making Display and Forms use the
> > native display format. Then you could use Morphic/Tweak with the best
> > performance.
>
> I don't know is there is a performance gain in using SDL for this.
> SDL is only an "adapter" for the OS libraries (DirectX, OpenGL, etc).
> So I don't want to use SDL as the graphic engine for the VM.
>

Yes, in my tests, blitting to the display took the longest time, and
perhaps this is not possible to optimise without using a bitmap
organisation that matches the display surface (which is was SDL does).
But is should be possible to convert forms in the Squeak image to the
format of the display, e.g. on startup or on the fist use of the form
(or simply manually in the application code). This this approach can
be a promising one, given how well Pygame performs.

> My intentions are at first much much less ambitious: collect a series
> of packages for game development in Squeak, and put them together,
> with tutorials and examples.
>

Yes, we should get a collection of code examples.

> I started the SDL bindings because I didn't found the ones mentioned in:
> http://minnow.cc.gatech.edu/squeak/1833
>
> Regards,
> Diego,-
>

Best regards, Micke

Hi!

"Mikael Kindborg" <[hidden email]> wrote:
> For high-end games Morphic/Tweak support might not be relevant, but I
> wonder if the previous SDL-bindings where using SDL as the engine for
> the VM, or if they were using your approach.
>
> Also, with the Surface Plugin, it should be possible to use SDL
> surfaces transparently as Forms in Squeak. Then again, OpenGL might be
> a better option, as you and Bert discussed previously.

What about Rome - the new Cairo plugin? I have of course no idea, just
giving a headsup. :)

regards, Göran

Thanks! Found Rome on Squeak source.
Ha det bra! Micke

On 11/7/06, [hidden email] <[hidden email]> wrote:

>
> Great, updated the SDL page on the swiki with this info, and made a
> link from the game programming page:
> http://minnow.cc.gatech.edu/squeak/5891
>
> Anyone knows if previous work on SDL-bindings is available somewhere?
> Would be useful as a reference.
>

Reda Forth is using SDL for doing all the rendering. It might be a good
reference starting point.

    http://www.geocities.com/redaforth/reda4pc.zip

I am also attaching the source code files where SDL is being referenced
(comments are in Spanish, but Diego won't have a problem with that).

Umhhh, now I understand why it Reda4 looked so bad on a double monitor...

if(!(gr_screen=SDL_SetVideoMode(1024,768,32,SDL_DOUBLEBUF|SDL_FULLSCREEN)))
//if(!(gr_screen=SDL_SetVideoMode(800,600,16,SDL_SWSURFACE|SDL_DOUBLEBUF|SDL_FULLSCREEN)))
//if(!(gr_screen=SDL_SetVideoMode(640,480,32,SDL_DOUBLEBUF|SDL_FULLSCREEN)))
  return -1;

Cheers,
Francisco