16 colors for amoeba / brick wall

[Arno]

I was wondering, is it technically impossible to choose from all 16 colors for color 5? It looks like all existing editors, including CLCK 3.0, support only 8 colors.

I'd find it great to have an amoeba in orange, or lightred, lightgreen... (I know this is already possible if you enable the BD2 mod, but then the overal "glow" in the cave will have a different color.)

Anyway, I would certainly use such feature, if it existed.

[LogicDeLuxe]

It's the way the C64 works. From the 4 color bits, one is reserved for switching the multicolor on/off. There is one intermission in Dr. Watson's BD4 which have turned multicolor off, thus you seeing the titanium wall as vertical stripes.

The Atari version has several caves with colors impossible on the C64, but I wouldn't say, that they look better there.

[Arno]

So, there are probably more C64 games having such a restriction? (i.e. one color is defined by 3 bits and the others by 4 bits.)

BTW, after thinking a bit about this, I found a way to partly eliminate the restriction for Boulder Dash. It must be possible to create a Graphics Set equal to the original graphics, with background color and wall/amoeba color swapped. Now the background is limited to 8 colors while 16 colors are available for the cave "glow".

[Simon]

Yes, you could swap background color and color 3 throughout the whole character set. Although, then you would have to write an extra routine to draw the white flash that illuminates the cave background when the outbox opens.

[LogicDeLuxe]

So, there are probably more C64 games having such a restriction? (i.e. one color is defined by 3 bits and the others by 4 bits.)

Yes. Though one color can be set for each 8x8 (~8 Mhz clock) pixel character separately. The Atari is similar in this matter, and BD sets the amoeba to green independently from the rest of the cave. The C64 hardware can do this as well. The problem is that BD's scroll routine and animations take much CPU time and there was not enough left for this, hence this feature was removed during porting the game.

BTW, after thinking a bit about this, I found a way to partly eliminate the restriction for Boulder Dash. It must be possible to create a Graphics Set equal to the original graphics, with background color and wall/amoeba color swapped. Now the background is limited to 8 colors while 16 colors are available for the cave "glow".

Right. That should work. I might even try implementing it that way in CLCK while staying compatible to earlier caves by changing the color bytes in the cave file accordingly.

[Arno]

Yes, you could swap background color and color 3 throughout the whole character set. Although, then you would have to write an extra routine to draw the white flash that illuminates the cave background when the outbox opens.

Good point! The elements will flash at places where otherwise color 3 is used. This is not visible if that color is white. Although (if I remember correctly) the border of the screen also joins with the flash (unless the border is white, of course).

But unfortunately there would be another side effect... The background color is also used as the background of the score bar, which is then hardly readable (or even not readable at all) in case of a bright color...

[LogicDeLuxe]

The elements will flash at places where otherwise color 3 is used.

That's a point. Maybe we should rotate the colors instead of swapping background with color 3. That way, color 1 becomes color 3, color 3 becomes background and background becomes color 1. Than the code would be easy to fix, since flashing color 1 is as simple as flashing the background.

But unfortunately there would be another side effect... The background color is also used as the background of the score bar, which is then hardly readable (or even not readable at all) in case of a bright color...

That was already fixed in the 1stB engine, thus it is no issue in CLCK either.

I definately will try this.
One other side effect would be the appearance of the title screen, if it uses some game graphics. Maybe I should make this change optional, because of this.

[LogicDeLuxe]

My first test looks like this:

All three item colors are choosen from the upper half.

In this test, I just shifted all 4 colors throughout the entire character file. To do it properly, I still have to exclude the text characters and the status bar sprite from the conversion, as this would mess up the status bar otherwise. Should be no problem.

I will try to make the engine backward compatible, thus all caves should appear as intended, unless it uses one of the higher colors for the background.

As you can see in the screenshot, it also affects the colored special items, since they aren't displayed in multicolor. There is no problem with that, but probably a thing, you have to get used to. It's not affecting the game.

[Arno]

Looks great!!

[LogicDeLuxe]

I afraid, this feature will not make it into my next engine. The flash would be the problem, taking too much time. I really don't want to stuck for a moment when the flash appears, throwing you completely out of the rhythm and losing a life every time this happens. This might end up pretty frustrating. So I dismissed this idea.

[Simon]

I afraid, this feature will not make it into my next engine. The flash would be the problem, taking too much time. I really don't want to stuck for a moment when the flash appears, throwing you completely out of the rhythm and losing a life every time this happens.

Really?

Code: Select all

set_color:
         lda #9    ; 9 = white (in text multicolor mode)
         ldx #31
loop:    sta $D800+40,x
         sta $D800+40+32,x
         sta $D800+40+32*2,x
         sta $D800+40+32*3,x
         ...
         sta $D800+40+32*29,x
         dex
         bpl loop

That takes about 4000 cycles, or 70 rasterlines, or 1/250 sec.
Taking into account that screen scrolling and charset animation already takes a lot of time, let's say 66% of all rastertime. Then the routine above would delay game play by 1/80 sec., or 0,012 sec.
Do you really think that the player gets out of rhythm by that?

[LogicDeLuxe]

Well, I might try this, but it sure has low priority. That routine probably would be fast enough, but also isn't exactly small.

I might try to do a better scrolling routine. The routine should take about the same raster time in each interrupt, no matter if the game is currently scrolling or not, like the original does. Preferably, doing so without using sprites, with less rastertime then the original, just as fluent as the original, using less RAM (the original uses several kB for a virtual screen buffer).
If this could be done, of which I'm not sure yet, we would have even more time for writing the color RAM and wouldn't even have to worry that much about code size as we just gained some kB.
The thing is, if we really manage to write the color RAM in each frame, shouldn't we prefer individual colors for Amoeba and Slime (and maybe even more element specific), like in the Atari version instead of just more possibilities for foreground color but still only 3 in total?

[LogicDeLuxe]

This one looks interesting: http://codebase64.org/doku.php?id=base: ... ioning_hsp.
It needs to be adapted for multinorm, though. I think, it would be a step in the right direction.
If I would write the outermost visible colum of the current cave position in each raster time, video RAM and color RAM alike, the raster time should be constant and there should be more time left then it currently is, am I right?

And I would use 6 sprites (1 for diamonds required, 1 for diamond value, 1 for diamonds collected, 1 for the timer, and 2 for the scores) for the status bar. Also the usual messages like "player 1, 3men a/1", "spacebar to resume", "b o n u s l i v e" and "g a m e o v e r " will fit into 6 sprites. The cave name can be placed in a second line, which would be necessary, since I don't have space to indicate the current level anyways. The cave names would be totaly optional that way, and can be increased to 18 characters instead of the 14 in CLCK.

Any ideas how to get the vertical scrolling done in a similar fast way?

[Simon]

This one looks interesting: http://codebase64.org/doku.php?id=base: ... ioning_hsp.
It needs to be adapted for multinorm, though. I think, it would be a step in the right direction.
If I would write the outermost visible colum of the current cave position in each raster time, video RAM and color RAM alike, the raster time should be constant and there should be more time left then it currently is, am I right?

Hm, so you think about HSP -- also called DMA-delay.
How are you going to update the screen for moving cave elements, e.g. a falling boulder? You would have to decide if the boulder at its current position is currently visible or not (or half visible or 1/4 visible?) and if its destination position is visible... Sure, it can be done, but I think that handling moving elements would eat a lot of cycles, then.

Any ideas how to get the vertical scrolling done in a similar fast way?

Yes, by using VSP (a combination of FLD and line crunching). But then you get at least 31 black rasterlines starting at the top of the screen area, so that reduces the visible cave area somewhat.
And of course you still have those update problems I mentioned above.

HSP and VSP combined is often called AGSP. There are rumors that AGSP crashes after a few seconds on older C64s (the real hardware, not in an emulator), but works perfect on newer C64 and all C128. It's something about the VIC getting "confused" so the DRAM refresh doesn't work any more, and then some bits in memory flip randomly after a few seconds. That's what I heard. You may want to search the forum64.de for more information on that.

[LogicDeLuxe]

How are you going to update the screen for moving cave elements, e.g. a falling boulder? You would have to decide if the boulder at its current position is currently visible or not (or half visible or 1/4 visible?) and if its destination position is visible... Sure, it can be done, but I think that handling moving elements would eat a lot of cycles, then.

I see, I would pretty much loose what the faster scroll routine gains. Things obviously get more complicated than I thought. Do you think it would be worth rewriting the entire scroll routine? The reason nobody tried is most likely is because the current one works that well. The only thing optimized by Prof. Knible worth mentioning is that he removed the unneeded copying of self modifying code, an evidence the Peter Liepa had a ROM version in mind (which actually exist in the arcade machine, though it's the atari version). This does not change the speed, but save some RAM.

Anyway, rewriting the scroll routine is of low priority. What I really have on my todo list is:
- All text of my Crazy Light Tools and its manual bilingual.
- Finally coding the missing features in the title screen editor.
- Adapting the Enemydesigner for CrLi and adding an import routine for PLCK graphic sets.
That makes the Crazy Light Tools v3.0 final so to speak.

- Disassemble the engine
- Cleaning it up, so we'll get readable and compiling code
- Optimizing what's there already, mainly getting rid of all those NOP's and JMP's I introduced while coding in a monitor. (I never liked macro assemblers, as they take much RAM of which we don't have much on a C64, but with cross development nowadays, this ought to be a different matter, so I definitely will try this.)
- Implementing new cave format and demo capability. See here.
- Writing a BDCFF compiler for that new cave format in C, so it can be compiled for any system, including the C64 itself.
(- Maybe replacing hidden exits. See here.)
(- Maybe, if it makes even sense at all, a new scroll routine.)
(- Maybe, I might try the color flash with such a routine, you suggested, and see how it turns out).
- Adapting the link tool from the Crazy Light Tools with the new engine and loading for compiled BDCFF cave packs instead of CLCK cavepacks.
Then, we will have Cross Development C64 engine v5.0

What do you thing of my ideas about the new cave format and the demo format? (subject to change, as nothing of that is implemented yet)