Re: [stella] Splatform 2600

Subject: Re: [stella] Splatform 2600
From: "Thomas Jentzsch" <tjentzsch@xxxxxx>
Date: Tue, 11 Nov 2003 10:25:27 +0100
Christopher wrote:
> Comparing the two, I don't think the hard scroll is a big deal since the scrolling is only "intermittent" and on irregular shapes (you don't get the effect of watching a horizon stutter along) it's not as noticeable.

Yes, both versions look quite good, but IMO the smooth scrolling looks and plays just a little bit better. 
And I wanted to do something new, since the hard scrolling idea is a 1:1 copy from Thrust. :)

> That being said, is the grouping a hardware limitation of some kind (are you doing a full reposition of sprite(s) each scanline or just a relative reposition)? 

No, there is no limitation coming form the kernel. The grouping seems to happen because there is only one platform per row allowed. This seems to cause the grouping effect (still not sure why). I even had results, where after a while *all* platfroms where on almost the same column.

> Can't you just fudge the platform generation to prevent clumping - ie:, check if there's a platform just above and if there is, regenerate (or skip generation until later)?

That's sounds like a possible solution. But that doesn't work very well too, because the result is, that the platforms are grouped every 2nd row then. 

Currently the algorithm works like this:
- define a platform density factor for each level
- generate the initial layout. With every scrolling step (4 pixels) factor/38 (the number of visible columns) is added to a SUM varable.
- Scroll, 
  For each row
  - check if row is empty
    - empty:
      compare random number with SUM variable
      if below, generate new platform, subtract large value (7, after some experimenting) from SUM
    - not empty
      - check if platform at right
        - yes, compare random number with a table value (depending on the length of the platform)
        - if below, generate additional platform piece, subtract 1 from SUM
    - not empty            
      check if platform piece leaves screen at left
        - if yes
          - last piece, add large value to SUM
          - else add 1 to SUM

This keeps the density constant over the whole level and gives all platform lengths about the same chance. A platform is weighted higher than a single piece of it, still larger platforms are weighted higher than small ones. 

While the initial screen is always very good, sooner or later the grouping happens and then soon gets worse and worse. Can anybody find the flaws in the algorithm?


Horoskop, Comics, VIPs, Wetter, Sport und Lotto im WEB.DE Screensaver1.2
Kostenlos downloaden:

Archives (includes files) at
Unsub & more at

Current Thread