Thinking about achievements such as Frogger for the CPC+, where the use of rasters (I think they're called) makes the game use so many colors, I couldn't help thinking if this could be done for a game like Pitfall II for the CPC, when I tried it on MAME yesterday.
Pitfall 2 The Lost Caverns Lv1 1984 Sega Mame Retro Arcade Games (http://www.youtube.com/watch?v=W_GQp7tNaE4#ws)
Switch colors for each floor. Possible?
Pitfall hasn't been made for the CPC.
Quote from: mr_lou on 09:09, 20 September 13
Thinking about achievements such as Frogger for the CPC+, where the use of rasters (I think they're called) makes the game use so many colors, I couldn't help thinking if this could be done for a game like Pitfall II for the CPC, when I tried it on MAME yesterday.
Pitfall 2 The Lost Caverns Lv1 1984 Sega Mame Retro Arcade Games (http://www.youtube.com/watch?v=W_GQp7tNaE4#ws)
Switch colors for each floor. Possible?
Pitfall hasn't been made for the CPC.
I wonder why the poor, in my opinion, left/right scrolling?
It could be possible. Would be interesting to mock up a game to do just that.
EDIT: More possible on the plus. When the screen is scrolled vertically the position of the raster interrupts would need to be changed so the colour split occurs in the correct place for each area.
That would solve the background.
The foreground would be done with plus sprites.
Scrolling left/right would be more of a problem, because you would need to keep the same colour areas in terms of height and with the same colours. So the same colours would need to exist across the whole of the left/right scrolling range.
Or accept the colours would change as it scrolls. It could be solved by changing the colours mid-line during the scroll but that would take too much processor time.
I think careful planning would make it work well.
Quote from: arnoldemu on 09:18, 20 September 13
I wonder why the poor, in my opinion, left/right scrolling?
S'probably just because the original is flip screen; if they'd gone for full on scrolling when converting that would also have required a redesign and potentially lost what made the game work in the first place.
I'd love to see some mockups.
Maybe a flip-screen plus game using rasters and sprites would be possible.
Those are some shallow lava pits...
Check out level 2 if you think the pits are shallow. The game looks ok but its very repetitive, and the music is pretty weak too.
I quite like the scrolling effect, it works quite well. Other games have used similar scrolling methods, Zelda for instance.
We could just invent our own game based on Pitfall, and give it a different name.
Maybe draw a lot from Pitfall, but add something too, and make the music more interesting, whatever we want.
As long as we can have that raster thingy effect, making it a MODE 1 game with seemingly many colors. Could be interesting.
That game should be doable on CPC w/o a problem. You don't need rasters though.
Pitfall is very similar, although not as shit as, the Hunchback games.
Quote from: TFM on 18:08, 20 September 13
That game should be doable on CPC w/o a problem. You don't need rasters though.
mr_lou wants rasters, mode 1 graphics, cpc+ hardware sprites!
yes the cpc can do it, with less rasters too, harder work to scroll the rasters when the screen scrolls.
Quote from: EgoTrip on 18:10, 20 September 13
Pitfall is very similar, although not as shit as, the Hunchback games.
:laugh: :laugh:
Quote from: TFM on 18:08, 20 September 13That game should be doable on CPC w/o a problem. You don't need rasters though.
The whole point was to make a game that DOES use rasters, or whatever the technique is called, in order to have multiple colors on the screen in the game, like seen with Frogger.
Quote from: arnoldemu on 18:10, 20 September 13
mr_lou wants rasters, mode 1 graphics, cpc+ hardware sprites!
yes the cpc can do it, with less rasters too, harder work to scroll the rasters when the screen scrolls.
I didn't mention CPC+ hardware sprites, but I'm curious now. Everytime people mention CPC+ hardware sprites, they talk as if it's very simple to achieve this scenario here:
Have 4 colors in MODE 1 for background, and then have 4 OTHER colors for the hardware sprite. That's how I hear it. Is that true?
Regarding scrolling, I'm thinking that the many colors should have priority. So why not just skip the scrolling, and just move the playfield down in one go. Why not?
Scrolling has been seen now, and it's great. Now let's have some awesome MODE 1 games using the same technique as Executioner did in Frogger. :)
I see no problem with rasters and scrolling. Just place the rasters to the interrupts (you got six of them all over the Y axis as you know :) ). So just don't switch off the interrupts and that's it. Therefore I say you don't need rasters, just change colors when the interrupt occurs.
I actually could use my Gerelakos/Giana engine for that, but I lack the time for that project.
EDIT: 6128 Plus hardware sprites have always 15 independant colors and invisible (16. color). That's mode independent. You also can zoom them. Their smallest resolution equals Mode 2 resolution with 16 colors (15 + invisible).
You also can use them for pixel splitting, but that's another story.
Quote from: mr_lou on 17:22, 20 September 13
We could just invent our own game based on Pitfall, and give it a different name.
Maybe draw a lot from Pitfall, but add something too, and make the music more interesting, whatever we want.
I would recommend not calling it Pitfall. As far as I know Activision still own all the rights to Pitfall and they tend to pursue people using their IP.
I doubt they will come after us for losing money from a potential Amstrad release :D
IP sharks do not care about imagined revenue losses from sales, they are after extortionate punitive damages for IP theft.
Let's call the game "fovea secunda" then.
Those cartridge often were not as big as they should have... And those consoles had ridiculously few RAM.
It even lacked enough VRAM to handle its own features actually.
Proper scrolling is not that easy to get and this game is originally flip screen based.
And consoles were not shittygames proof.
Anyway it was somewhat already done :
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=213&slot=2&part=A&type=.png) (http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=213&slot=2&part=A&type=.png)
So a Mode1 with raster version ?
Mode1 really hase few colours you know?
Mode0 is quite suitable enough for this sort of game.
Still yeah, could be a nice sort of game on PLUS. But don't expect too much from the PLUS' sprites and the Z80.
Sega master system was 256x192 resolution "only" so a nice 160x200 would be quite enough... 128x256, mode0 can manage the chunky pixels quite well with those kind of graphics indeed.
What is this with those youtube video displaying old machines in 4/3 on a "modern" 16/10... everything lokes like Mode0 at worse.
Post Edit :
Oops my bad, I jsut realised it is an arcade game, not a SegaMS game...
Well according to its date of release (1985) the arcade specification shouldn't be that far from the SegaMS...
http://www.system16.com/hardware.php?id=693&gid=1813#1813 (http://www.system16.com/hardware.php?id=693&gid=1813#1813)
QuoteMain CPU : Z80 @ 4 MHz
Sound CPU : Z80 @ 4 MHz
Sound chip : SN76496 @ 4 MHz, SN76496 @ 2 MHz
Video resoution : 256 x 224
Board composition : One board
Hardware Features : 2 layers+sprites, hardware collision detection
Z80 based Arcade board, semi flipscreen scrolling, cute cartoonish graphics... 256x224, not a lot of sprites...
This could perhaps even be emulated on a 6128 CPC/PLUS, actually. :P
Quote from: MacDeath on 11:08, 21 September 13Anyway it was somewhat already done :
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=213&slot=2&part=A&type=.png) (http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=213&slot=2&part=A&type=.png)
Oh right yes. The 5th Axis is a better comparison than Hunchback.
That's kind of what I mean, except that instead of changing only 1 color per floor, change all 4 colors. (Except I know that 1 color can't be changed, so change 3 colors then).
That means, change all 3 colors 2-3 times pr. update.
Possible?
5th axis mostly uses only 3 colours per "raster zone"...
And it is on CPC old generation, so obviously this could be done quite betterly on a PLUS because of all the extra features which seems desigend "especially" for this game. ;)
This game was originally designed for MO5/TO7 to be fair, which is a graphical limitation more than anything.
Thomson MO5 :
(http://www.grospixels.com/site/images/5axe/axe_html_759a58c3.jpg) (http://www.grospixels.com/site/images/5axe/axe_html_759a58c3.jpg)
(http://www.grospixels.com/site/images/5axe/axe_html_301bfb88.jpg) (http://www.grospixels.com/site/images/5axe/axe_html_301bfb88.jpg)
More backgroundss elements on CPC, but better "multicolour" for MO5 due to its attributed video mode in 8x1pixels x2colours in 16 colours.
On a PLUS :
could use Hardsprites of course, better rasters (more precises, more numerous, and so on)
could use Hard scrollings.
DMA sounds for some samples sounds.
The Background or softsprites could use one more colour to be fleshed a bit betterly.
why only 3 colours ?
This is mostly due because they straightported the graphics from the Thomson machine.
With addition of white, the sprite wouldn't get this transparency...
Sprites seems coded in 1bpp anyway, like most of the graphics perhaps.
Again a 128K RAM version could easily be better without being especially slowlier, I guess.
So :
=Keep Black and White as common colours on the whole screen.
This enables for high-lighting and shadowing through fine ditherings because Mode1 FTW !!!
Keep those sprites simple, still the white would make them more visible because white would be used for the backgrounds with parcimony
=Then you have 2 inks for the backgounds... PLUS would enable for more fine "raster zones" I guess.
=border for the 1 extra colour displayed on screen... :laugh:
=128K (or ROM ?) and multiloading because more tiles and musics and cinematics is always better.
=then if more tilesets, could perhaps even have some sort of pseudo parralax effect done with a clever tileset for the holes and escalators...
There was also this JameBond game using this sort of Mode1+rasters trick to get nice visual results.
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=1307&slot=4&part=A&type=.png) (http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=1307&slot=4&part=A&type=.png)
on this one, the sprites are more fleshed because they use more colours.
If enough CPU, could even get those "Atari 8 bit" like raster effects on PLUS because 4k palette FTW !!!!
(http://i41.servimg.com/u/f41/11/61/31/48/ar_a8_10.png) (http://i41.servimg.com/u/f41/11/61/31/48/ar_a8_10.png)
I guess this "Atari 8 bit" way is something to use heavily on the PLUS.
Remember those gradiants on GX4000 games ?
Switchblade, Crazycar2, fire and forget2....
There, a game like 5th Axys could really shine above all.
Anyway, list of games with those nasty or failed effects :
http://www.cpc-power.com/index.php?page=database&lemot=MODE1%20special (http://www.cpc-power.com/index.php?page=database&lemot=MODE1%20special)
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=931&slot=1&part=A&type=.png)
Quote from: mr_lou on 11:50, 21 September 13
Oh right yes. The 5th Axis is a better comparison than Hunchback.
That's kind of what I mean, except that instead of changing only 1 color per floor, change all 4 colors. (Except I know that 1 color can't be changed, so change 3 colors then).
That means, change all 3 colors 2-3 times pr. update.
Possible?
Possible, maybe. But it limits how easily you can move things between each "layer", otherwise you'll have things changing colour too. I can't really imagine you'd end up with something that would look that great. Frankly I think a Mode 0 version could easily look much, much better without needing any rasters at all.
Quote from: andycadley on 13:31, 21 September 13
Possible, maybe. But it limits how easily you can move things between each "layer", otherwise you'll have things changing colour too. I can't really imagine you'd end up with something that would look that great. Frankly I think a Mode 0 version could easily look much, much better without needing any rasters at all.
I thought about that too, but as far as I understand, the sprite wouldn't change colors if it's a CPC+ hardware sprite.
And yes of course MODE 0 has more colors. But this is about trying something new. MODE 1 with a few color-changing down the screen, as seen in Frogger for the CPC+.
Don't expect too much from those hardsprites on PLUS.
they are heavy and slow to "refresh", animationframe wise.
They are more like a "tile patch" than proper hardsprites with pointers at RAM and easy multiplexing tricks.
And being on the "over-layer" (foreground compaired to normal bitmap screen) you would have issues to get the hole effect if player's sprite is in Hardware sprites.
Had they been proper 4bpp sprites pointed at RAM/ROM, and easy to vertically multiplex, this could have constitued a true second layer screen easily into 256x256x15...
or (with magnification) x2 layers of 128x256x15 (mode0 sized pxiels).
I guess the CPC original specifications couldn't allow this thing, the sprite video circuit would have needed to read datas like x2 or x4 faster than the normal video circuit, in addition to it (DMA ?), because those sprites could be displayed with Mode1 and mode2 pixel size yet still in 15(+transp.) colours.
Or they simply didn't care or it would have cost slightly more to allan sugar...
Still having to upload them with 8bpp for actually only 4bpp used... ouch...
Good point : each pixels can be addressed, still...
Sadly this would also have made the GX4000/PLUS an actually more viable system (this and 256K or 512K cartriges...).
But I told ways to still get a nice thing in my previous post and those sprites can actually be refreshed, provided you don't aim at a 50hz framerate with shittons of animation frames... ;D
Quote from: MacDeath on 12:08, 21 September 13
5th axis mostly uses only 3 colours per "raster zone"...
This game was originally designed for MO5/TO7 to be fair, which is a graphical limitation more than anything.
That explains the singlecolour Speccylooking graphics
Quote from: MacDeath on 14:01, 21 September 13
Don't expect too much from those hardsprites on PLUS.
they are heavy and slow to "refresh", animationframe wise.
They are more like a "tile patch" than proper hardsprites with pointers at RAM and easy multiplexing tricks.
Somehow I have been given the impression lately that this isn't a problem because we are using the machine a way that it wwasn't intended to be used. WIth cartridges this wasn't a problem. Can anyone confirm this?
The hardware sprites aren't perfect, there certainly are choices in the design that limit them somewhat. Yes, they take quite a lot of time to update so can't easily be multiplexed and so on. However, they're still a *lot* easier and faster to work with than software sprites and if you can store them uncompressed (which is easier on cartridge) then the perf hit doesn't have to be insurmountable.
Looking a Pitfall 2, there are quite a few "sprites" that actually wouldn't need any (or much) animation, so I wouldn't really see them as an issue. I still don't think using Mode 1 would make any sense though. If anything with the foreground objects using sprites the benefits of a higher res background would be minimal and certainly not likely to be as effective as a more colourful one, especially given that the game has relatively sparse backgrounds anyway.
Quote from: andycadley on 07:13, 22 September 13I still don't think using Mode 1 would make any sense though.
Apparently you didn't read what this thread is about then.
Quote from: mr_lou on 09:09, 20 September 13Thinking about achievements such as Frogger for the CPC+, where the use of rasters (I think they're called) makes the game use so many colors, I couldn't help thinking if this could be done for a game like Pitfall II for the CPC.
This thread is not about "How could Pitfall II best be made for the CPC".
This thread is about "Could Pitfall II be a good game for a MODE 1 multi-color game experiment".
So NOT using MODE 1 wouldn't make any sense. It would render the whole idea and this thread pointless.
Quote from: mr_lou on 07:26, 22 September 13This thread is not about "How could Pitfall II best be made for the CPC".
This thread is about "Could Pitfall II be a good game for a MODE 1 multi-color game experiment".
So NOT using MODE 1 wouldn't make any sense. It would render the whole idea and this thread pointless.
And the answer was: "Pitfall II won't be a good game for a MODE 1 multi-color game experiment, but should be a good game for a MODE 0 multi-color game with rasters"...
Quote from: TotO on 08:11, 22 September 13
And the answer was: "Pitfall II won't be a good game for a MODE 1 multi-color game experiment, but should be a good game for a MODE 0 multi-color game with rasters"...
The posts I've seen doesn't agree. Some say like you do yes, but others doesn't seem convinced.
Quote from: mr_lou on 08:12, 22 September 13
The posts I've seen doesn't agree. Some say like you do yes, but others doesn't seem convinced.
OK. Because there is interests to use more than 16 colors on screen here.
Quote from: TotO on 08:14, 22 September 13OK. Because there is interests to use more than 16 colors on screen here.
A MODE 0 16+ color game experiment could also be interesting. But this thread is about the MODE 1 multicolor game experiment.
arnoldemu (and TFM?) seems to believe it's doable, so please keep this on topic. Feel free to create another thread for a MODE 0 game.
The interest of choosing a MODE 0 with rasters instead of the MODE 1, is to use a dual playfield mode.
You will be limited to 4 colours backgrounds tiles AND 4 colours sprites, but you don't have to mask them!!!
So, you get up to 4 different colours for each floor with the rasters (don't conflict with sprites) to look like a FAST full 16 colours game at end.
On your nice idea to use rasters, it would be a clever way for porting this game on CPC...
In all cases, you will have to redo the level design to match with rasters. (can't scroll vertically for stage 2 and above)
That all for me, here. ;)
Quote from: TotO on 08:11, 22 September 13
And the answer was: "Pitfall II won't be a good game for a MODE 1 multi-color game experiment, but should be a good game for a MODE 0 multi-color game with rasters"...
And the answer is "No, it doesn't make sense to use MODE 1 for this game and it'd be a poor choice as a experiment"
Of course you CAN write any game for MODE 1 (or 2 for that matter) and you CAN add rasters to change colour. However if you analyse the kind of screen design in Pitfall 2, doing so doesn't make sense. There isn't a sufficient need for a level of detail to really benefit from the higher resolution and, even changing three colours at a time, you'd be compromising on the number of colours per section and would end up with something that just didn't look nice (which was surely the whole point of adding the complexity in the first place)
It's even worse if you bring the plus hardware sprites into the mix, because the only things that would benefit from MODE 1 resolution is the sprites, which would no longer need the screen in MODE 1. At that point you're compromising the visual appearance even more with even less reason to do so.
There may well be games better suited to the technique (probably more so if you design the entire premise around the limitations of doing so), but this really isn't one of them.
I disagree. It makes perfect sense to use MODE 1. You use MODE 1 to get the better resolution.
But the only way to get more colors in MODE 1 is if the game can be split into levels, like seen in Frogger and Pitfall.
The whole point of doing that is to create a game with the illusion to the gamer that MODE 1 offers many colors. It worked nicely in Frogger. Looks great.
When it works in Frogger, of course it will work for other games as well. (And I don't care if you think Frogger should have been done as a MODE 0 game too).
Just talking about MODE 0 means you don't get the idea. There are plenty of MODE 0 games out there. This is about trying something a bit new.
The idea is a MODE 1 game. As I said. Feel free to start your own thread about a MODE 0 game. This is about a MODE 1 game idea.
And this thread isn't a debate either which is better. Let me say again. It's about a MODE 1 game.
Thank you.
(And if you still don't get it, and continue to talk about MODE 0, I promise you I will hire people to ruin every single thread you create from now on, by insistingly claiming whatever it is you're posting about could/should be done another way). ;)
Then the Obvious question :
Was Pitfall2 a good game to begin with ?
From the video I wouldn't say that... :P
The Dual playfield trick could be great with rasters and hardsprites.
The second layer can be used for some paralax effect and to patch the raster transitions or whatever.
Otherwise having more colours because Mode0 gives the possibility to simply use less rasters so it would ease the CPU.
Even on PLUS, palette changes are not NOP free.
But yeah, I guess this is an iteresting challenge anyway.
quite a few games tried to get the Mode1 having fare more colours, the Plus never really get this change, except for Switchblade/Striker of crypt of Trogan whose engines had a nice use of rasters and Sprite patches concerning switchblade.
Fluff always was an interesting try.
[AMSTRAD CPC+/PLUS] Fluff - Review & Longplay (Part 1 of 2) (http://www.youtube.com/watch?v=WpNq1-WOf4Q#)
Panza Kick boxing on GX4000 also has a heavy use of rasters actually, you can count many colours on most in-play screen.
Many old arcade games from the pre-1985 era could be nice inspirations.
Son Son (Arcade) Demo (http://www.youtube.com/watch?v=rSfQXIN0A64#)
This one could be a perfect candidate.
another fit for dual playfield Mode0 + Sprites/PLUS features :
Pandora's Palace (ARCADE) Inv (http://www.youtube.com/watch?v=9QIWJrnykT4#)
Quote from: mr_lou on 13:23, 22 September 13The idea is a MODE 1 game. As I said. Feel free to start your own thread about a MODE 0 game. This is about a MODE 1 game idea.
And this thread isn't a debate either which is better. Let me say again. It's about a MODE 1 game.
Thank you.
(And if you still don't get it, and continue to talk about MODE 0, I promise you I will hire people to ruin every single thread you create from now on, by insistingly claiming whatever it is you're posting about could/should be done another way). ;)
The answer to the topic is: N, O = NO.
No, Pitfall II will not be a good MODE 1 game with rasters. (for all the good reasons given before)
If you don't want to ear more about "How to get it good", so ask to close your topic, you got the answer.
Better: Don't ask, if your don't want to ear an answer different that your point of view.
@MacDeath: Instead of wasting your time by posting long texts and videos here, go to make sprites for Cyber Hunh! :)
Yes thank you TotO. I have heard your reply more than once now.
As I said, arnoldemu (and TFM?) has a different opinion, so naturally I'm going with that.
I'd love to be proved wrong, but I did spend quite a while going through YouTube videos of the entire game (because I was tempted to see if it was a reasonable coding job to get back into things), a lot of that time was also analysing the graphics to see what it'd roughly need and I don't think the end result is worth it. You're welcome to try and demonstrate otherwise though....
Quote from: Gryzor on 19:31, 20 September 13
I doubt they will come after us for losing money from a potential Amstrad release :D
They do have modern versions of Pitfall available for iOS and Android released last year, so they would be concerned about trademark dilution especially as it's one of their most iconic titles.
That Son Son game looks like a good target for a Plus conversion - smooth scrolling, hardware sprites, etc. Looks like a 30x30 screen, or thereabouts. MODE 1 should be perfect for this one.
As for Pitfall II, or "Shameless Rip-Off of Pitfall II Designed To Not Provoke The IP Owners", I believe a plus version in MODE 0 would be best for this game. This is because 4 colours per raster line is still very limiting.
But I think it is worth thinking of other games that could be a good fit for MODE 1 + Rasters + many, non-animated hardware sprites.
Son son :
hard to find decent picture.
(http://www.videogameden.com/fc/snap/son05.gif) (http://www.videogameden.com/fc/snap/son05.gif)
Seems like a "classic" 256x240...
But it is perhaps the Famicom (NES) version.
With a mode1 could the scrolling be actually smoother ?
The vertical concept could enable nice sprites multiplexings perhaps, even for a PLUS.
Arcade seems to be in 240x240 resolution instead.
(http://www.videogameden.com/fc/extra/son01.gif) (http://www.videogameden.com/fc/extra/son01.gif)
So because of the concept the 256x256 would be perfect on a PLUS.
But the transitions between different tiles/zones could be somewhat problematic, unless level designs is a bit twisted to fit Amstrad machine.
Many platform tiles needs only 2 colours + black, and enemies patterns can be arranged to fit PLUS limited sprites...
VerticalMultiplexing, alternated "25hz" display, alternated animation frames.
This game is actually both a rail shooter and a platformer.
6 lines of platforms, + 7 "between" zones + Score/lifes/HUD zone
even the platform lines could get a bit more extra raster lines for the "floor"...
Would still be quite a lot of raster zones IMO.
But soemwhat similar to what Frogger did... with far more trick to exploit the 16 Hardsprites, which would then turn this game into also a PLUS features Demo as well.
Shit a brick... The Allergy Demo! That is an unbelievably fast,smooth and sharp piece of work!
Quote from: mr_lou on 16:48, 22 September 13
Yes thank you TotO. I have heard your reply more than once now.
As I said, arnoldemu (and TFM?) has a different opinion, so naturally I'm going with that.
Attached to this message is a simple test in mode 1.
It is ugly, but should demonstrate one way it could be achieved on standard CPC.
Move the sprite with q,a,o,p.
You will see bands of colour. These show the normal position of the interrupts. If the colours are changed at these points it takes less cpu time than if you want to change them at points in between.
There are 2 colours that are common to all regions: white and black. Each region then defines 2 of it's own colours.
So within each region you have 4 colours to use, 2 of it's own and 2 fixed. You can use all 4 to make backgrounds. My example background doesn't really show what an artist can do. You are also free to use 4 colours for sprites and store a mask to draw them with.
I believe both Switchblade and Stryker do similar, I think black is one of the common colours.
The sprite on this screen changes colours as it goes between the areas. If this was a player sprite this would be noticed. 2 Ways to avoid this: 1 use the common set of 2 colours (2 colours for main sprite is not great), or make sure the sprite doesn't cross the boundaries by using tricks (character disapears into a tunnel and re-appears on the other side???)
EDIT: My example does look ugly, but both Switchblade and Stryker use this method and they look good.
Example 2:
Looking at switchblade there are 3 common colours and 1 colour changed. On switchblade it's normally 1 colour per screen, but on some screens it's 1 colour per interrupt region. You can see it in one of the playthroughs where a box is broken and the bits that come off are yellow in one place and green in another.
Again, poor graphics that don't show it off well.
The common colour here uses pen 0 and is also shown in the border so you can see the areas.
In this example the sprite doesn't change colour. It uses 3 colours of the palette and doesn't use the common colour.
Depending on how the artist used that other colour (e.g. made it the main scenery colour), then with clever artwork it can look really good.
I may even be able to scroll these regions without using too much cpu time.
I'll try something out.
On the plus you have more flexibility with the regions because of the raster interrupt. You also have a bigger palette to choose from for the regions. And the sprites have a seperate sprite to the main screen so you don't get the problem of the sprites changing colour as they move over the regions.
I'll do an example of this when I have some time so you can see how this would work.
I think it looks great!
I would choose the colours like this:
The two main colours that doesn't change would be grey (13) for neutral (where light doesn't hit) and a dark colour for warm shadow, e.g. purple (4) or dark red (3).
(A warm shadow is when there's shadow but also slight light bouncing back from the ground. Dark purple or red is ideal for that).
Then, two colours that changes should be for a light-source. For example, yellow (24) and orange (15) could go well together.
The main sprite character would always use all 4 colours. Depending on where he is, different light will hit him. So if he's on a level where yellow and orange is used for light colours, then obviously yellow and orange light will also hit him. Or maybe just one of the light-colours.
The grey and dark purple colour will work with most other colours you choose.
Anyway, I also think Mode1 should deserves more love.
Those Speccy ports basically killed it into the eyes of the world. But many games managed well in CGA despite it being 4 fixed colours.
Of course a PC in CGA can get 512K RAM and 8mhz easily, still...
(http://www.cpcwiki.eu/imgs/2/22/Black_tiger_redone_11_CPC_mode1.png) (http://www.cpcwiki.eu/imgs/2/22/Black_tiger_redone_11_CPC_mode1.png)
4 colours are enough... at least better than 6 colours with rasters...
(http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=405&slot=2&part=A&type=.png) (http://www.cpc-power.com/extra_lire_fichier.php?extra=cpcold&fiche=405&slot=2&part=A&type=.png)
Post edit :
This game : Black tiger...
=many rasters (useless actually, and poor colour choices)
=every graphics in 1bpp converted into 2bpp by CPU.
=I even sometimes wonder if it actually emulates attributes for the HUD parts, lol.
=the sprites use 1bpp mask.
=it flips graphics (left-right orientation) with CPU as well.
in 128K with fully natives 2bpp graphics in both left-right orientation (seems the orc's sprite does have both orientations in memory according to WinApe's find graphics), still using the 1bpp mask (so we get 4 colours sprites...) and with no rasters at all, this game would surely run as fast I guess (even perhaps faster if it wasn't coded by Tiertex peoples wearing snowgloves)...
But would surely look damn better and seem a more playable and enjoyable experience actually.
Still a bad game on speccy anyway, was certainly produced in 1 month at best (and 2 weeks for the CPC port)
To have the code ported straight can not help.
Speccy48 version wasn't meant to deal with 1bpp to 2bpp conversion, nor rasters, nor being on CPC6128.
The playfield is very small so this game could run fast and smooth on native CPC code, or get a bigger screen.
The original arcade game runs with a Z80B (6mhz Z80) as main CPU and another Z80A as "soundcard"'s CPU... and its resolution is something like 256x224 "only".
Having such a small playfield on this ZX-CPC version is a cruel gameplay handicap, sprites actually size the same as on the arcade, but playfield is like 1/3 or 1/4 or the arcade. hence scrolling would always activate at the slightlest jump and you almost can't see where you land.
A good CPC version could certainlymanage a 256x240 display, with HUD nor overlaying on the playfield, actual playfield being only 256x192 then (standard speccy fullscreen)
The speccy version shows that the backgrounds can be achieved with actually quite very few tiles. Srpites are quite numerous but not voluminous (small ones) and would be simplified anyway from the arcade.
Oops sorry i'm out of topic again.
Quote from: arnoldemu on 14:04, 10 October 13
I may even be able to scroll these regions without using too much cpu time.
I'll try something out.
And it worked!!!!
Attached.
This uses the interrupt counter "reset" to shift each section down the screen.
For a couple of interrupts there is no interrupt reset.
Then in one I delay for x lines and reset the counter.
In each interrupt after this I then reset the counter.
But I leave an interrupt near the end where I don't reset the counter.
And the result is that the interrupts move down the screen. I need to experiment more to see how I can do this enough so that the sections could scroll with a background that scrolls.
At the moment it moves between 0 and 7 lines.
It shows it's possible, need to find a method now that is best on the cpu.
An added disadvantage to this however, is that if you try and then use rupture to split the screen it could become too complex.
Quote from: MacDeath on 19:41, 10 October 13
Oops sorry i'm out of topic again.
I don't think you are.
We are talking about mode 1, and you've showed some great mode 1 screenshots.
Quote from: arnoldemu on 13:35, 11 October 13
At the moment it moves between 0 and 7 lines.
It shows it's possible, need to find a method now that is best on the cpu.
An added disadvantage to this however, is that if you try and then use rupture to split the screen it could become too complex.
Sounds like a job for the CTC-AY! ;)
Quote from: Axelay on 15:29, 11 October 13
Sounds like a job for the CTC-AY! ;)
yes, ctc-ay, kc compact, aleste or plus would be better for this kind of thing.
all have interrupts that can be made to interrupt on the line you want.
I did think... it would be great on ctc-ay.
If I have time, I'll post some more examples, one using plus interrupts and sprites.
Another using ctc-ay interrupts.
Here a link that could be quite helpfull I guess, if not already posted...
http://vgmaps.com/Atlas/Arcade/PitfallII-LostCaverns-Map.png (http://vgmaps.com/Atlas/Arcade/PitfallII-LostCaverns-Map.png)
The Video Game Atlas - Arcade Maps (http://vgmaps.com/Atlas/Arcade/#P)
this site is quite awesome indeed... a nice source for most "modern" arcade ports on CPC and others... :P
Looking at the maps, I believe a flip-screen Pitfall 2 (or stylistically similar) could be done in MODE 1 with the standard CPC 300Hz timer palette changes - maybe with some graphical alterations to adjust for vertical positioning.
Obviously every screen would have its own palette, but going for the start of the game - leaves, sky+tree trunks, ground + tree trunk, floor, caves 1, caves 2:
A palette of <VARYING>, Dark Blue (or black, or dark red), Orange, White (or pastel yellow).
VARYING would be Green (or dark green), Sky Blue, Green, Grey (Blue Grey), Purple.
You would want to have at least a solid line of a non-varying colour of some sort between each palette change because the CPC does like to do the interrupt halfway through a scanline. This could make for a darker, more sombre game with lots of foreboding shadows. Which IMO would look great.
If sprites never go onto the tree tops, maybe two palette colours could be changed in that area.
All I need now is mockup creation time.