So, I was working a little bit on a Breakout/Arkanoid game in Engine BASIC and came to the realization that I need to implement some sort of rudimentary task scheduler (not sure if this nomenclature is correct?). Having inbuilt VSYNC and TICK functions is a huge help, of course. Having a single ball and paddle moving simultaneously is a very easy task, of course, but my real problem will come when introducing multiple balls moving about at the same time, the paddle moving, blocks exploding when hit, and when lasers/photons are shot at the paddle from around the screen.

I'm certain I can do it in standard BASIC spaghetti code, but the need for scheduling and allotting time slots per second (or per 60th or 30th or? of a second) seems obvious.

I just wrote out, on paper, a very simple bit of stuff that does something like:

start of main loop
tm=TICK()
IF tm<TICK()+125 then jump to this procedure or subroutine or defined function
IF TICK()+250>tm+125 AND TICK()+250<tm+250 then jump to this procedure or subroutine or defined function
etc.
end loop and go back

Can anyone point me at something to read or checkout? I realize that it needn't be super involved for Breakout/Arkanoid, but my hope is this is just the beginning. I made sprite images and ideas for a redo and enhancement to my favorite game of all time - and THE best computer game of all time, Star Raiders for the Atari 8 bit.

Edited Saturday Night: I didn't get any work done on this, unfortunately. We stayed at our high elevation cab and had a hefty snow. I played chauffeur for my wife and three of her coworkers. That took up the extra time I had allocated to this. In any case, I did upload the new program to Git at the link below. It does need some changes, it needs lots of comments to help people read my crappy code, and it needs an alternate version to read frames instead of time via TICK.
Github >> [https://github.com/painintheworld/Engine-BASIC-Task-Scheduling-Stuff](https://)

Edited Friday Night: Will upload new demonstration of what I'm getting at tomorrow (Saturday). It is mostly buttoned up now, but I'm still tinkering with it. The new program actually does a little bit of stuff during each test, by moving a sprite (tests pushed up to 8, with a different sprite for each test, with each sprite given a random starting position, and random X/Y movement speeds). It has become evident, at least in the minimal amount of stuff that is happening in the loop, that I need to change things around to count frames at the beginning and end of the loop (counting time at the beginning and end of the loop in latest version of the new program), instead of counting time. I underestimated the horsepower available! It essentially going through each of the 8 tests, moving 8 sprites, and comparing TICK() at the beginning and end of the loop. It is going through those tests inside the loop so fast, especially on the x64 (literally taking less than 1/1000th on x64), that it is a bit comical.

###################################################################

Okay, a little early, early morning tinkering shows me that I need to do some more figuring on this 😆

@uli , if you get a second to read this, I would really appreciate a professional tip or two 😃

This is what I wrote out on paper a couple or three hours ago. I rushed by the cabin for a minute to try it out.

The test bed for the moment is BASIC Engine NG (v0.90-3.20). For this test, I am checking in roughly 1/8 second increments. This was an arbitrary number for now, because it seemed like a good starting point 😅

The loop is a WHILE/WEND loop that terminates when a key is press. tm grabs the current TICK() value at the beginning of the loop. I'm fairly certain the first test has to be changed, as the output for the subroutine it calls tells the tale of being much more performant than I imagined. The second and third tests are actually less performant than I imagined. I am also fairly certain that those are screwed up, too 🙂 It is after 2AM here and I have 60 miles (100 kilometers) to drive in a moment or two, so maybe the correct methods might come to me on the way 🙂

10 CPUSPEED 100
100 SCREEN 14:PALETTE 2
105 fr=FRAME()
110 WHILE INKEY$=""
130 tm=TICK()
150 IF tm<TICK()+100 THEN GOSUB &test1
170 IF tm+250>TICK()+125 AND tm+250<TICK()+250 THEN GOSUB &test2
190 IF tm+375>TICK()+250 AND tm+375<TICK()+375 THEN GOSUB &test3
900 REM fr2=FRAME()
910 REM frm=fr2-fr
915 REM COLOR 172
920 REM LOCATE 0,7
925 REM PRINT "frame #=";frm
1000 VSYNC
1010 frm=frm+1
1020 LOCATE 0,7
1030 PRINT "frames=";frm;" / seconds=";INT(frm/60)
1100 WEND
1200 SCREEN 13:PALETTE 2:COLOR RGB(255,255,0):LIST 0-1200:END
4998 ' do stuff here
4999 ' add sprites or something, so there will be more work done
5000 &test1
5010 tst1=tst1+1
5015 LOCATE 0,0
5016 cl1=RND(255)
5017 IF cl1=0 THEN GOTO 5016
5018 COLOR RGB(cl1,cl2,cl3)
5020 PRINT "tst1=";tst1
5050 RETURN
5100 &test2
5110 tst2=tst2+1
5115 LOCATE 0,1
5117 cl2=256-cl1
5118 COLOR RGB(cl1,cl2,cl3)
5120 PRINT "tst2=";tst2
5150 RETURN
5200 &test3
5210 tst3=tst3+1
5215 LOCATE 0,2
5216 cl3=RND(256)
5217 IF cl3=0 then GOTO 5216
5218 COLOR RGB(cl1,cl2,cl3
5220 PRINT "tst3=";tst3
5250 RETURN

  • Hawk replied to this.
    5 days later

    painintheworld Hi, have you considered a Round Robin type scheduler?
    You call each routine in turn, and the routine decides whether it needs to do anything or not based on the tick count. The advantage of this is that you could keep a dynamic list of the routines that need to be called. You can add or subtract from the list as objects are created or destroyed.
    Some routines might do some thing every call, others may only do something every 10th call.
    The scheduler knows how many ticks it should take to go around, and if it is too quick then it delays until it's time to go again.
    If the scheduler detects that a cycle has taken too long, then you've had an overrun and your system will start to run slower and more jerkily.

        Hawk I did have a similar idea, but had no idea what it was called 😄

        I've not felt good the last couple of days, so no more work has been done. That will change Friday (fingers crossed)! I will definitely try to implement a very basic version of what you suggest.

        What did occur to me is that for a basic Breakout/Arkanoid game, is that I'm make things more complicated than they need to be. VSYNC has worked exceptionally well for what has been needed so far. Counters have been used to trigger events, etc.

        I should have done more of this 40 years ago, when my mind was more of a sponge 🙂

          Powered by: FreeFlarum.
          (remove this footer)