News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Joseman

Astonishing and enigmatic pics from BatmanGroup!!

Started by Joseman, 20:27, 12 June 17

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

Rhino

Hi!
Since there were some people interested in the source code of this demo, here it is.
The comments and documentation are in Spanish, sorry.
The current implementation has many optimizable parts, some of them are commented in the code itself.
The music player is the Arkos Player 2 converted to Maxam.
The music in the demo is Smoke from FenyxKell included in the Arkos Tracker 2 examples.
It would be great if this helps someone to make a full game! since BG does not currently plan to use it.

fano

Quote from: Rhino on 19:30, 20 December 18
Hi!
Since there were some people interested in the source code of this demo, here it is.
The comments and documentation are in Spanish, sorry.
The current implementation has many optimizable parts, some of them are commented in the code itself.
The music player is the Arkos Player 2 converted to Maxam.
The music in the demo is Smoke from FenyxKell included in the Arkos Tracker 2 examples.
It would be great if this helps someone to make a full game! since BG does not currently plan to use it.
Thanks a lot, i just take a quick look to the code but it is a great job.Just a little question, why did you decided to use 4 colors background with rasters, just a way to save space, improve collisions or a way for optimisation ?
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Rhino

Quote from: fano on 19:32, 21 December 18
Thanks a lot, i just take a quick look to the code but it is a great job.Just a little question, why did you decided to use 4 colors background with rasters, just a way to save space, improve collisions or a way for optimisation ?
Thanks! Is the way it get pixel precision in the scroll.

fano

Quote from: Rhino on 20:56, 21 December 18
Thanks! Is the way it get pixel precision in the scroll.
Nice! thank you, i understand well now, clever trick ;)
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

rexbeng

#104
Well, since you guys brought this discussion into attention again; I have to say, I don't see much difference in Rhino's method in comparison to what I've worked with when making Relentless back in 2013.

Ofcourse this is an opinion on whatever practical assumptions I can make from what I've read and seen in this thread, based on my personal experience as a games' pixeler. I am no coder so I really cannot judge pieces of code posted.

But anyway, I have been wondering; is there differences to be pointed out?

fano

Quote from: rexbeng on 15:56, 22 December 18
Well, since you guys brought this discussion into attention again; I have to say, I don't see much difference in Rhino's method in comparison to what I've worked with when making Relentless back in 2013.

Ofcourse this is an opinion on whatever practical assumptions I can make from what I've read and seen in this thread, based on my personal experience as a games' pixeler. I am no coder so I really cannot judge pieces of code posted.

But anyway, I have been wondering; is there differences to be pointed out?
As i understood, both use R3 approach to provide byte scrolling but there are differents for pixel scrolling.Relentless uses shifted double buffer where Rhino uses palette combinaisons to get pixel scrolling.On other side, Axelay used dual playfield to get fast masked sprites, that limits sprites to 3 colors and background to 4 where Rhino uses 'classical' sprites that can use up to 7 differents colors (4 sprites + black outline + 2 background colors (light and dark)) and background can use 4 colors (color 0+black outline shared with sprites+2 colors (dark and bright)).Both use raster approach in order to get more colors on background.
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Rhino

Quote from: rexbeng on 15:56, 22 December 18
Well, since you guys brought this discussion into attention again; I have to say, I don't see much difference in Rhino's method in comparison to what I've worked with when making Relentless back in 2013.

Ofcourse this is an opinion on whatever practical assumptions I can make from what I've read and seen in this thread, based on my personal experience as a games' pixeler. I am no coder so I really cannot judge pieces of code posted.

But anyway, I have been wondering; is there differences to be pointed out?
Hi rexbeng,

I haven't looked Relentless in depth, but I've always thought it's the way fano described it (maybe Axelay can give us more details). In practical terms, the main difference of both methods would be that the Relentless scroll is unidirectional and at constant speed, while this is multiderectional (left/right) and multispeed (Mario inertia).

jesusdelmas

Quote from: Rhino on 21:30, 22 December 18
Hi rexbeng,

I haven't looked Relentless in depth, but I've always thought it's the way fano described it (maybe Axelay can give us more details). In practical terms, the main difference of both methods would be that the Relentless scroll is unidirectional and at constant speed, while this is multiderectional (left/right) and multispeed (Mario inertia).


Yes i see that diference too, it is possible to get real 50fps?? really? :o

rexbeng

#108
Thank you for the explanations people. I see how the different natures between the two games are the decisive factors for the way the scrolling and sprite techniques are implemented. So I guess it's related to Overflow's Shadow of the Beast demo from 1995, but with the graphical & technical sides narrowed down to make room for sprites etc.

From the designer's perspective though, I'm seeing that, much like the case with Relentless, there have also been set a number of limitations. 8 colours are sacrificed to achieve the 1 pixel offset, so in reality the actual visible colours on screen are just 8. The background graphics can only have up to 4 of those, while the remaining 4 colours can only be used on the sprites. The sprites can additionally use 3 of the background colours. Those facts alone present a challenge to the designer, who will need to base most of his sprites on those unique 4 colours that are not used on the background graphics (so that sprites stand out) and from then on make whatever best use of the common 3 colours.
The fact that the Mario demo uses rasters (splits the screen to different horizontal raster-zones) to change two of the background colours, complicate things in the sense that, if the designer wishes to use the 2 background colours on sprites, he must make sure that those particular sprites do not move between raster-zones, else their colours are going to be changing.
So, in reality, there's three possible approaches I can think of.

First is, you dont use rasters and just have 4 background colours, and 4+3 colours for sprites that move without restrictions around the screen.

Second, you have 4 background colours that are bumped up by the use of rasters, and 4+1 colours for sprites that move without restrictions (which is more or less a case like you see in Relentless).
Third is the method presented in the Mario demo. You use rasters but restrict the movement of sprites that use 4+3 colours within their respective colour zones, while sprites that freely move around can only have 4+1 colours (the mario sprite in this example).

So, while interesting and challenging this method, it is clear that what someone may build with this would by no means be an unrestricted full coloured game as some people might got lead to believe. The choice of Mario to show this off is a clever choice because this game is not very graphically demanding. That said, it would be interesting to see how this method could be exploited to make an actual game where factors like enemy AI, level building and gameplay come into play.
But don't make Mario FFS, it's been done to death!

andycadley

It's not uncommon for 8-bit game engines to have all sorts of restrictions on size, placement, colours etc - probably more than artists would like but such are the limits of old hardware. The restrictions here don't seem particularly onerous and could probably be put to great use.

Rhino

Quote from: rexbeng on 11:38, 23 December 18
Thank you for the explanations people. I see how the different natures between the two games are the decisive factors for the way the scrolling and sprite techniques are implemented. So I guess it's related to Overflow's Shadow of the Beast demo from 1995, but with the graphical & technical sides narrowed down to make room for sprites etc.

From the designer's perspective though, I'm seeing that, much like the case with Relentless, there have also been set a number of limitations. 8 colours are sacrificed to achieve the 1 pixel offset, so in reality the actual visible colours on screen are just 8. The background graphics can only have up to 4 of those, while the remaining 4 colours can only be used on the sprites. The sprites can additionally use 3 of the background colours. Those facts alone present a challenge to the designer, who will need to base most of his sprites on those unique 4 colours that are not used on the background graphics (so that sprites stand out) and from then on make whatever best use of the common 3 colours.
The fact that the Mario demo uses rasters (splits the screen to different horizontal raster-zones) to change two of the background colours, complicate things in the sense that, if the designer wishes to use the 2 background colours on sprites, he must make sure that those particular sprites do not move between raster-zones, else their colours are going to be changing.
So, in reality, there's three possible approaches I can think of.

First is, you dont use rasters and just have 4 background colours, and 4+3 colours for sprites that move without restrictions around the screen.

Second, you have 4 background colours that are bumped up by the use of rasters, and 4+1 colours for sprites that move without restrictions (which is more or less a case like you see in Relentless).
Third is the method presented in the Mario demo. You use rasters but restrict the movement of sprites that use 4+3 colours within their respective colour zones, while sprites that freely move around can only have 4+1 colours (the mario sprite in this example).

So, while interesting and challenging this method, it is clear that what someone may build with this would by no means be an unrestricted full coloured game as some people might got lead to believe. The choice of Mario to show this off is a clever choice because this game is not very graphically demanding. That said, it would be interesting to see how this method could be exploited to make an actual game where factors like enemy AI, level building and gameplay come into play.
But don't make Mario FFS, it's been done to death!

As Andycadley said, from a global point of view, the free use of 16 colors for all things in CPC is something uncommon in 8-bit machines, most of the other platforms usually have this type of limitations for sprites, backgrounds, etc ... So, in this proposal, one of Amstrad's strong points (colours usage freedom) is sacrificed to achieve one of the weaknesses of the CPC (fast pixel-precise multidirectional scroll) and thanks to the rasters, I think a final result can be achieved in which these limitations are difficult to perceive, but, as you say, the design of the game itself is conditioned by these limitations. To make things a little easier, I've included a tool to convert 4-color graphics to the format used in the engine.
On the other hand, the use of palette changes to obtain 1 pixel displacements is not a new idea, maybe the only new thing is the combination with rasters so that the total number of colors and overall result is what everyone would expect from our colorful CPC.

In any case, if someone wants to give up pixel precision and use byte precision to have 16 totally free colors, it is quite simple to do from this same code, as well as add vertical scroll to make a game with movement in all directions.

andycadley


I'd go further than that. Even on machines which have hardware limitations around colour placement etc, such as the C64 and Spectrum, game engines often placed additional restrictions about what can be done that ultimately impact on the artwork in ways that may not be entirely obvious.


For example, the much applauded Cobra on the Spectrum uses a very clever PUSH scroll technique to update the background very quickly - however this severely limits what the background can look like, with limits on how many different tiles can be on a line and certain background items being limited to less than 8 pixels wide in order to fake the effect of more tiles than would otherwise be possible, making the background appear less repetitive than it otherwise would with such a routine.


If you dig deep enough into many 8-bit games you'll find all sorts of weird tricks used to squeeze an extra ounce of performance out of a system and often they come at the expensive of full flexibility with graphical appearance.

Rhino

Quote from: jesusdelmas on 00:12, 23 December 18

Yes i see that diference too, it is possible to get real 50fps?? really? :o

Because the scroll does not require CPU, the main task that will determine the fps are the drawing/clearing sprites routine, in this example a general purpose routine is used, it is not specially optimized, and you could get more CPU free with compiled sprites for example. All of this also has its impact on memory, so it also depends on whether you are going to make a 64 or 128kb game.
On the other hand, a Mario-type game doesn't require major math calculations or AI, so I think a Mario's game similar to the one on the NES is possible on CPC at 50fps.
In any case, I think horizontal scrolling games aren't the CPC's strong point.

jesusdelmas

Quote from: Rhino on 14:53, 23 December 18
Because the scroll does not require CPU, the main task that will determine the fps are the drawing/clearing sprites routine, in this example a general purpose routine is used, it is not specially optimized, and you could get more CPU free with compiled sprites for example. All of this also has its impact on memory, so it also depends on whether you are going to make a 64 or 128kb game.
On the other hand, a Mario-type game doesn't require major math calculations or AI, so I think a Mario's game similar to the one on the NES is possible on CPC at 50fps.
In any case, I think horizontal scrolling games aren't the CPC's strong point.


Thanks for the answer! so i see that 50fps is possible and i thought that it was just not possible so pretty good news for the amstrad scene

rexbeng

Sure, I agree. I have no objection with creating (graphical) restrictions on games in order to save on memory that gets spent on other factors such as framerate. I have worked on two such cases in fact, Relentless and Dragon Attack. Besides, the challenge for the coder and also for the pixeler is greater, so more fun to work with!

@jesusdelmas: there are already plenty games running at 50 frames already  :)

jesusdelmas

Quote from: rexbeng on 20:19, 23 December 18
Sure, I agree. I have no objection with creating (graphical) restrictions on games in order to save on memory that gets spent on other factors such as framerate. I have worked on two such cases in fact, Relentless and Dragon Attack. Besides, the challenge for the coder and also for the pixeler is greater, so more fun to work with!

@jesusdelmas: there are already plenty games running at 50 frames already  :)


I know i was talking about colorful horizontal scrolling.

Axelay

Quote from: Rhino on 21:30, 22 December 18
Hi rexbeng,

I haven't looked Relentless in depth, but I've always thought it's the way fano described it (maybe Axelay can give us more details). In practical terms, the main difference of both methods would be that the Relentless scroll is unidirectional and at constant speed, while this is multiderectional (left/right) and multispeed (Mario inertia).

Fano looks to have described it well, but if you're comparing the scrolling method, and not the particular implementation in Relentless, then a significant difference between the two you didn't mention there is that using palette swapping to achieve a pixel scroll comes with colour restrictions, while the shifted buffer approach does not.  Relentless had colour restrictions from using the 'dual playfield' approach to sprites, but it had nothing to do with the scrolling.  That was about sprites over backgrounds at 50fps in a small memory footprint.  Remove one of those requirements and a full 16 colours could have been used.

I'd also argue that shifted buffers isn't strictly speaking limited to one direction.  It could be used for a bidirectional scroll, I considered such a project in the past, but it would not be well suited for many circumstances, with stopping and multispeed being a particular challenge.

Rhino

Quote from: Axelay on 01:36, 27 December 18
Fano looks to have described it well, but if you're comparing the scrolling method, and not the particular implementation in Relentless, then a significant difference between the two you didn't mention there is that using palette swapping to achieve a pixel scroll comes with colour restrictions, while the shifted buffer approach does not.  Relentless had colour restrictions from using the 'dual playfield' approach to sprites, but it had nothing to do with the scrolling.  That was about sprites over backgrounds at 50fps in a small memory footprint.  Remove one of those requirements and a full 16 colours could have been used.

I'd also argue that shifted buffers isn't strictly speaking limited to one direction.  It could be used for a bidirectional scroll, I considered such a project in the past, but it would not be well suited for many circumstances, with stopping and multispeed being a particular challenge.

Yes, if I'm not wrong in Edge Grinder you use all the colors freely and it's the same scrolling technique, right?
In any case, it is good to have different techniques and know the differences so that whoever wants to make a game chooses the one that best suits their needs.
Btw, Axelay, are you doing any new project for CPC?

Axelay

Quote from: Rhino on 19:55, 28 December 18
Yes, if I'm not wrong in Edge Grinder you use all the colors freely and it's the same scrolling technique, right?
In any case, it is good to have different techniques and know the differences so that whoever wants to make a game chooses the one that best suits their needs.
Btw, Axelay, are you doing any new project for CPC?

Yes, Edge Grinder was the same technique.
On the CPC project front, well, technically yes, but time to work on it has been limited lately and it still has a way to go yet.

Powered by SMFPacks Menu Editor Mod