Feature 11 - Pharaohs Return (C64)

[ptoing]

Grimsane: some of that is not possible because of the colours you picked. You can not have a colour from 8-F (the greys, browns and the light rgb colours) as your extra colour on tiles. So no matter what you do, having orange, brown and grey or 2 greys and a brown on the same char does not work.

[Grimsane]

that's what led me to believe you could...
as someone mentioned using black as your optional colour per tile for that region and making that the negative space, kinda like inverting the palette mask.

but as I said I had no real clue, was just going on what I've read in this and another thread here and there, kinda why i was reluctant to post it 

[ptoing]

That thing with the 3 greys would work if you would take one of the greys as BG colour for that big and then set the other 2 greys as fixed and use black as the free colour, yes. I guess you could do that as well in your examples. But to be honest I don't even know how economical it would be to have 6 rastersplits in a game like that. It would take up quite a few cpu cycles and probably make the gameplay slower. But I dunno.

All I can say is look at vierbits Metroid stuff which has no rastersplits (apart from perhaps the statbar at the top) and it looks very good. I think that would be a better approach, rather than relying on rastersplits, esp if this is a game Lazycow really wants to make.

[PypeBros]

imho, brown+darkbrown+black is what works the best for the current mock-up. I'd expect another palette to be picked for e.g. caves area. I can envision splits such as "blocks below, cave-looking above your head" or "blocks below, egyptian paintings as background", etc. (the original game had nice use of such "paintings" to make screens more interesting

It would take up quite a few cpu cycles and probably make the gameplay slower.

That would be 3 stores to the VIC per 32 raster lines. I'd have to dig the report of Mr Sid to know whether this is too much or not, but I think it should leave you enough time for your logic and animation rendering. I'd be more concerned about the fact that it imposes some annoying restrictions on level design, such as "no yellow top-of-platform here, we've got blue rocks 10 tiles on the left".

All this reallly makes me wonder how they realised Rick Dangerous on C64. I never figured out that gfx art on the C64 was so mixed with technology mastery.

But I guess the real question is "do you want to go for a real game or is this just a mock-up ...

[STE 86]

being a graphic designer on any of the 8bits always meant knowing your machine at a technical level. They all require this.

the "reversed" character colour is a standard method of obtaining all your colours from any of the 16. it's also known as the "uridium" method because its what Andy Braybrook used to get his metallic bas relief fades for the game Uridium.

however this will restrict quite heavily the use of colour in the game and simply using horizontal bands of colour will more than likely resullt in something that looks like an atari vcs game. oh and you will also lose your background "lowlight" red tiles if you go this way.

These are shots from soulless which pretty well illustrate the effect you seem to want

[PypeBros]

Which I'd de-construct the following way into "3-color mask" over "per-character color page"

[Lazycow]

Thanks for the comments!

@BladeJunker: Didn't realize that there so many games that use overlay sprites. Interestingly, they all seem to use the overlay sprite for a black outline.

@Grimsane: Brown as dark color and to replace the red blocks? Clever, I like it.

@STE86: Yes, blocks can be hires. I just was too lazy to make the red bricks hires and used copy & paste.
The "soulless" screenshots are really great. So many details and very clever use of hires blocks. Sometimes too many colors maybe.

@ptoing: Programming and map design with raster interrupts would be a bit tricky. Yes, probably. But if you want to go the easy way, you wouldn't make a C64 game anyway, would you? ;-)

@PypeBros: A raster interrupt has more overhead than just poking the colors. You have to save registers and clear flags first and doing anything reverse after. So you cannot do tricks every line like on an Atari 2600 or on the Amiga, I guess.


Yes, the colors of the hero are blending a bit... Let's see... Blue is interesing, but what about red?

On the right side, there's an early version of the hero. (which would force white and orange as global sprite colors) Never liked sprites with 2x2 pixels on the C64. No way! ;-)


Update: Here's a new mockup which uses the Uridium-method (thx, STE 86) for gettings some unusual color combinations.

I think the area of the hero with the "little brown squares" looks a bit odd. But I cannot figure out what's wrong. Do I have to fill the black area here like on the 1st floor? Any hints?

This is my 3rd try to make a game about collecting aegyptian treasures. (no, it doesnt pretend to be a Pharaoh's Curse sequel) I used the C64 graphics to make it easier for me to concentrate on my problems in creating maps and tiles. (that's why I stopped last time)

[PypeBros]

HEre's an edit for you.

1. tried to soften those squarish corners.
2. got rid of highlights on ceiling.
3. had fun with some arachne-inspired vines in the background, possible replacement of those curious squares.

I'd strongly suggest you don't mirror those "brown roots" as "climbing up" or "going left". it just doesn't make sense.

[Helm]

Please consider this edit:



I'm not sure on functionality, but as far as bg/fg separation and usage of dithering for c64

edit: if it's not functional under real c64 limitations I'd like to know so as to present a more realistic edit btw

[STE 86]

warning: this is going to get pretty complicated.

No, what you have done isn't possible under the method which the chap has chosen to create the screen.

in order to have full control over his colour set he has used Black as the overall $d800 character colour ram.

This has the effect of "reversing" out the background colour so instead of black being in the background colour register, he can have any of the 16 colours and thereby bypass the 8 colour limit on character colours.

because of this, you cannot have black and colour which ISN'T green, lt green or brown in the same square. so your blue is out. it would have to be brown (or green or lt green)

the yellow colour top and bottom is being provided by a colour raster split and therefore the yellow colour must extend uniformly across the screen like it does in his initial screenshot. you cannot step it down the blocks only on one side like your screenshot.

The white and the cyan details are being provided for by changing the $d800 colour ram in those squares from black to the required colours. as can be seen from the full red squares dotted around.

not sure exactly which way round the the chap envisages the the colour registers being but at a guess they would be:

Background: Brown
MC1: green
MC2: lt green
character colour ram: predominantly black with spot details colours in white,cyan and red.

you might think this is unnecessary, because green is a character colour, but using this method he can, on another screen have access to the entire range of greys to do stone blocks instead of compromising on white or cyan for stone highlights.

It does however take some getting your head round and curtails your ability to add spot colours significantly.

Steve