Could Pitfall II be a MODE 1 game with rasters?

[mr_lou]

I still don't think using Mode 1 would make any sense though.

Apparently you didn't read what this thread is about then.

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.

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.

[TotO]

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.

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"...

[mr_lou]

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.

[TotO]

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.

[mr_lou]

OK. 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.

[TotO]

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. 

[andycadley]

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.

[mr_lou]

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). 

[MacDeath]

Then the Obvious question :

Was Pitfall2 a good game to begin with ?

From the video I wouldn't say  that...

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)

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


This one could be a perfect candidate.


another fit for dual playfield Mode0 + Sprites/PLUS features :

Pandora's Palace (ARCADE) Inv

[TotO]

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). 

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!

[mr_lou]

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.

[andycadley]

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....

[ralferoo]

I doubt they will come after us for losing money from a potential Amstrad release

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.

[Sykobee (Briggsy)]

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.

[MacDeath]

Son son :
hard to find decent picture.


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.


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.

[Puresox]

Shit a brick... The Allergy Demo! That is an unbelievably fast,smooth and sharp piece of work!

[arnoldemu]

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.

[arnoldemu]

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.

[arnoldemu]

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.

[mr_lou]

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.

[MacDeath]

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...


4 colours are enough... at least better than 6 colours with rasters...






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.

[arnoldemu]

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.

[arnoldemu]

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.

[Axelay]

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! 

[arnoldemu]

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.