15th of March – 50Hz – adapting…

High Score

Last night I implemented most of the planned high score system.

I leaned heavily on my experience with Karl Quappe. Persistent high scores will be possible with:

a) a DS2431a one wire eEprom

b) VecFever

There will be 5 high score entries only, comparing, saving loading is all finished – only thing is – I haven’t done a high score screen yet. So – it is so far not possible to actually see the scores – or enter a name. Its these menial tasks that are annoying – and that I try (often times successfully) to avoid :-).


In one of the earlier entries on this blog I mentioned, that the original game sports a “starfield” display in the background. That also was a thing that I tried (successfully…) to avoid. After some thinking I did a first implementation yesterday.

The “beauty” of my implementation is, that is easily scalable (you will see why that is “beautiful” if you read on…).

Since I implemented nearly every entitiy of the game in things called “objects” – I liked to implement the effect also as an “object”.

As you might recall – the original ObjectStructure looks like:

                    struct   ObjectStruct
                    ds       Y_POS,1                      ; current position
                    ds       X_POS,1                   
                    ds       CURRENT_LIST,2               ; current list vectorlist 
                    ds       DDRA,1                      
                    ds       SCALE,1                      ; scale to position the object
                    ds       BEHAVIOUR,2
                    ds       TYPE,1                       ; enemy type
                    ds       ANGLE,2                      ; if angle base, angle in degree *2
                    ds       PREVIOUS_OBJECT,2            ; positive = start of list
                    ds       NEXT_OBJECT,2                ; positive = end of list
                    ds       filler, 5                     
                    end struct 

Reusing the object “pattern” the object structure for one starfield “atom” looks like:

                    struct   ObjectStruct
                    ds       POS_1,2                      ; 
                    ds       SCALE_1,1                   
                    ds       POS_2,2                      ;  
                    ds       SCALE_2,1                      
                    ds       BEHAVIOUR,2
                    ds       TYPE,1                       ; 
                    ds       POS_3,2                      ; 
                    ds       PREVIOUS_OBJECT,2            ; 
                    ds       NEXT_OBJECT,2                ; 
                    ds       POS_4,2                      ; 
                    ds       SCALE_4,1 
                    ds       SCALE_3,1 
                    end struct 

I must always have the fields “Beaviour”, “type”, “next_object”, “previous_object” – all other fields might be reused by data. So one starfield “atom” has information of 4 stars. One star is described with “POS” (y, x coordinate) and “SCALE” (how far away from the middle).

The spawning of such an object actually does (apart from the usual):

  • build a random number and set the scale to that
  • set pos to $ffff (initialization marker)

The “behaviour” does:

  • if in initialization (pos == $ffff)
    – decrease scale as a counter
    – if zero do secondary initialization, which is:
    – find a random “angle” and its position information
    – set the position accordingly
    – set scale to 10
  • else
    – according to current scale:
    – add to scale (the higher the scale, the higher the add)
    – if scale > max – do another initialization
    – else
    – set intensity (the higher the scale, the higher the intensity)
    – set the actual scale to t1
    – move to the position
    – draw a dot

With that a not desasterous looking mini starfield (of 4 stars) is implemented.

If I spawn more of these objects – more stars are displayed. If only the starfield is displayed, I can go up to about 120 stars (30 starfield “atoms”) and still be under 50Hz – so approximately one atom takes less than 1000 cycles.


As I repetitively said – I like to stay within 50Hz. Apart from collision detection with a large shield I can achieve that most of the time easily. I will not look at collision detection in relation to 50Hz again, since that is a “singular” event.

The “cool” thing about Release is, that there are game elements which are necessary and there elements that are not strictly speaking necessary.


  • base
  • shield
  • enemies


  • explosions
  • floating scores
  • starfield

If there is so much “action” on screen, that the game comes near the 30000 mark – the user (gamer) will most certainly not bother about the “can things”. So if we are in danger to break the 50Hz barrier I can tweak here!

That “tweaking” is what I call scaling…

Within the game I can watch certain information and take actions according to its analysis results, following information I have available:

  • number of current objects
  • number of starfield atoms
  • max scaling of explosion
  • max scaling of scores
  • time left of last update round

(in case you wonder – I have an own WaitRecal routine, which right befor the T2 wait loop stores the VIA_t2_hi, that value times 256 is exactly the number of cycles I have to “spare”)

If the analysis comes to the result that I am:

  • dangerously near the 50Hz barrier
  • have only a “few” of my 35 objects left

I can take action such as:

  • lower the explosion scale (the explosions take an inapproriate amount of cycles)
  • lower the score scale
  • forbid new “score object”
  • reduce the number of starfield atoms

And vice versa (expand explosion scale, spawn new starfield objects…).

I uploaded a gameplay video on YouTube (my wordpress support of videos is dwindling somehow):

VRelease demo (4 minutes)


Image with a starfield, Bonus “shield” was captured, the base shows the countdown – 27seconds left.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.