Tetris

Michael Donegan invader at zilker.net
Wed Dec 1 08:27:48 UTC 1999


In my lost version of Tetris, I eliminated a lot of the redrawing. It was
actually pretty easy. And it did help in that it took longer to get
sluggish, but it still got sluggish. It just took longer.

It is a fun problem, all right. I think that more complicated algorithmic
changes are required. I was just looking for a magic bullet so that I
wouldn't do some big overhaul to no avail.

The changes I had made up to this point not only made it faster, but also a
lot easier to understand. I'll give it another shot.

	mkd

>Michael Donegan <invader at zilker.net> wrote...
>>But, before going back and doing it again, I was wondering if anyone would
>>like to do a tutorial on how to go about finding the hot spots in something
>>like this.
>>
>>Has anyone else looked at this problem?
>
>Not until 5 minutes ago.  MessageTally is one tool I use a lot (as Scott
>suggests).
>
>Another diagnostic technique is to turn on viewing of damage rectangles.
>Browse to PasteUpMorph>>displayWorld, and change the occurrence of 'false
>ifTrue:' to 'true ifTrue:'.  Suddenly your screen will start flashing.
>What is happening is that prior to repainting any part of the screen,
>morphic paints it black.  This lets you see how much work morphic is doing.
>
>My recent tweak to AlignmentMorphs was the result of my discovery in
>exactly this manner that entire alignment structures were being repainted
>when only smallparts of them were really changing size.
>
>Anyhow, applying this to Tetris, you see that the entire game board is
>being redrawn every time any block moves.  Looking for the reason, you'll
>soon discover that the entire board is being *created anew* (paint) every
>time a block moves.  This was a surprise to me -- I expected each block to
>be a morph.  If the blocks were morphs, then they could be moved by one
>line of code, and they would only cause that small rectangle to get
>redrawn (and of course no removal or addition of morphs would take place.
>
>It looks like it might be hard to delete just the bottom row if each block
>is a morph.  I would handle this by having the game board extend below the
>bottom line and delete blocks as they pass completely below the bottom
>line.
>
>One could stick with the current model (a morph per square) and still
>greatly improve efficiency by representing the current block as a
>collection of 1-square morphs.  Then for moveLeft or moveDown, you just
>tell each component square to move left or down, and morphic will take
>care of repainting just the cells that change as a result.
>
>It's a fun problem.
>Isn't it nice that Aibek took the trouble to build it?
>Isn't it great to have it in Squeak where we can not only play it, but
>also play with it?
>
>It would be fun to see how small it could be in morphic Squeak, and
>compare it with the Java from which it was ported.
>
>	- D





More information about the Squeak-dev mailing list