News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_mr_lou

Could Pitfall II be a MODE 1 game with rasters?

Started by mr_lou, 09:09, 20 September 13

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

mr_lou

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

Switch colors for each floor. Possible?
Pitfall hasn't been made for the CPC.

arnoldemu

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

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?
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

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


My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

TMR

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.

Sykobee (Briggsy)

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

EgoTrip

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.

mr_lou

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.

TFM

That game should be doable on CPC w/o a problem. You don't need rasters though.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

EgoTrip

Pitfall is very similar, although not as shit as, the Hunchback games.

arnoldemu

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.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

mr_lou

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

TFM

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.
TFM of FutureSoft
Also visit the CPC and Plus users favorite OS: FutureOS - The Revolution on CPC6128 and 6128Plus

ralferoo

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.

Gryzor

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

steve

IP sharks do not care about imagined revenue losses from sales, they are after extortionate punitive damages for IP theft.

MaV

Let's call the game "fovea secunda" then.
Black Mesa Transit Announcement System:
"Work safe, work smart. Your future depends on it."

MacDeath

#17
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 :


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

mr_lou

Quote from: MacDeath on 11:08, 21 September 13Anyway it was somewhat already done :


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?

MacDeath

#19
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 :



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.



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


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



andycadley

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.

mr_lou

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

MacDeath

#22
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

ivarf

#23
 
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?

andycadley

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.

Powered by SMFPacks Menu Editor Mod