Entry 2018: A Sparrow Goes Flapping

[Kiwi]

This is my entry. Today is the 2 year anniversary that I released an "improvement" version of A Sparrow Goes Flapping. So, I'm porting that game to the Intellivision. It is called A Sparrow Goes Flapping. You can get the Colecovision ROM version here: http://atariage.com/forums/topic/254474-kiwis-game-a-sparrow-goes-flapping-available-to-play/?hl=%2Bsparrow+%2Bflapping#entry3547284 Eventually I'll add more improvements to that version like adding the volcano level to it. Maybe a snow level...

It is early in development. No sound effect or music yet, so you don't disturb your next door neighbor or any other family member who may be sleeping at this time. It's pretty much my very least favorite part of making a game. It only contain 1 level, but defeating the boss will make the game more difficult and difficult.

 

Here's the Intellivision ROM: Asparrow.rom

And here's the gif.

 

Dang it, 1 point away...

 

Instructions: Go through trees to the end of the forest, where you face a badly rendered owl, pretty hard to make a good looking one in 8x16 card. You can break sticks(and stones[which will be in level 2]) with your birddash attack ability, which can be press with the top button. While birddashing, you are invincible(becomes blue) during this time. Solid object like trees will halt the birddash. After birddashing, it takes the sparrow some time to recover. He flashes pink when he's recovering. Also use this birddash ability to attack the boss of the level.

 

Keypad 0 is the pause key. it overrides the 5 objects on screen to display the word "PAUSE". Use this to do whatever you need to do in the real world. Any of the side button or key 0 will remove the pause feature and the game will resume. Pressing the top button from unpausing the game will make the bird, birddash, so I recommend pressing the bottom buttons to unpause.

Breaking sticks will cause the power up to appear later in the stage. Eating apple will spawn a star.

Items:

Star:Makes you invincible for about 9 seconds

Heart:Restore your health to the maximum
Cape:Reduce your rest time after birddashing

Shield:Increase your after hit invincibility

I haven't tried the ROM on the Intellivision. It should work.

Bug: Sometime apple may hurt you, I'm not sure why yet. I'm using hardware collision.

[+Steve Jones]

awesome, thanks

[Utopia]

Very nice, playing it now!

[emerson]

I just played a few rounds, and this is pretty good! Decent graphics overall, plus it has a quick learning curve. My only suggestion is to add some code that waits for the "unpause button" to be released before returning to gameplay.

[+DZ-Jay]

It looks great! I'll take it for a spin this week-end.

 

 

Go through trees to the end of the forest, where you face a badly rendered owl, pretty hard to make a good looking one in 8x16 card.

 

Looks like a flying squirrel to me!

 

 

Bug: Sometime apple may hurt you, I'm not sure why yet. I'm using hardware collision.

 

That's probably because some apples are rotten and have worms.

 

-dZ.

[carlsson]

Over at FB, some of us are trying to convince Kiwi to turn the sparrow into a swallow and add killer rabbits, coconuts and a shrubbery...

[Kiwi]

New v0.15 ROM: Asparrow015.rom

 

Solved the collision issue. The stic.txt said that collision is sticky. So I update the sprite table after removing the sprite. poke 0 to the collision register to clear it since the txt said the CPU suppose to clear it(I don't know when it to get around doing it, and obviously it can't do it when the screen is being drawn.). So the apple now won't hurt or give you the star invincibility. The star spawn immediately upon getting over 5 apples, and the stick spawning might occur exact time you ate the apple. So the collision register wasn't being cleared and activate whatever it has just loaded into that object slot. Hopefully that makes sense. So the code is now...

if objID(i)=3 then ID=i:gosub RemoveObject:poke $0018,0:gosub UpdateSprite:#score=#score+2:birdHP=birdHP+1:apple=apple+1:gosub DrawHP:wait:poke $0018,0:if apple>5 then objecttype=1:d=0:gosub CreateObject:apple=0

And I added 2 more items, the green magic mushroom and the purple jewel. The green magic mushroom will revive you on the spot if you take a fatal hit, and then disappears. The purple jewel just add 50 points to your score. I redrew the "Owl". The pause screen now shows the item you have in your possession. I made the items higher resolution since I'm not using 14 cards that reserved for the background tileset.

Edited July 6, 2018 by Kiwi

[+DZ-Jay]

Solved the collision issue. The stic.txt said that collision is sticky. So I update the sprite table after removing the sprite. poke 0 to the collision register to clear it since the txt said the CPU suppose to clear it(I don't know when it to get around doing it, and obviously it can't do it when the screen is being drawn.).

 

It means that they will remain until the programmer clears them manually, i.e., when the CPU is instructed to write zero into the collision registers.

 

nanochess: Since these are cached by IntyBASIC, should the kernel have the responsibility of clearing them on every frame?

 

By the way, I know you are one of the old-school users of IntyBASIC from when it was growing up, but it now supports "IF/END IF" blocks, so you don't have to put all that into a single line.

 

Now, about the game, I finally took some time to play it, so here's my feedback:

• Works great! I like it. I beat the flying squirrel mean owl!
• It "feels" as if it could use some acceleration when moving.
• I don't understand what the floating yellow horizontal things are...
• Apples and other debris fall at a too much constant rate, it seems artificial. Perhaps you could add acceleration due to gravity to make it feel a bit more natural.
• I understand that the sparrow flickers with some colour when recovering from its "dash," but it is too subtle. When I am fighting with the flying squirrel owl, for example, I am paying attention to many items on the screen and can't really focus on the sparrow. Maybe you can make it flicker in a more obvious way so that it can still be noticed in my peripheral vision. As it stands right now, I have to stare at it directly and focus in order to notice (and I get hit by some flying thing).
• When fighting the flying squirrel owl, he shoots some blue "force field" (it reminds me of the satellite force fields in Gyruss). These seem randomly positioned but 99% of the time they are aligned vertically covering the entire stretch of the screen, and I cannot avoid it. Very, very, very seldomly do they leave a tiny gap between them through which I can manœuvre. I do not know if this is intentional, but if it is, it feels unfair -- as if every time the force field shows, I am going to get hit no matter what.
• Could you make the game start by pressing the disc also? It's sort of common...
• The scrolling is not completely smooth: there is a glitch/stutter after every few columns. You may need to review your game loop to make sure the screen block-copy on every 8th shift is occurring correctly.
• I can't wait to hear some sound effects and perhaps some background music.

 

It's looking very good! Keep it up!

 

-dZ.

[Kiwi]

 

It means that they will remain until the programmer clears them manually, i.e., when the CPU is instructed to write zero into the collision registers.

 

nanochess: Since these are cached by IntyBASIC, should the kernel have the responsibility of clearing them on every frame?

 

It does as I look at the asm .lst. I think when I added gosub updatesprite, which update all 6 sprites perimeter, The sprite removed no longer overlaps. But this insures that Col0 is zero.

 

By the way, I know you are one of the old-school users of IntyBASIC from when it was growing up, but it now supports "IF/END IF" blocks, so you don't have to put all that into a single line.

To keep it in one line. There's many if/end if blocks in the code.

Now, about the game, I finally took some time to play it, so here's my feedback:

• Works great! I like it. I beat the flying squirrel mean owl!

  Cool

• It "feels" as if it could use some acceleration when moving.
• I don't understand what the floating yellow horizontal things are...

  The star. Collecting this will make you invincible. Cape and other items I listed will show up if you defeat enough enemies.

• Apples and other debris fall at a too much constant rate, it seems artificial. Perhaps you could add acceleration due to gravity to make it feel a bit more natural.
• I understand that the sparrow flickers with some colour when recovering from its "dash," but it is too subtle. When I am fighting with the flying squirrel owl, for example, I am paying attention to many items on the screen and can't really focus on the sparrow. Maybe you can make it flicker in a more obvious way so that it can still be noticed in my peripheral vision. As it stands right now, I have to stare at it directly and focus in order to notice (and I get hit by some flying thing).

  There will be audio cue when you're ready to dash again.

• When fighting the flying squirrel owl, he shoots some blue "force field" (it reminds me of the satellite force fields in Gyruss). These seem randomly positioned but 99% of the time they are aligned vertically covering the entire stretch of the screen, and I cannot avoid it. Very, very, very seldomly do they leave a tiny gap between them through which I can manœuvre. I do not know if this is intentional, but if it is, it feels unfair -- as if every time the force field shows, I am going to get hit no matter what.

  They are towering tornadoes. Air dashing when it is at the very left edge of the screen will let you pass through to avoid being hit.

• Could you make the game start by pressing the disc also? It's sort of common...
• The scrolling is not completely smooth: there is a glitch/stutter after every few columns. You may need to review your game loop to make sure the screen block-copy on every 8th shift is occurring correctly.

  This is something I have to test on the real Intellivision. With the emulator on this machine, JZintv, drops 1%-2% of frames. And block copy is probably the most cycle intensive part of the frame. And I'm unsure how much cpu cycle is left before wait on that frame, and prefer the game to run at 60fps if possible. I did some technique that let me guess where the beam is at by writing to the border color before wait and after wait. After a wait, I used border 0, then before the wait I used border 4. If the border doesn't flash, it means that the intellivision is still drawing the screen and deny the write to the register.

• I can't wait to hear some sound effects and perhaps some background music.

It's looking very good! Keep it up!

Thank you for your comments and playing my game.

-dZ.

Edited July 7, 2018 by Kiwi

[+DZ-Jay]

Thanks for the response. A few more things:

• Looking back at your comments, the "yellow horizontal things" are sticks. Perhaps painting them brown would help clarify this (I don't know).
• I get the tornadoes, those seem fine. But there are some vertical bars that show up, two of them at a time, and when they align vertically (which they do 99% of the time), they block the entire screen. A few points on that:
  • Forcing to use the dash mechanic to avoid them seems unfair, since the dash mechanic is used to attack the owl as well and requires a long cool-down period.
  • Also, sometimes you get the force field and the tornadoes at the same time, but you only have one dash at a time. It seems unfair to force the player to lose health by one or the other.
  • They look too much like energy force-fields, which does not seem to belong in this kind of game.
  • I just played a round where by pure luck most of those force-fields had a gap between them. This suggests that it is not really intentional for them to block completely the screen. I recommend adding a check to always leave a little sparrow-sized gap. This allows the player to use his manœuvering skills to escape, giving him a chance to survive even when his dash is not available. It is still quite challenging to manœuvre between them.

Here's a screenshot of what I mean:

 

Note that since they blue thingies are multiplexed, they don't show up in the screenshot. In practice, those two blue thingies, replicate vertically blocking the entire screen path.

 

Cool, nonetheless.

 

-dZ.

[+DZ-Jay]

• This is something I have to test on the real Intellivision. With the emulator on this machine, JZintv, drops 1%-2% of frames. And block copy is probably the most cycle intensive part of the frame. And I'm unsure how much cpu cycle is left before wait on that frame, and prefer the game to run at 60fps if possible. I did some technique that let me guess where the beam is at by writing to the border color before wait and after wait. After a wait, I used border 0, then before the wait I used border 4. If the border doesn't flash, it means that the intellivision is still drawing the screen and deny the write to the register.

 

It doesn't necessarily have to be the scrolling skipping (I just checked in the debugger, and STIC writes are not dropped except when moving many sprites on screen -- and that was clearing the collision register of MOB #0, so that's not it). It is most likely screen "tearing" which occurs when the copy block does not stay ahead of the STIC pre-fetch to draw the frame.

 

As you know (but for the benefit of others) the scrolling mechanic works like this:

1. Every frame you shift then screen by one pixel via the "horizontal/vertical delay" register of the STIC.
2. When you have shifted 8 pixels, an entire column/row has been moved, so...
   • you draw a new column/row on the appropriate edge,
   • and shift the entire screen one card in the direction of scrolling.
3. You then reset the horizontal/vertical delay register to zero and start again with step #1.

Concurrently, the STIC drawing of the screen works like this:

1. On every Vertical Blank (VBLANK) period of the TV raster, it interrupts the CPU giving it a chance to update the STIC and graphics memory. This "VBLANK Period" is divided into two:
   • VBLANK 1 - in which the CPU gets access to the graphics bus and the STIC registers. We normally update MOB, Scroll, and other STIC registers here.
   • VBLANK 2 - in which the CPU still has access to the graphics bus, but not to the STIC itself. We normally update GRAM here.
2. Right after VBLANK 2 completes, the CPU starts "pre-fetching" card data from the BACKTAB and populating its FIFO which ultimately will be used to guide the raster.
3. This pre-fetching is done periodically through active display, and is done from top-to-bottom, left-to-right, i.e., in BACKTAB address order.

The trick to smooth scrolling is to get your horizontal/vertical delay updates (step #1 in scrolling algorithm above) during VBLANK 1, and to keep your screen shifts (step #2 in scrolling algorithm above) ahead of the pre-fetching requests of the STIC. If you let the STIC overrun you, the updated BACKTAB will not make it to the next frame, and will instead have to wait an entire other frame.

 

In practice, there should be plenty of time, since copy loops are much faster than the interval of BUSRQ pre-fetching interrupts. The critical thing is to start as early as possible so that you can stay ahead. Once you have that lead, you're probably safe, but if you miss it -- even if you catch up -- you would have missed the updating of some BACKTAB cards.

 

Note that we're not talking about the BACKTAB not getting updated. The updates happen as you do them (unlike GRAM when you miss the VBLANK window). We're merely talking about those updates making it to the next frame sent to the TV raster. Missing the pre-fetch means that the old data would be used for those cards when drawing the next frame.

 

As you may imagine, this results in the screen either "jumping" between frames, or in "tearing" when some parts belong to the new frame and others to the old frame.

 

This is why IntyBASIC reserves 20 cards for scrolling, even if you are scrolling horizontally: in order to draw the top row as quickly as possible and stay ahead of the BUSRQ pre-fetch requests.

 

...

 

All that said, I also recommend you test your game on the Intellivision just to rule out any jzIntv quirks or PC-induced latency. This is usually a hard problem to troubleshoot. In my experience, the best way to handle this is to have as much stuff pre-calculated on a previous frame, and make sure to optimize the top of your game loop (i.e., after calling WAIT) to do all it needs to do. Critical stuff are, in order:

1. MOB registers
2. Scroll registers
3. GRAM updates
4. Scroll screen shifts

The first two must be done at the tipity-top, there's no way around it; you need VBLANK 1 for that. The last two need to be coordinated so that your graphics and background can be updated adequately with minimal impact. Who has priority depends on your preference, but if there are not enough cycles to do both, you'll have to be aware that one will be affected.

 

-dZ.

 

 

P.S. To intvnut and other experts: I wrote the above from memory with the best of intentions to simplify the very technical aspects of the issue and help programmers deal with smooth scrolling. If I got something wrong or inaccurate, please let me know so that I can correct it.

Edited July 7, 2018 by DZ-Jay

[Kiwi]

• • VBLANK 2 - in which the CPU still has access to the graphics bus, but not to the STIC itself. We normally update GRAM here.

 

This is interesting. I guess my poke to the border register won't work here. I shouldn't worry too much about the scrolling lag now and the game still run ok enough. I gotta build the 2nd level, the cave.

 

The scroll code is right after the wait.

 

	WAIT
'	poke $2C,0
if scrolloffset=7 AND scrolltime=0 then gosub DrawStrip:treespawn=treespawn-1:#leveltime=#leveltime-1
if scrolltime=0 then scrolltime=scrollspeed:scrolloffset=scrolloffset-1: if scrolloffset=255 then move=2 :scrolloffset=7
if scrollon=1 then scrolltime=scrolltime-1
SCROLL scrolloffset,0,move
move=0	

 

 

1. MOB registers
2. Scroll registers
3. GRAM updates
4. Scroll screen shifts

Looking at the .list, intybasic handles that upon wait.

[+DZ-Jay]

Hmm... I think you got it reversed. I'll wait for nanochess to confirm, but my understanding is that (see UPDATE below) The SCROLL statement will buffer the scroll update until the next frame. I see that the "scroll.bas" example suggests this as well by performing the WAIT after the scroll statement:

REM >>>> Scroll to right
FOR time=1 to 240
	IF offset_x=0 THEN offset_d=2:offset_x=7 ELSE offset_x=offset_x-1
	SPRITE 0, 64 + VISIBLE + ZOOMX2 - offset_x, 48 + ZOOMY2 - offset_y, SPR02 + SPR_YELLOW
	SCROLL offset_x,offset_y,offset_d
	WAIT
	offset_d=0
	IF offset_x=7 THEN COL=19:GOSUB clear_column:PRINT AT RAND%BACKGROUND_ROWS*BACKGROUND_COLUMNS+19,"\257"
NEXT time

The idea is that, by the time WAIT is called (i.e., when the next VBLANK interrupt occurs), all the scrolling information is ready to go.

 

This is similar to all MOB information: remember, you are composing the next frame.

 

About the only thing that you need to check right after WAIT is collision and user input, which came from the previous interrupt, and are needed to update the game state for the next frame.

 

-dZ.

 

 

UPDATE: The IntyBASIC manual confirms that the SCROLL statement is buffered until the next frame.

Edited July 8, 2018 by DZ-Jay

[PuzZLeR]

Tough to beat.

[Kiwi]

Ok, I've finished level 2 and made sound effects for the game. The game goes through the 2 levels repeatly, increasing the difficulty(damage from enemies goes up), boss HP(the owl for sure I think) and the length of the forest in level 1, per loop.

I have parallax scrolling working. Similar how old 8-bit system back in the day did it.
Gifeo, had to trim it since the one I recorded was over 5 Megabytes.

ROM:Asparrow020.rom

The cave maze is probably too difficult. I did match the invincible timer to the Colecovision when you birddash. Good luck.

Future WIP:
Fire bird boss
2nd maze, Having the cave in different color is going to be more difficult than the Colecovision, which it has color table and pattern in seperate tables.

Adding idea that I had and had to cut Colecovision due to data constraint content:

Volcano level
snow level
Eagle boss
Seasonal forest

Small bird diving towards in the forest level

Not a bug: The max object on screen, beside the boss, is 5. So nothing will spawn until one of these object are destroyed.

Possibly multiplex object when there's more than 5... 15 16-bit variables are toward sprite attribute to avoid multication. Colecovision version was limited to 6 single color object, even though it has 32 sprites. It's due to Flappy bird side on the Colecovision cartridge version having only 12 sprites for the bird, and the score and it clone.

Enjoy.

Time for me to sleep.

Edited July 24, 2018 by Kiwi

[+DZ-Jay]

Hi, Kiwi,

 

The cave maze is very difficult, especially as a second level. However, I passed it twice (barely), arriving to the second boss only to die miserably. On my second run, I figured out the attack pattern of the boss, so I almost killed him. I'm sure with one more try I could, but I find the maze itself a bit frustrating.

 

Here's some additional feedback:

• The cave maze requires a little "learn-by-death," meaning that you have to die a few times in order to figure out that there is an optimal path (lower corridors), and there is a path (upper corridors) that is impossible.
• In some places, blockages and enemies are too close together that there is no time to recover from your last dash to use it again. This seems rather unfair, since there is no way around them, only through them.
• The scrolling needs work to make it smoother. It is jittery and sort of distracting. The Intellivision is capable of very smooth scrolling, so it may be something to strive for.
• The parallax scrolling is neat, but hard to notice due to the jittery nature of the background tiles during scrolling.
• The change of colour during the dash-recovery-period is still too subtle, and forces me to focus on the sparrow rather than on the other moving elements on the screen. Perhaps a repeating sound effect could help or a more distinct colour change or flash.
• Some of the sound effect appear to be mostly generic "pinball/video game" bleeps and bloops, and may go better with a space shooter than this sort of game. (I know sound effects are very hard to do! That's why someone else had to make the ones for my game... )
• That second boss, with his energy-field that arrests my sparrow's dash, is a killer! :o

 

Great job! I can't wait to see those other ideas you mentioned come to life.

 

-dZ.

[+DZ-Jay]

There's one more bit of feedback which I meant to give before. It applies to both levels.

 

I haven't played the ColecoVision version, so I do not know how the game is originally intended to be, but there is something in the game-play which seems a bit off to me: it is the orientation of the obstacles (apertures and corridors through which the sparrow must traverse), and the way that the sparrow goes through them.

 

The fact that the sparrow can go through walls and trees with only minimal health loss is to me an indication that the level is perhaps not entirely balanced for success without it. It feels like a work-around for the excessive difficulty of the path itself.

 

I personally would rather have impassable barriers with the difficulty applied judiciously on other elements, like a more balanced layout and aggressive (but fair) enemies. Perhaps with a bit of strategy thrown in.

 

As an example, I present my experience through the second level: like I mentioned in my previous post, I was able to complete the level twice and reach the boss; but I did it by just running through the entire level hitting almost every wall and going almost straight through and "dying" over and over. That felt less like a successful accomplishment and more like just stumbling my way through with no rhyme or reason. It's as if I had to plod through the level without much plan or strategy, hitting the "dash" key repeatedly (so that it activates whenever it is ready), just to reach the boss and get the real challenge.

 

I'm not saying that you need to make the level harder! :o God forbid, no!

 

I am just saying that the mechanic of going through the level without requiring a proper strategy, just muddling through, smashing dash repeatedly, losing health and gaining it back, and going blindly and almost mechanically, feels... well, a bit vapid and lifeless. This game seems to me like an exciting mash-up of Flappy Bird and a run-and-gun platformer like Metroid; but the Flappy Bird mechanic seems almost superfluous.

 

Just my thoughts, of course. Other's experience may vary.

 

-dZ.

Edited July 24, 2018 by DZ-Jay

[Kiwi]

 

Hi, carlsson,

Carlsson? Have he been possessing me to make this game the whole time?

 

The cave maze is very difficult, especially as a second level. However, I passed it twice (barely), arriving to the second boss only to die miserably. On my second run, I figured out the attack pattern of the boss, so I almost killed him. I'm sure with one more try I could, but I find the maze itself a bit frustrating.

The cave maze requires a little "learn-by-death," meaning that you have to die a few times in order to figure out that there is an optimal path (lower corridors), and there is a path (upper corridors) that is impossible.

In some places, blockages and enemies are too close together that there is no time to recover from your last dash to use it again. This seems rather unfair, since there is no way around them, only through them.

 

I will remove some obstacles. Like the double rocks. I had thoughts reducing the initial rest timer. I had to pass through the maze every time I have to see if the boss is working correctly.

Here's some additional feedback:

 

The scrolling needs work to make it smoother. It is jittery and sort of distracting. The Intellivision is capable of very smooth scrolling, so it may be something to strive for.

It's a little harder since I'm working in IntyBASIC and I can't really measure the cycle between waits. There's 5 other objects it have to process in the scene. So the block copy will be taking most of the cycle in the frame. In the other thread, I stated that I'm going to lose a frame no matter what in the block copy frame.

The parallax scrolling is neat, but hard to notice due to the jittery nature of the background tiles during scrolling.

The change of colour during the dash-recovery-period is still too subtle, and forces me to focus on the sparrow rather than on the other moving elements on the screen. Perhaps a repeating sound effect could help or a more distinct colour change or flash.

I did add sound cue when you're ready to dash.

Some of the sound effect appear to be mostly generic "pinball/video game" bleeps and bloops, and may go better with a space shooter than this sort of game. (I know sound effects are very hard to do! That's why someone else had to make the ones for my game... )

I'm leaving sound channel 0 and 1 for music since I'm planning to write music. Not really my favorite part of game making, but nanochess did a good job making the music player and used it for Mad Bomber.

That second boss, with his energy-field that arrests my sparrow's dash, is a killer! :o

Yup! The owl projectiles let you dash through while the bat sonic barrier halt your attack.

 

 

Great job! I can't wait to see those other ideas you mentioned come to life.

Thank you

-dZ.

 

The original game was you fighting the gravity by tapping the fire button like you do in Joust. I seen many video playing my game, they couldn't handle it. So I added other control method to just move the bird, and press the button. One thing when nanochess ported JETPAC, which was a flappy bird type of clone for the MSX, to the Colecovision. I can see the developer may have trouble keeping the guy out of the walls, because you can phase through the wall there. The issue I encounted doing the Colecovision may be similar is that it is difficult to tell if your player sprite is hitting the top of the impassible object or bottom or in front of it. Also I had to cram the game and the flappy bird game in one 32KB cartridge, so memory was a constraint. You can see the gif of it in the thread I linked in my original post. Scrolling was done differently on Colecovision since it has a enough video memory to double buffer screen data.

[+DZ-Jay]

Hi, carlsson,

Carlsson? Have he been possessing me to make this game the whole time?

 

 

OMG! Sorry, I just fixed it. I don't know what came over me there. Well, I guess all you programmers look the same to me (is that racist?).

 

 

 

The scrolling needs work to make it smoother. It is jittery and sort of distracting. The Intellivision is capable of very smooth scrolling, so it may be something to strive for.

It's a little harder since I'm working in IntyBASIC and I can't really measure the cycle between waits. There's 5 other objects it have to process in the scene. So the block copy will be taking most of the cycle in the frame. In the other thread, I stated that I'm going to lose a frame no matter what in the block copy frame.

 

I wonder if the trade-off could be moved to something else in a more practical way. For example, keep track of the speed of scrolling and be aware of the frame when the BACKTAB needs shifting, and avoid certain functions or reduce the game-state updates on that frame.

 

I don't know how you organized your game loop, but you'll probably have to create a pipeline that can be split conditionally.

 

One trick I use in my own game is to "stagger" animation frame-rates and displacement velocities on some objects, or their starting values, so that they never update on the same frame. If you are using fractional rates or velocities, it can be a bit complicated with some maths; but if you are just using integral frame counters, it shouldn't be too bad.

 

As a trivial example, consider two objects which animates at the same rate, every other frame. You can advance the counter on one of them at the start so that their updates do not coincide, having only one of them updated on every frame. The animations will be equally smooth, it is just happening at different moments.

 

It takes some careful planning and additional effort, but I think the results are worth it.

 

Of course, it may be too much of a short notice right now for the contest but I'm thinking for a future update, in case you are interested in furthering the polish of your game for a splashy eventual release. Personally, I do not see IntyBASIC as the limiting factor in this issue, and I think it's worth addressing (said the arm-chair quarterback programmer from the cozy comfort of his reclining laz-e-boy ).

 

-dZ.

[+nanochess]

Just I've made a video:

 

https://www.youtube.com/watch?v=LFOMRzzWIHg