News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu

Rasters in CPC

Started by sigh, 17:15, 18 April 11

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

sigh

I'm not to sure whether this question should be in the games or programming section of the forum, but I've only recently been looking at rasters while researching on mode 1 and mode 2.

What I would like to know is how many times can the CPC split the screen comfortably with out slowdown within the game area (not the hud). Striker in the Crypts of Trogan seems to have 2 splits in the game area:

Sky
Foreground area with the sprite.

For instance - is it possible to have 3 or 4 splits which would enable 8 colours in mode 1 or 4 mode 2? Are there any other examples apart from Stryker, Thundercats and The living daylights? I can't help feel that there is so much more that can be done graphically with this technique.

arnoldemu

Quote from: sigh on 17:15, 18 April 11
I'm not to sure whether this question should be in the games or programming section of the forum, but I've only recently been looking at rasters while researching on mode 1 and mode 2.

What I would like to know is how many times can the CPC split the screen comfortably with out slowdown within the game area (not the hud). Striker in the Crypts of Trogan seems to have 2 splits in the game area:

Sky
Foreground area with the sprite.

For instance - is it possible to have 3 or 4 splits which would enable 8 colours in mode 1 or 4 mode 2? Are there any other examples apart from Stryker, Thundercats and The living daylights? I can't help feel that there is so much more that can be done graphically with this technique.


Remember my test program that showed where the interrupts were?
Well there is the potential to change the palette at each point (when each interrupt is triggered), so you could change all 4 colours each interrupt.

This will take a little bit of time but not a lot.

EDIT: If you want it at other times, you have to use cpu time to wait to that point, then this takes away from the time for a game.
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

sigh

So you can change the palette colours as well as add colours. Adding colours doesn't have any waiting time, but changing colours does.

I think I'll draw an example pic and to see if what I have in mind is possible or not.

Executioner

Quote from: arnoldemu on 17:43, 18 April 11
EDIT: If you want it at other times, you have to use cpu time to wait to that point, then this takes away from the time for a game.

That depends on whether the waiting is just waiting and not doing something that takes a set amount of time like drawing a scrolled section or the score characters or sprites or other calculations.

sigh

As a test I plan to have a 320 x 200 mode 1 screen, split into 4 sections. The top will have a skyline with unique colours (4 dithered blues). The section below that will have a three colour sprite and one of the blues from the sky. The next section will have the three colour sprite and a colour for the ground. The last section will have the colour from the ground plus 3 new colours.

sigh

Well- this is a rather old thread! I got round to doing that test :P



This test shows a Mode 1 screen with a 3 colour sprite travelling through 4 sets of colours, with one of the background colours being the same as the sprite (black).
When the sprite travels through the blue to the green - what would happen in this situation? Would the top of the sprite turn green as it enters?

roudoudou

Quote from: sigh on 23:54, 28 January 20
Well- this is a rather old thread! I got round to doing that test :P



This test shows a Mode 1 screen with a 3 colour sprite travelling through 4 sets of colours, with one of the background colours being the same as the sprite (black).
When the sprite travels through the blue to the green - what would happen in this situation? Would the top of the sprite turn green as it enters?
Mode 1 has 4 color right?
Assuming background is color index 0 and your sprite color indexes 1,2,3, you may change the background color anytime without changing the colors of the sprite :)
In this case there will be two black inks at the bottom of the screen (idx 0 and one idx of the sprite)
My pronouns are RASM and ACE

roudoudou

I suggest you to test this software https://www.cpc-power.com/index.php?page=detail&num=5389
There is some RSX to change colors in basic, the screen is splitted in 4 zones

; set color changes index 0 four times on the screen

|INK,1,0,1 : |INK,2,0,2 : |INK,3,0,11 : |INK,4,0,23
Then you may try to move a sprite using index 1,2,3 on the screen :)


My pronouns are RASM and ACE

andycadley

It's better to think in terms of palette entries rather than actual colours. At any one time, you can always have multiple palette entries reference the same colour.


Since the stripes in the background never share the same scan line, they can all be using the same palette entry (which is traditionally 0, but doesn't have to be). That leaves the three other palette entries free for use on the sprite. Since those colours aren't changed anywhere on the screen, the sprite will appear unaffected by the palette swap.


It only becomes an issue if you change palette entries that are used by your sprite, at which point the colour will depend upon where the sprite is. Sometimes you can design out this issue, the most obvious example being changing the palette entries by a status panel your sprite will never be displayed over but some games can be zoned off in cunning ways too.

sigh

Quote from: roudoudou on 08:15, 29 January 20
Mode 1 has 4 color right?
Assuming background is color index 0 and your sprite color indexes 1,2,3, you may change the background color anytime without changing the colors of the sprite :)
In this case there will be two black inks at the bottom of the screen (idx 0 and one idx of the sprite)
Yes - mode 1 has 4 colours. (320x200). I have another test/exampple:



Quote from: andycadley on 08:30, 29 January 20
Since the stripes in the background never share the same scan line, they can all be using the same palette entry (which is traditionally 0, but doesn't have to be). That leaves the three other palette entries free for use on the sprite. Since those colours aren't changed anywhere on the screen, the sprite will appear unaffected by the palette swap.

It only becomes an issue if you change palette entries that are used by your sprite, at which point the colour will depend upon where the sprite is.
With the example shown above, I have divided the screen into 3 sections that each have a different background colour. The sprites have 3 colours and share the same palette and those colours appear in the background too. Please bare in my mind that the picture isn't finished yet as I still have a few more bits to draw:D

Would this pass the test? Or would it be a programming nightmare? I also have this simple verion that is 4 colours all the way through (unfinished):



The reason I'm doing this is that I'm back working on the beat em up again which is quite complicated graphically, so I usually have another CPC related project on the side to take a break with. That originally was the football game, but I have drawn and animated everything for that, apart from the menu and title screen. So I'm creating a simple "VS" fighting game that only uses "1" button to control the character. There are no joystick controls - just 1 button (fire button).

A nice short, easy and gentle project - art and animation wise :D

roudoudou

waaaah, very nice!
i confirm it would be easy to program the raster in the sky
My pronouns are RASM and ACE

sigh

Quote from: roudoudou on 15:47, 29 January 20
waaaah, very nice!
i confirm it would be easy to program the raster in the sky
Thank you.
What about the grey coloured ground? This is a single screen game and there is no scrolling. There is no hud/score panel either. As you can see, the timer is on the building.

roudoudou

Quote from: sigh on 16:34, 29 January 20
Thank you.
What about the grey coloured ground? This is a single screen game and there is no scrolling. There is no hud/score panel either. As you can see, the timer is on the building.


Nothing special. You will loose some time with rasters. Do you want a prof of concept ?
My pronouns are RASM and ACE

sigh

#13
Quote from: roudoudou on 17:37, 29 January 20

Nothing special. You will loose some time with rasters. Do you want a prof of concept ?
Yes please!!! That would be great!

With the ground - is that not the same method that would be used for the sky too? I have heard about "losing" time and I assume that this is in reference to when the grey background would swap inks to the white and green? Is that time loss noticeable?
I have been watching "Stryker in the Crypts of Trogan" but that has scrolling. I have noticed that when the orbs fall out from the purple sky, the orbs them self are purple coloured, but then turn green when they ht the ground, because that particular section has a green ink for the grass. So the Green Ink and Purple Ink are sharing the same entry.

roudoudou

Quote from: sigh on 17:53, 29 January 20
Yes please!!! That would be great!

With the ground - is that not the same method that would be used for the sky too? I have heard about "losing" time and I assume that this is in reference to when the grey background would swap inks to the white and green? Is that time loss noticeable?
I have been watching "Stryker in the Crypts of Trogan" but that has scrolling. I have noticed that when the orbs fall out from the purple sky, the orbs them self are purple coloured, but then turn green when they ht the ground, because that particular section has a green ink for the grass. So the Green Ink and Purple Ink are sharing the same entry.
Do not worry, without scrolling, there is enough potential CPU time left to move 2 sprites at 50Hz  ;D
My pronouns are RASM and ACE

roudoudou

#15
Here is the POC
I must wait 640 nops on 20.000 before switching to grey so i lose 3.2% of CPU time because...
because interrupts are 52 lines spaced so if you want to lose almost nothing, you need to modify the GFX
My pronouns are RASM and ACE

roudoudou

source code is very light  ;D
buildsna
bankset 0

run #1000
org #1000
di
ld hl,#C9FB
ld (#38),hl
ei

ld bc,#7F01 : out (c),c : ld a,64+14 : out (c),a : inc c
ld bc,#7F02 : out (c),c : ld a,64+3  : out (c),a : inc c
ld bc,#7F03 : out (c),c : ld a,64+20 : out (c),a

ld bc,#BC00+7 : out (c),c : ld bc,#BD00+31 : out (c),c

ld b,#F5
vbl in a,(c)
rra
jr nc,vbl

rastaloop
halt
halt
ld bc,#7F00 : out (c),c : ld a,64+25 : out (c),a : inc c
halt
ld b,10 : djnz $
ld bc,#7F00 : out (c),c : ld a,64+11 : out (c),a : inc c
halt
halt
ld b,128+32 : djnz $
ld bc,#7F00 : out (c),c : ld a,64+0  : out (c),a : inc c
halt

jr rastaloop

org #C000
incbin "sigh_test.bin"

My pronouns are RASM and ACE

sigh

Quote from: roudoudou on 20:26, 29 January 20
Here is the POC
I must wait 640 nops on 20.000 before switching to grey so i lose 3.2% of CPU time because...
because interrupts are 52 lines spaced so if you want to lose almost nothing, you need to modify the GFX
Thank you!
Erm...how do I run this file? Sorry! :-[

sigh

Quote from: sigh on 23:39, 29 January 20
Thank you!
Erm...how do I run this file? Sorry! :-[
Never mind - I got it working!
Thanks!

sigh

Quote from: roudoudou on 20:27, 29 January 20
source code is very light  ;D
buildsna
bankset 0

run #1000
org #1000
di
ld hl,#C9FB
ld (#38),hl
ei

ld bc,#7F01 : out (c),c : ld a,64+14 : out (c),a : inc c
ld bc,#7F02 : out (c),c : ld a,64+3  : out (c),a : inc c
ld bc,#7F03 : out (c),c : ld a,64+20 : out (c),a

ld bc,#BC00+7 : out (c),c : ld bc,#BD00+31 : out (c),c

ld b,#F5
vbl in a,(c)
rra
jr nc,vbl

rastaloop
halt
halt
ld bc,#7F00 : out (c),c : ld a,64+25 : out (c),a : inc c
halt
ld b,10 : djnz $
ld bc,#7F00 : out (c),c : ld a,64+11 : out (c),a : inc c
halt
halt
ld b,128+32 : djnz $
ld bc,#7F00 : out (c),c : ld a,64+0  : out (c),a : inc c
halt

jr rastaloop

org #C000
incbin "sigh_test.bin"


Thank you very much for taking you time to test.
If I were to try and get it down to lose almost nothing - what graphical modification would I need?

If it's tricky, programming wise, then I will stick with the normal 4 colour version.



roudoudou

I realise i Can move up Again the screen by one char. Doing this the Small loss will become 0.5% so do not modify the screen yet. Will do this tonight
My pronouns are RASM and ACE

andycadley

Quote from: sigh on 23:51, 29 January 20
If I were to try and get it down to lose almost nothing - what graphical modification would I need?

If it's tricky, programming wise, then I will stick with the normal 4 colour version.


The way to get it down to almost nothing is to design the colour change points to happen where the standard gate array interrupts occur on the monitor. Or code for the Plus machines which have much more flexible interrupt capabilities.


That said, and as others have alluded to,  you may not need to. Often the "delay" code can be replaced by some other constant time operation that you were going to have to do anyway, in which case you get it for free. Or your code ends up with some free time on a frame anyway and you'd just end up waiting for a frame flyback instead.

sigh

Quote from: roudoudou on 06:29, 30 January 20
I realise i Can move up Again the screen by one char. Doing this the Small loss will become 0.5% so do not modify the screen yet. Will do this tonight
Thank you!
Quote from: andycadley on 08:47, 30 January 20
That said, and as others have alluded to,  you may not need to. Often the "delay" code can be replaced by some other constant time operation that you were going to have to do anyway, in which case you get it for free. Or your code ends up with some free time on a frame anyway and you'd just end up waiting for a frame flyback instead.
One thing I just realised in the pictures I sent, is that I forgot to take in consideration the "transparency" for the sprites that also act as a colour. I have been toying with some special effects using dither patterns, but the problem is that the effects take a lot of space. Here is an example on a 320 x 200 sprite sheet:


As you can see - that is a lot of sprite space! Ideally - I think it would be better to have a dithered transparency overlay on just one smoke cycle like this:


You would take the dither pattern and lay it on top instead. This save a lot of space but I'm not sure if this is the correct method to take. This is the largest effect in the game. There are 3 more effects that are not as large at around 5 frame each.
1) How much kb for a mode 1 320 x 200 sprite sheet? I would like this game to fit in 64kb if possible. Ideally - I would need around 4 of these sheets.
2) The background is just one picture so I'm guessing that it would not need to be separated into tiles?3) Would a game like this need double buffering?

roudoudou

i notice (that's not the first time, i saw the other thread with fighters) you like to push MANY pixels, you should consider a ROM game (for Dandanator, XMEM or Playcity) if it's not against your religion
As far as i know, existing ROM hardware offer up to 512K of code/data and let software run on all CPC (dealing with 64K+double buffering is a lot easier with many ROMs)
My pronouns are RASM and ACE

Axelay

Quote from: sigh on 00:20, 31 January 20
You would take the dither pattern and lay it on top instead. This save a lot of space but I'm not sure if this is the correct method to take. This is the largest effect in the game. There are 3 more effects that are not as large at around 5 frame each.

That's how I'd handle it if was looking to save memory, though the dither masks themselves don't appear to be required at those sizes, they look to be repeating patterns of 4x4 pixels, just 4 bytes per pattern, so wouldn't take much space at all in that case.


Quote from: sigh on 00:20, 31 January 20
1) How much kb for a mode 1 320 x 200 sprite sheet? I would like this game to fit in 64kb if possible. Ideally - I would need around 4 of these sheets.

A full default sized CPC screen is 16kb in any mode, so those 4 sprite sheets would come to 64kb.  But if multiload works for your design, it might work in 64kb.

Quote from: sigh on 00:20, 31 January 20

2) The background is just one picture so I'm guessing that it would not need to be separated into tiles?3) Would a game like this need double buffering?
Storing the background as tiles and double buffering depends on how the coder might handle your requirements, you'd need to specify what you're trying to achieve so they could work out an approach - simultaneous sprite count & their size, frame rate you'd like to aim for & how stable that is, things like that.  The higher the requirements, the more likely double buffering may be necessary.

Powered by SMFPacks Menu Editor Mod