Colour Dizzy

[delta]

one thing about DizzyAGE games, is that obviously because DizzyAGE uses tiles for the map, the Dizzy Character is always white, even when in front of a background object. Whereas in the original games, dizzy was whatever colour the background object was - even multiple colours!

so i was a bit bored this evening, and started idly wondering if there was a way to do this in DizzyAGE (make dizzy multiple colours when in front of background objects). Now, the developers among you will think this over for a few seconds, realise that the dizzy character is one tile, and say 'no'. and initially, so did i.

but i don't like taking 'no' for an answer...

[xelanoimis]

He,he - cool one.

Though, this was so annoying on Z80. It had only 2 colors for each 8x8 pixels block. A pixel was either on or off, meaning it was getting the "paper" or the "ink" color from the color block it was in. So, even if you do a smart movement per pixel,you were still limited and could not move it's colors too (unless moving from 8 to 8 pixels).

We were hearing stories about how the Comodore computes have colors for each pixel, but I never had one.

Now about your amazing trick in DizzyAGE, you own us an explanation

Just a quick guess - do you have the graphics white in the background, than paint white dizzy, then another set of brushes (white rectangles with no alpha) painting the proper colors with modulate?

Alex

[delta]

Now about your amazing trick in DizzyAGE, you own us an explanation

Just a quick guess - do you have the graphics white in the background, than paint white dizzy, then another set of brushes (white rectangles with no alpha) painting the proper colors with modulate?

Alex

I wasn't sure what you meant at first, but i get it now. I've never tried anything like that, and didn't even know it could be done! interesting... i may try something like that. It would be a bit of a pain to do though, painting every object (and item) twice.

i may modify my rather complex coding to incorporate something like that tho.

the way i did it is as follows:

it's relatively easy to change the actual colour of dizzy depending on what he collides with. the issue is how to break it down into blocks of colour. So what i did was draw 9 'Dizzys' elsewhere in the map, then use coding in the HandlerGameAfterUpdate() function to specify which part of the tile was shown for each 'dizzy', and then to position that part of the tile over the main 'dizzy' character. So there are actually 2 dizzys, one on top of the other. The only difference is that the one on top is made up of 9 blocks, each 8x8 pixels.

then what i do is use a small bit of code i wrote for CoTM to determine when each of those 9 blocks collides with an object in the room. If it does, it finds the colour of that object, and changes the colour of that 8x8 block to be the colour of the object. The original Dizzy tile is still white behind the 9 coloured blocks.

See the picture below for a more graphic explanation.



the only problem with this is that it doesn't exactly correspond to the colour directly behind him, as if he moves 4 pixels to either his left or right, all the 8x8 blocks will be half-way between one colour and another.

The solution would be to make him up of 36 4x4 blocks instead, which should fix the issue.

I hope that satisfies everyone, and is clear enough!

[Meph]

Thats rarther clever stuff.

[xelanoimis]

aha

The thing with your method is that your background brushes must be dynamic objects to test the collision.

A nice optimization would be to build a color map based on the background static brushes. The dynamic objects would simply read their colors from this map (still have to split them in 8x8 blocks). The color map would be room_w/8 x room_h/8 in size and can be build offline and saved in separate file.

About the trick I suggested, an editor script can be made to generate the front color brushes and remove color from background brushes automatically, like a map compilation.

[delta]

aha

The thing with your method is that your background brushes must be dynamic objects to test the collision.

i know. i had to change all the background scenery brushes into objects. you can see that the rock he stands in front of at the end is a brush however, as his hand is still white when in front of it.

I do have another option, which is to make them all objects, and use the O_COLLIDE function I've introduced into CoTM, which effectively simulates a solid object for the purposes of moving around. However I'm not sure whether it would work properly for walking on top of curved objects.

A nice optimization would be to build a color map based on the background static brushes. The dynamic objects would simply read their colors from this map (still have to split them in 8x8 blocks). The color map would be room_w/8 x room_h/8 in size and can be build offline and saved in separate file.

About the trick I suggested, an editor script can be made to generate the front color brushes and remove color from background brushes automatically, like a map compilation.

arrrghhh I'm not even going to bother! haha it's far too much effort for a visual effect that not only is a step backwards, but that i may not include in any games anyway!

i just wanted to see if it could be done! now that I've proved to myself it can, I'm happy.

[xelanoimis]

Yeah, I wouldn't like to see the DizzyAGE games using this feature.
As I said, it's more like a limitation of the Z80, not really something to bother with.

[Meph]

But can it be done too only work in certain rooms?
it could be a nice little featuer within a big game.. some kind of dodgy magic spell lol

[delta]

oh yes, quite easily. a simply variable check and switch it on/off when entering/leaving the room.

wouldn't really want to tho. it's not perfect, and i can't be arsed spending time on it to make it perfect.

[Joe]

Colour-clash is a limitation of the ULA in the ZX Spectrum, the Z80 doesn't have any responsibility for generating the video display There's a Z80 in the Amstrad, Master System, Game Gear, Game Boy, Megadrive and even the Commodore 128, it's a general purpose microprocessor, and a very nice one at that