Feature 11 - Pharaohs Return (C64)

[PypeBros]

I was more thinking at those things that spit from the ground, like in this video


As for the elevators, their role in the gameplay is obvious. They could be some visible part of a sophisticated machinery. Afaik, egyptian people were fond of mechanisms/machinery that can be thought as the act of gods by their opponents.

(lol on the petscii screen -- reminds me of that animated oric screen by some moderator)

it could also use the "extended background color mode" instead of the multicolor mode, to get hires graphics

I'm absolutely not convinced you need hi-res graphics here. It's going pretty well right now and if you keep embracing the limits rather than fighting against them, I'm not afraid.

not sure about the black shadow on the topleft

darkblue instead ?
Anyway, it would look better if the top block was a bit wider on the left so that the shadow was horizontal all the way long.

Argh. fail. darkblue can't be mixed with yellow on the same tile, since yellow is the char color already.


Grey seems to work a bit better than plain black, and could be mixed with darkblue in the "border" tile on the right.
That may require some adjustment on the palette swaps, however.

[Lazycow]

@ptoing: Ok, it depends... Still to lazy to check it out if ECM would look better.  Maybe I should keep the multicolor mode.

@pypeBros: You could see the lifts as part of an egyptian machinery, well... ok. I think I would prefer moving blocks instead of moving plattforms. The longer top-plattform is nice. Like this the shadow looks ok. Haven't started on drawing traps, yet. I am so slow in pixeling.

"Embrace the limits, don't fight them" - that sounds like a sentence from Spock... 

Unfortunately, I am still fighting against them in this post. On my notebook, I can zoom the graphics to 3x. (On other computers even more)  These are very big pixels and dithering looks odd somehow. To come around this, I made a little converter to display the graphics in a C64 emulator. Maybe the game should have some CRT-monitor emulation? (or am I getting crazy now?)


Here's a part of the 3rd mockup in reverse mode, using the C64 emulator "vice" with enabled CRT emulation. (On the bottom are Helm's pixel clusters)
- I have spotted 2 things in the CRT emulation: a) dark scanlines, b) blurs the colors to the next pixel
- dithering looks better (?)
- seems like I can mix some colors on the C64? (I made some tests on the right side)

blue and brown / yellow and light green - do these colors mix to a new color or what? Should I use these effects? I have the feeling, at least the C64 game "mayhem in monsterland" does color mixing this way. It's hard to say, because I could only find screenshots without monitor-emulation. But the stripes in the screenshots are very omnious.


Here's a test with single blue hires pixel (top half) and wide pixels (bottom half).
- single pixels have less brightness (?)

If someone wants to check it out on a C64: compare1.prg compare2.prg


Some test rocks... In reverse mode, I can use 4 colors for the rocks, but then I cannot use blue background like in the picture above and I would have to use 3 colors. Except I utilize the color mixing from above for a 4th color. What do you think?

[ptoing]

Yes, you can blend certain colours on the C64. This has to do with both how the PAL signal works and some peculiarities of the C64. It does matter which of the colours comes first. But this effect differs slightly from C64 to C64 actually, because it has to do with some analogue hardware which is not calibrated super exactly.



As you can see there are 7 real luma pairs (the pair colours will be the same grey value if you would turn down the saturation on a c64 monitor or tv down all the way)

The light blue, mid grey / light red, green luma pairs have the peculiarity to be closer in luma than other pairs. So you can kinda mix all those 4 colours with each other, tho you do not get a 100% mix you get some nice stuff as well.

[Lazycow]

@ptoing: That's... that's really thrilling! And if I switch the emulator to NTSC, the effect vanishes.   (a pity!)
"Mayhem in Monsterland" does indeed use some of these color combinations with near lumina-pairs. But it's hard to use mixed colors... Moving on without mixing. (at least for now)


Update-time! Let's include some elevators of the egyptian machinery...   I used moving blocks instead of platforms. Like this, the blocks could be used as elevators and as doors.

To move the blocks on the C64, I need a lot of the 256 characters of the C64 charset. But like this, I can build rooms that have lots and lots of elevators and doors. That's an important gameplay element. Either they move in a certain rhythm, or the blocks are controlled by switches. In the end, all the graphics may not fit into one single charset.


BOSSFIGHT!

I need a split in the bottom half to switch to reverse-mode. (I can only use 4 colors for the rocks in reverse-mode) In the top half, I used black as background color. (Otherwise I cannot use blue background blocks)
The two layers of background do not show that much depth. I am a bit disappointed.  

Some calculations for the ROCK GOLEM:
- The C64 has 8 sprites. The hero needs 3 of them. (2 sprites, because of the overlay and a 3rd sprite for the whip, the dynamite or the gun bullet)
- So we have 5 sprites left for the boss: Sprite 4 and 5 for the body will be duplicated with 2 raster interrupts to build two 24x63 sized supersprites. (Like this, they cannot overlap) Finally, we have sprites 6/7/8 for the hands, which can be moved freely. (handy for the attack animations)

And yes, every Lazycow game needs a guardian:
- "I am the guardian!"
- "What are you doing here?"
- "Make an educated guess!"

[PypeBros]

I love how it's coming along. As for your elevator block, I guess if you need more tiles in some room that have little/no elevator, you could still use sprite elevator there and block elevator in the special "up and down" screen.

Although I love the design of golem guardian Guile, I think he lacks contrasts right now. He might prefer a (mostly) non-black background and use black as a sprite color instead.

[ptoing]

I hope you are aware that sprites are ALWAYS 21 pixels high, no matter what is in them, even just one visible pixel.
Also you can x/y stretch sprites. Hewson did that a lot in their Creatures games and a bit in Mayhem too.

[Grimsane]

whoa that looks pretty epic, especially at first glance, even if you have difficulty with the c64 restrictions and decide to abandon making a game specifically for c64, I hope you stick relatively close to spec along these lines =D and even with screen filters as an option, because they look quite authentic and inspire a warm fuzzy feeling 

and tile based animation methods like that are quite alot of work huh compared to simply sliding the contiguous block with code  I like how you've thought of doubling them as doors, looks effective.

btw how do you manage the bats and other character sprite if you are only allowed 8 sprites? making them tiles? strictly working within those restrictions would wrack my mind

[Lazycow]

Thanks for the support! I am not sure if I still would working on this without all your feedback. It's a bit strange to follow the C64 restrictions 100% for a potential PC game. The restrictions help me to focus, but they do not really help me much to create the graphics. Well, let's see...


The C64 can have up to 8 sprites... in one zone. We can build multiple horizontal zones, divided by raster splits.

- Split "A": in this split we reset all 8 sprite positions, so the 8 sprites can be reused (the score display and stuff are build out of sprites)
- Split "B": this split just changes one multicolor color. (pretty much obsolete)
- Split "C"/"D"/"E": resets sprite positions again. (Split "D" and "E" do only reset positions of sprite 4 and 5, see graphic below)
- Split "F": changes background colors and at least one sprite position (for the scorpion)
- Split "G": changes all sprite positions again for the map and the map name. (the map is build out of 3 stretched sprites)

Since we do not have a complaining C64 programmer here who has to program this, no one stops me here.
The sprites have a fixed size of 24x21 and cannot be smaller, yes. Do I miss something? The only problem I could see here is, if a sprite moves close to the top or bottom area. Then it will overlap the status display. I am not sure, but I think a sprite cannot overlap itself vertically over a raster split.


Hm... yes, the golem could be build out of streched sprites, not using any raster splits at all. Interesting, but the streched sprites would have superwide 4x1 pixels. Uhhh...


Yes, I don't like the contrast in the boss mockup very much, too. Has Yeti be seen in Egypt, yet? One thing to consider: 2 of the 3 sprite colors are shared between all sprites. But the 2 colors are not set in stone, yet.

[PypeBros]

--

(please ignore super-sketchy background replacement, I just wanted to see which colours could be used for background details over a mostly-grey scene: brown and grey doesn't work so well in that case.).
Imho, introducing black as shared sprite color for this scene could work.

"Embrace the limits, don't fight them" - that sounds like a sentence from Spock...

I have some pretty Spocky sides, but not near the ears. Using horizontal dithering (on the right of your golem) is limit-embracing. Those "black spikes" at the bottom of the stones that make the golem is clearly "limit-fight" in my eyes (unless you wanted them to have a skull-shape, somehow). The rightmost variant of my edit tried to fix that by embracing more, with some AA.

If I were a bat/scorpio here, I'd run/fly for my life possibly even before the golem comes to life. Your sprite splicing could work, but that start looking like a lot of data to transfer every frame. Iirc, you don't have a "palette" of sprites available: if you want to switch Spr2 from hearts to bat, you need to copy that from RAM to VRAM on the "A" barrier.

Having no (vertical) room between the D and E areas, for instance, means that you'll have to ensure the first lines of your golem sprites have *already* been replaced during D, but not too early (so that you're still slightly behind rastering). I think that's feasible for someone who mastered the hardware, but that's for sure a challenge of its own. Essentially, C-F becomes a busy-loop of sprite data updating more than a "h-blank interrupt".

Personnally, If I were to program this, I'd urge you to save me some tiles room so that status, map and level name could use tiles rather than sprites, but that's completely off-topic at this point.

[mrsid]

Apparently it's not ok to just say nice things here about the art if it's less than 2 lines of text...
Way to go, making sure the coders just stay lurkers here!

So I'll just add that I don't just like the visuals here a lot, but that I also think that from a programming point of view, I don't see a problem with the restrictions. I think this is totally doable.
I'm just wondering how the golem would look animated, i.e. how much his hands can move away from the body with the whole thing still looking nice.