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.
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.
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.
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.
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.
Well- this is a rather old thread! I got round to doing that test :P
(https://s5.gifyu.com/images/Raster_Test.gif)
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?
Quote from: sigh on 23:54, 28 January 20
Well- this is a rather old thread! I got round to doing that test :P
(https://s5.gifyu.com/images/Raster_Test.gif)
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)
I suggest you to test this software https://www.cpc-power.com/index.php?page=detail&num=5389 (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 :)
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.
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:
(https://i.postimg.cc/qBWkjDyH/Raster-Test-2.gif)
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):
(https://i.postimg.cc/v8pLvMm7/4-colours.gif)
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
waaaah, very nice!
i confirm it would be easy to program the raster in the sky
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.
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 ?
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.
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
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
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"
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! :-[
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!
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"
(https://i.postimg.cc/MKGdPD7q/Sna-test.gif)
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.
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
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.
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:
(https://i.postimg.cc/vH15j86X/Dither-Anim-Test.gif)
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:
(https://i.postimg.cc/Y2v3cz51/DITHER.gif)
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?
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)
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.
Quote from: roudoudou on 07:37, 31 January 20
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)
You are correct! I do try and create the animation as smooth a possible which can sometimes result in large sheets, then I have to start cutting back. The beat em up and the Football game are all designed for a 128kb machine, where I have had to be very meticulous in ensuring that the sprites are optimized as much as possible. This game however only has around 10 animations for the main sprite following:
IdleJumpSomersaultLand on Wall
flying through the air.HitBeing HitKO
Celebration
I will optimize so they don't, won't take much sprite space. The Idle - I may split this into body parts and animate a 5 frame cycle which will save lots of space, instead of displaying full frame.
Quote from: Axelay on 09:21, 31 January 20
...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.
What size would you recommend? Your right in that they are just a repeating pattern. I will follow your advice and use the dither masks.
Quote from: Axelay on 09:21, 31 January 20
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.
Cool. I'm going to fit everything into 2 sprite sheets as I don't think multiloading would work. I intend to optimize animations and effects to the best I can.
Quote from: Axelay on 09:21, 31 January 20
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.
Thankfully the game will only have that 1 background and no other (like Way Of The Exploding Fist/IK +). I'm going to post a gameplay animation.
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
Did you manage to get round to doing this? I'm thinking that it maybe easier to just stick with the 4 colours.
Quote from: sigh on 00:44, 02 February 20
Did you manage to get round to doing this? I'm thinking that it maybe easier to just stick with the 4 colours.
Sure, there was "nothing" to do as i said
https://rasmlive.amstrad.info/edit/eXZwEZmaPf8BqyKzZ (https://rasmlive.amstrad.info/edit/eXZwEZmaPf8BqyKzZ)
Quote from: roudoudou on 11:46, 02 February 20
Sure, there was "nothing" to do as i said
https://rasmlive.amstrad.info/edit/eXZwEZmaPf8BqyKzZ (https://rasmlive.amstrad.info/edit/eXZwEZmaPf8BqyKzZ)
Cool - thank you!
After some more testing with the special effects and rasters, it seems better if the raster is only used (in this case the deep yellow) in the sky so that the white dither special effect stands out. I did try dithering the sky with the pale yellow, but the white didn't show up well enough. So now the background is only 2 colours in each part, with the characters primary colours being the black and white so they stand out clear enough from the background during the action.
(https://i.postimg.cc/x8Jpsdr4/Demo3A.gif)
Good choice. It's amazing how often a cool sounding idea, that is technically feasible and seems to work well in static screenshots just sort of falls apart once you start doing real movement
Quote from: andycadley on 23:38, 04 February 20
Good choice. It's amazing how often a cool sounding idea, that is technically feasible and seems to work well in static screenshots just sort of falls apart once you start doing real movement
Thanks.
Yes - the sprites were getting lost in the detail of the background. I'm going to make the raster part of the sky either light blue or light green.
I will go for the green...
(https://i.postimg.cc/yNgKXX2R/Raster-Colours.gif)
...and then do something like this by deleting some of the green to form clouds.
(https://i.postimg.cc/3wnGm75N/Raster-Clouds.gif)
I will do this properly tomorrow and that should be the background finished.
Here is the final background, but the cloud patterns have complicated the rasters as it has now affected the sprites.
Due to the cloud patterns, I have had to account for colour clash for where the green clouds will be as it is the only way to pixel the clouds blending smoothly into the sky. The characters white detail will change into the pale yellow around the clouds.What I think needs to happen are that the ink arrangements at this point, needs to have a natural colour clash to appear on the white parts of the character. But that natural clash needs to be yellow and not green.
(https://i.postimg.cc/NFTWBfqF/Raster-Final.gif)
If the cloud patterns are making things too complicated then they will have to be removed. Here are example with the existing four colours:
(https://i.postimg.cc/T2qDdKnX/Raster-Final-3.gif)
(https://i.postimg.cc/L62jLtmX/Raster-Final-2.gif)
The white clouds are to harsh on the eyes.The black clouds could be a little distracting.The orange clouds could work if I change some of the dithering. Otherwise I will just remove the clouds altogether and leave the sky plain.
Nice new animated-gif "project". What about the football and beat them up games started in April 2012?
Quote from: TotO on 17:38, 06 February 20
Nice new animated-gif "project". What about the football and beat them up games started in April 2012?
Football is done (all sprites animated) but needs a programmer. There isn't much else I can do for that apart from the menu screen.
The beat em up is still going and I was working on level 3 backgrounds early January. I find that it helps to have 2 game projects running side by side as I can get burn out if I just focus on one.However this time, I'm not making the same mistake with the football project - that project was very intense with the amount of animation going on. This project is tiny compared to those and only needs 2 or 3 more drawings for the main sprite and that is all the character art done. Then; I just need to animate the special effects and grab some fonts.
I'm really amazed that no programmer was involved since years for those amazing projects.
Quote from: TotO on 19:18, 06 February 20
I'm really amazed that no programmer was involved since years for those amazing projects.
Arnoldemu is working on the beat em up project. :)
The backgrounds and level designs is the real brain cruncher for me. The first 4 screens of any of these levels are extremely challenging as I am constantly having to optimize the tiles - only to have "re-optimize them again" in order that they can be used elsewhere. Altering just 1 pixel can really make a difference whether that tile can be re-used or not to save space while being interesting enough to give variety to the level. Animating the characters was a much easier task.
The football game is a nightmare for a programmer due to ball physics, AI for team awareness of 22 players on field, goal keeper AI to balance how good they are and also the scrolling; so finding a programmer for this will be difficult. There are also a lot of animations.
This game however, has none of the above :D . This is a very small project and it's also the first mode 1 game that I have designed. There is no level design, no scrolling, no hud, no joystick control as it is only the fire button that is used and there are only a handful of animations.
Just 3 more poses to do (will do that on sunday as tomorrow I am sketching out the rest of level 3 for the beat em up), then next week I will do the special effects. I will post a full gameplay demo soon in the "games" section. Hopefully a programmer will be interested to take this one on.
Quote from: sigh on 01:33, 07 February 20
The football game is a nightmare for a programmer due to ball physics, AI for team awareness of 22 players on field, goal keeper AI to balance how good they are and also the scrolling; so finding a programmer for this will be difficult. There are also a lot of animations.
I totally agree with this :laugh:
Quote from: sigh on 01:33, 07 February 20
Arnoldemu is working on the beat em up project. :)
The backgrounds and level designs is the real brain cruncher for me. The first 4 screens of any of these levels are extremely challenging as I am constantly having to optimize the tiles - only to have "re-optimize them again" in order that they can be used elsewhere. Altering just 1 pixel can really make a difference whether that tile can be re-used or not to save space while being interesting enough to give variety to the level. Animating the characters was a much easier task.
128K floppy game? Why not a ROM game?
Quote from: TotO on 11:32, 07 February 20
128K floppy game? Why not a ROM game?
To be honest, I do need to learn how to be more resourceful and not go overboard with my ideas, so I think that at this stage, I should learn to work within a set limitation before creating a rom game.
However - nothing is set in stone until we get the first level playable, so that could all change depending on what Arnoldemu is able to do, or if he needs me to cutdown/change things.
On the CPC WIKI, I noticed that it mentioned a "Mode 5" which makes "which makes heavy use of Rasters and Split Rasters in order to enable far more colours in the normal Mode1."
Where can I find examples of this?
There is no spoon mode. ;D
Try to Keep 4 colors max Every 16 pixels
Do color change every 64 pixels on the same ink ( or more pixels by 16 step)
Thats all folks
Will be easy if there is less than 6 color changes per line
Ah okay. So not a mode; because I was about to ask what happened to "mode 4" ;D
Thanks!