Smooth movement in Basic for CPC

Started by bluestar, Yesterday at 14:38

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

bluestar

Hi everybody,

Sorry if this is a recurrent subject but I wasn't able to find a similar post in the forum.

After 37 years of got my CPC 472 I'm now learning how to code games for Amstrad. I'm a programmer so coding itself is not a problem for me.

Currently I've the idea of develop a couple of games in Basic, and then move to a framework like CPCtelera and use C and assembly code. Just for fun.

Anyway... I've created a prototype of Oh Mummy! in Basic wich works quite fine and now I'm trying to improve some parts of the program. One is the movement of course. I'm using a 16x16 character but it blinks too much when moving.

I've tested different variations in order to improve results but there is no much difference (adding FRAME instruction, playing with transparent colors, using TAG/TAGOFF, erasing just a part of the track, etc.). Best way currently is deleting and drawing at the same PRINT instruction (a different PRINT instruction is call based on player direction with empty characters in the previous position).

Nevertheless... Is there any particular trick/procedure using pure Basic to get an acceptable smooth movement? Other solution adding machine code to Basic?

I know I'll getting better results with other languages but the idea is develop an acceptabale game and then code the same game in C in order to compare.

Thanks in advance (and excuse my English).

andycadley

I think you've probably tried most of them, at some point BASIC just isn't great for this kind of thing.

Probably the only other option left is to handle screen updates by palette switching so you can draw to the screen without it being visible, and make the change near instantaneous. It's similar to the colour plane techniques described in the manual.

It's all to do with bitwise operations and careful arrangement of the palette, it easiest to describe in Mode 1 but the principle applies to Mode 0 too. Because of the way it works, it does limit the number of colours on screen however.

Start with a screen entirely in PEN 0, which will be our background colour. Draw something on the screen using PEN 1 using an OR operation, it'll all appear in PEN 1. So far, so simple. Now draw something over the top of it using OR and PEN 2. Every pixel that was in both drawings will end up in PEN 3, the others will either be 1 or 2 depending on which drawing they were part of.

Now the clever bit, change the palette entries as follows:

0 - background colour
1 - foreground colour
2 - background colour
3 - foreground colour

And the second drawing will mysteriously disappear, even though the pixels are still in place. Change the palette to:

0 - background colour
1 - background colour
2 - foreground colour 
3 - foreground colour

And the second image instantly replaces the first. What's more if you draw the first image again, only this time using an AND operation and PEN 2, all of the pixels that were set to PEN 1 will become PEN 0 and all those in PEN 3 become PEN 2, effectively erasing the background image ready to start over.

By cycling between drawing in PEN 1 &2 like this, switching palette each time you've finished you can get almost instant updates to the screen. But you have sacrificed the colour depth to just 2 colours in Mode 1 (or 8 in Mode 0)

Sykobee (Briggsy)

I think you are finding out why sprite RSXes were common :)

In terms of BASIC RSXes used today there is the 8BP library that might be enough to solve your BASIC issues, and I think it has a C/asm version too which would help later on. It does have its limitations (I haven't used it however). Sprites Alive! and Laser Basic were other solutions back in the day.

TAG is a very slow way to get multicoloured pixel-perfect sprites.

bluestar

Quote from: andycadley on Yesterday at 15:56I think you've probably tried most of them, at some point BASIC just isn't great for this kind of thing.

Probably the only other option left is to handle screen updates by palette switching so you can draw to the screen without it being visible, and make the change near instantaneous. It's similar to the colour plane techniques described in the manual.

It's all to do with bitwise operations and careful arrangement of the palette, it easiest to describe in Mode 1 but the principle applies to Mode 0 too. Because of the way it works, it does limit the number of colours on screen however.

Start with a screen entirely in PEN 0, which will be our background colour. Draw something on the screen using PEN 1 using an OR operation, it'll all appear in PEN 1. So far, so simple. Now draw something over the top of it using OR and PEN 2. Every pixel that was in both drawings will end up in PEN 3, the others will either be 1 or 2 depending on which drawing they were part of.

Now the clever bit, change the palette entries as follows:

0 - background colour
1 - foreground colour
2 - background colour
3 - foreground colour

And the second drawing will mysteriously disappear, even though the pixels are still in place. Change the palette to:

0 - background colour
1 - background colour
2 - foreground colour
3 - foreground colour

And the second image instantly replaces the first. What's more if you draw the first image again, only this time using an AND operation and PEN 2, all of the pixels that were set to PEN 1 will become PEN 0 and all those in PEN 3 become PEN 2, effectively erasing the background image ready to start over.

By cycling between drawing in PEN 1 &2 like this, switching palette each time you've finished you can get almost instant updates to the screen. But you have sacrificed the colour depth to just 2 colours in Mode 1 (or 8 in Mode 0)
Thanks! I'll try this method. Colour depth is a problem as I'm working in Mode 1 but is fine with a GT65 monitor... :) I'll code a test and maybe I'll consider develop a 2 colours version of the game at the end. 

Thanks again.

bluestar

Quote from: Sykobee (Briggsy) on Yesterday at 16:06I think you are finding out why sprite RSXes were common :)

In terms of BASIC RSXes used today there is the 8BP library that might be enough to solve your BASIC issues, and I think it has a C/asm version too which would help later on. It does have its limitations (I haven't used it however). Sprites Alive! and Laser Basic were other solutions back in the day.

TAG is a very slow way to get multicoloured pixel-perfect sprites.

RSX: another item for the TODO list  :laugh: Looks like i'm gonna make different versions of the game with different techniques. I'm 40 years late almost   :picard2:

Sykobee (Briggsy)

I remember many more advanced ACU game listings would have some form of sprite code embedded in DATA statements at the end, poked into memory, and either CALLed or RSXed for use from BASIC, with all the sprite data also encoded in more DATA statements.

(obviously some  (e.g., Space Mania) where literally BASIC loaders for DATA statements, with game logic also encoded, which wasn't what I call a BASIC game!)

Powered by SMFPacks Menu Editor Mod