What made crownland so colorful?

[TheNameOfTheGame]

I have been looking at some coding techniques for A8 and noticed some games like crownland are more "colorful".

 

For example Naturix has good graphics but the main screen is all shades of one color it seems.

 

 

 

Compare this to crownland:

 

 

 

So what are some of the techniques crownland uses to get a more colorful appearance?

[popmilo]

- Dli (display list interrupts) to change color register values at certain vertical position on screen (Color of sky and ground in those Crownland screenshots).

- 5 color character mode. Background and two colors are fixed for each of 128 charactes in character set. Fourth possible color in each character can be one of two registers depending on value of bit 7 of character screen code.

You can see it in screenshot bellow (Different colors of those square blocks):

 

Most irritating limitation is that max 5 color per scanline in normal color modes.

 

You can put more colors in one line with very cpu intensive live changes of color registers in middle of screen or with using Player Misile over (or under) normal graphics.

Here is good example of PM mixed with background:

 

[+Philsan]

Two recent colorful games

 

Dimo's Quest (up to 44 colors):

 

http://youtu.be/e4m6MRQbkfk

 

RGB (circa 35 colors):

 

http://youtu.be/WTbDx-JX3QM

[TheNameOfTheGame]

- Dli (display list interrupts) to change color register values at certain vertical position on screen (Color of sky and ground in those Crownland screenshots).

- 5 color character mode. Background and two colors are fixed for each of 128 charactes in character set. Fourth possible color in each character can be one of two registers depending on value of bit 7 of character screen code.

You can see it in screenshot bellow (Different colors of those square blocks):

crownland_preview_6.gif

 

Most irritating limitation is that max 5 color per scanline in normal color modes.

 

You can put more colors in one line with very cpu intensive live changes of color registers in middle of screen or with using Player Misile over (or under) normal graphics.

Here is good example of PM mixed with background:

 

 

Ah so crownland is using techniques like this Rick Dangerous port using Antic4 5-color mode?

 

http://translate.google.com/translate?client=tmpg&hl=pl&langpair=pl|en&rurl=translate.google.com&twu=1&u=http://www.atari.org.pl/forum/viewtopic.php%3Fid%3D9887%26p%3D2

 

Wow so the cybernoid is changing color registers on the horizontal sweep? Must be tricky coding...POKEY timers??

[TheNameOfTheGame]

Two recent colorful games

 

Dimo's Quest (up to 44 colors):

 

http://youtu.be/e4m6MRQbkfk

 

RGB (circa 35 colors):

 

http://youtu.be/WTbDx-JX3QM

 

Yes, I have seen both and they are amazing....Antic 4 5-color text mode also??

[+JAC!]

 

Wow so the cybernoid is changing color registers on the horizontal sweep? Must be tricky coding...POKEY timers??

 

No. It's overlaying the character/multicolor graphics with 4x sized players in PRIOR mode $00. As a result the colors of the player or or-ed with the background.

Horizontal splitting is not possible in character mode (well it is, but nor for something "useful" :-)

[TheNameOfTheGame]

Just to confirm what I am thinking. Are Crownland and Rick Dangerous using Antic4 mode?

[popmilo]

Just to confirm what I am thinking. Are Crownland and Rick Dangerous using Antic4 mode?

Crownland yes, Rick looks like it is (hasn't been released yet...).

 

Here is one more example with explanations of using expanded PMs to get more colors:

 

Analmux's demo with source code and explanation here:

 

http://atariage.com/forums/topic/229764-source-code-released-scrolling-mcs-pmu-rmt/?do=findComment&comment=3072381

 

[emkay]

So what are some of the techniques crownland uses to get a more colorful appearance?

Most stuff has been explained. But "Crownland" also is cheating a bit, as it allows the moving objects to flicker. As long as the count of moving objects per scanline wasn't more than the available PMg objects, it looks more colourful and richer of details.

Actually, you see that flicker less often, so the decision about it , was good. Other games with several moving objects on the same "scanline" need to use software moving objects, that causes a reducing of the available colours. IF flicker is no problem, you can add all 128 colour to a game.

A big "minus" with crownland is the 32 bytes mode in the "full" game, while the demo uses a 40 bytes wide view.

Edited January 25, 2015 by emkay

[Bryan]

The short answer is: code.

 

The Atari is a low color depth machine with a big palette. This means the colors are there if you're willing to work for it.

 

This makes it a personal achievement to design a colorful program, but it also means that there's going to be a lot of bland looking software- especially with conversions from other systems.

[TheNameOfTheGame]

Most stuff has been explained. But "Crownland" also is cheating a bit, as it allows the moving objects to flicker. As long as the count of moving objects per scanline wasn't more than the available PMg objects, it looks more colourful and richer of details.

Actually, you see that flicker less often, so the decision about it , was good. Other games with several moving objects on the same "scanline" need to use software moving objects, that causes a reducing of the available colours. IF flicker is no problem, you can add all 128 colour to a game.

A big "minus" with crownland is the 32 bytes mode in the "full" game, while the demo uses a 40 bytes wide view.

 

Did they add something to the full game that the demo didn't? I couldn't tell a difference. So what was the benefit or "need" to go to the 32-byte mode?

[TheNameOfTheGame]

The short answer is: code.

 

The Atari is a low color depth machine with a big palette. This means the colors are there if you're willing to work for it.

 

This makes it a personal achievement to design a colorful program, but it also means that there's going to be a lot of bland looking software- especially with conversions from other systems.

 

Yes, I remember a lot of "bland" conversions back in the day.

 

 

Programmers have discovered a lot since then. There are so many amazing designs now.

[emkay]

Did they add something to the full game that the demo didn't? I couldn't tell a difference. So what was the benefit or "need" to go to the 32-byte mode?

Seems, there had been some issue with understanding the rules of the ABBUC Softwarecontest. The rule is , it has to run on a stock Atari with stock peripherals (1050 floppy). The screen had been reduced for memory saving and to run the game inside the memory of the "stock" Atari without loading the levels from disk...

[+MrFish]

Seems, there had been some issue with understanding the rules of the ABBUC Softwarecontest. The rule is , it has to run on a stock Atari with stock peripherals (1050 floppy). The screen had been reduced for memory saving and to run the game inside the memory of the "stock" Atari without loading the levels from disk...

 

In that case, better to load the levels from disk.

[Heaven/TQA]

32 mode vs 40 mode in Crownland might be more issue not RAM but having more CPU left per frame... my guess that is the reason and not RAM.

[emkay]

32 mode vs 40 mode in Crownland might be more issue not RAM but having more CPU left per frame... my guess that is the reason and not RAM.

Wrong quess. The demo was fully working with 40(48) Bytes width. Some years ago the coder of the game stated that the screen had been reduced to have the game running on an Atari without additional RAM.

[Creature XL]

32 mode vs 40 mode in Crownland might be more issue not RAM but having more CPU left per frame... my guess that is the reason and not RAM.

 

I thought the same, however, emkay's post could be interpreted as if he knew it from the developer. And he restated that in a reply to you so I guess it is indeed the reason.

But, I want to add that I cannot imagine why it should affect the needed RAM. As I was absent from the ATARI-Front during that time, I haven't looked at the demo version much. So a running demo version in 40 bytes doesn't automatically mean the final version would run in 40 bytes as well, because background tasks could have been omitted which were needed in the final version. Or it might be so simple things that there wasn't enough raster time for the DLI's.

The DITCH engine runs with 48 byte mode as well and doesn't use any extra DMA time (as 40byte and 48 byte is the same when using hscroll) however, there is not enough time in the HBLANK to change two colors as simple as that And considering "Crownland" changes PMG registers as well...

One would have to check out the demo version and look for flickering on the right (or left) side of the screen. But I am on emkay's side and assume he has the info directly from coder. So why bother. Just sharing thoughts

[MaPa]

I don't know what the memory reasons can be to shrink the size from 40 to 32 bytes. AFAIK the whole level is prepared in RAM under OS and it just move the visible "window" over it by changing LMSes. So with 40 bytes it would be the same, you would just see more from that level at once. Maybe it was the case, that with smaller screen you can design level with more sprites as the left ones will leave screen before the new ones on right will appear.

 

The DITCH engine runs with 48 byte mode as well and doesn't use any extra DMA time (as 40byte and 48 byte is the same when using hscroll) however, there is not enough time in the HBLANK to change two colors as simple as that And considering "Crownland" changes PMG registers as well...

 

Usual there should be enough time to change two colors but of course it depends on actual conditions. In RGB I'm changing three registers on each character line (font and two colors) like this:

dli pha
    stx regx_tmp
    sty regy_tmp
    ldx color2_tmp
    ldy color3_tmp
    lda font_tmp
:4  nop
    sta $d409
    stx $d018
    sty $d019
    ...

High hscroll values helps too as there are some cycles free on left side. I use hscrol 9-12 as ANTIC does show only two chars more on the left side anyway.

[Heaven/TQA]

in my latest project I am using high hscrol values, too.

 

anyway. if RAM is crucial maybe even "small" amount of byte can help and that would be the reason... (but we are talking here about maybe 20x 8 bytes saved...)

[emkay]

Depending on how the engine had been created, it saves also about 3 additional character sets, which means 3K of RAM.

[José Pereira]

Depending on how the engine had been created, it saves also about 3 additional character sets, which means 3K of RAM.

Why? Charsets there if you're talking about Crownland and any other horizontal scrollers depends on the number of total chars that can be organized or not to have different ones on other charlines.

You can have, for example a part where 10charlines just use 1charset where in others 2or3charlines take 1charset deppending on the complexity of the gfxs.

In X:8 we have all the middle part hi-res stars and enemy ships using just and only 1charset and other 1 for the ground (indeed top and bottom are the same because of in A8 you can just Poke and invert/mirror them ).

And you can even save if you can also have the same charset for the status and the font used on the credits and hi-scores screens.

 

Of course that if you are in a static screens you can do the 'mimic bitmap' and if no need of soft sprites you can have:

-> 32Bytes wide screen: 1charset per 4charlines (4x32chars);

-> 40Bytes wide screen: 1charset per 3charlines (3x40chars);

-> 48Bytes wide screen: 1charset per 2charlines (2x48Bytes).

But like I said if you need to use soft sprites or objects like items or bullets above the gfxs you'll end up in more charsets needed across the screen. And here is where my long time talking of the 'Interleaved Charsets' enters to solve the problem :-).

[José Pereira]

I still think like somebody else said that the reason of Crownland final version be in 32Bytes wide screen is because of the PMGs and the way they are used because less wide screen together with the horizontal scrolling you have sooner some going out and can have new ones entering on screen and can reduce more often some of the flicker if more than two multicolour players are at the same line.

They only couldn't reduce the flicker on the last level with the big dragon because it uses all PMGs and if our guy is at same line(s) we have 2Players the same for the two.

[José Pereira]

Or it is and maybe also because they misunderstanding the ABBUC Software Contest rules and thought that a multiload couldn't enter like it was already said here?

Any coder can try to just change the value to have it 40Bytes or 48Bytes wide screen?

Now I am curious to see what we'll get and this is also about the PMGs flicker and playability of the game like knowing what is coming next and sooner manage better way, jumpings and enemys...

[Island2Live]

I am still puzzled about the way Cybernoid is creating more colors than usual on the playfield. As far as I understand there are players involved which mix up with the playfield. So far so good.

 

1st problem: How to mix?

How is the player data mixed with the playfield data to form new colors? I know it's possible with ANTIC mode 2, 3 and $F (40 characters and hires graphics), where the color of the player is taken and mixed with the luminance values of the playfield data. But in other ANTIC modes?

 

2nd problem: Black areas.

When mixing player and playfield data the way I described above a problem with »black areas« arise. When using the player in 4x-wide-mode it covers 8 characters (in for example ANTIC mode 4). So one bit of the player can only cover one complete character ... not partly. The color of the player would always shine through in the background. But in Cybernoid you can't see this.

 

I suspect here a very clever method of using the priority register PRIOR. This forces ANTIC to produce black area when the four priority bits 0 - 3 are used non-exclusive.

[kenjennings]

Colors are OR'd with players, just like two players are OR'd together. It's all controlled by PRIOR register.

 

23 colors are possible per scan line. Discussed on the wikipedia page: http://en.wikipedia.org/wiki/CTIA_and_GTIA#PRIOR_.24D01B_Write

 

 

An alternative to dealing with black (or background) is to use a foreground color as black (simulating background) and the players at lower priority than the playfield. Wherever the foreground color is missing the player colors show through. This allows a super wide player in all its chunkiness to show apparent finer detail color.