Color capabilities question

[+Philsan]

I know that

- we have a 256 colors palette

- we can have more than 5 (16 GTIA modes) on-screen colors programming Antic's display list.

 

What I don't know is what are the drawbacks of increasing on-screen colors.

Obviously there must be drawbacks otherwise all games (perhaps with the exception of scrolling games) would have colorful backgrounds.

Maybe this technique steals CPU time? How much?

 

Thank you!

[Rybags]

5 PF colours + 4 PM colours = 9 colours. Tricky mixing can give 23 colours.

 

GTIA modes give 16 colours.

 

More colourful modes usually mean more memory used, although multicolour text mode gives effective 160x192/5 colours at the cost of about 2K including 1 custom character set.

 

More colour still usually means DLI usage to change colour registers. The CPU penalty can be small, medium, large depending on what's being done.

 

Generally for games the CPU isn't the problem there, it's more often the case of limitations imposed on you by having regions of fixed colour.

 

"All games" ... the fact of the matter is that 98% of games barely push the ability of the system and in many cases could easily have been made to look better.

[Bryan]

The problem is that more color requires CPU involvement and that's a limited resource.

 

For example, a stationary image can have all sorts of color because we don't need the CPU for anything else. You can change colors as fast as you can update the registers. But the complexity of doing this in a game grows exponentially. First of all, let's assume that all the work the game needs to do fits in the VBLANK (although this is rarely the case and won't work at all with CPU intensive things like soft-sprites). Now, we need code to change the colors as objects move around the screen. This could either be DLI driven or a full-screen kernel. But what happens when two different colored objects cross paths? If they're using the same color register we have a problem. If we need to write code to try and find an alternate way to draw them then we have problems. Do we just drop one and have flicker? Do we limit their motion so it can't happen? The more colorful the game tries to be, the more problems you'll run into and the larger the code to manage the colors will be.

 

Certainly there are many A8 games which could be improved, but there's a whole different skill level required between writing a simple textbook Playfield/Player game and writing one that manages the beam in real-time. The A8 is both an easy machine to program that delivers average results, and a royal pain in the ass that delivers spectacular results.

[+JAC!]

Two nice extremes:

- everything from MaPa & PG makes excellent use of the special constraints of the Atari and they design along these constraints (choice of resolution, distribution of color horizonally/vertically, use vertical screen/game concept). I absolutely love everything they release.

 

- my demo RGBA uses TIP full screen mode to achieve 160i*100 pixels in 256 colors which binds the CPU for 100% for the complete visible area and leaves you with almost nothing in terms of CPU to animate any pixel in the underlying 12kb of graphics data.

Edited August 22, 2014 by JAC!

[kiwilove]

In the topic whereby colour counts were given - many of the games didn't appear to use extra colours to advantage. Few Atari games come across - as wow! this game uses more than the standard number of colours.

Some games are let down - not because of the colours - but because of the graphic design.

 

It is possible to make use of the GTIA modes - but you need to work with the very fat (med-res) pixels - and match the designs accordingly. There is a very simple motto for both the programmer/graphics designer to work to: Do what the hardware can do - and don't try something that is too impossible to pull off... Working within the hardware limits may sound rather obstruse (vague) - as well as working it to it's limits. You soon discover what will work, and what clearly doesn't - when you set up tests/demos to see if it does - or doesn't?

 

There are always advantages and disadvantages to whatever system you work with - whether you plan everything down to the last detail - or you just make it up as you go along...

 

I'd guess animation is as important as colours - if you allow for all kinds of animations to be running - the game ought to look good. 3 frame minimum, then 4, then 6, and 8 frame in places? 2 frames where 3 cannot be used (typically for firing/laser animation).

 

Harvey

[Synthpopalooza]

I would also include this attempt that I did, of a modification of Itay Chamiel's multicolor Tetris game using the ICE CIN low-res mode. Of course, the tradeoff is that you have to put up with flicker, altho I'm told that on modern LCD TV's you don't get the flicker.

 

http://atariage.com/forums/topic/211412-the-wall-v-20-tetris-using-ice-cin-mode/

 

It just depends on whether you can put up with the flicker. It does look better on NTSC machines though.

[+Adam+]

The number of colours says nothing about how good the game is. It also can be very misleading in judging how good the graphics is (for example beautiful black and white Amaurote).

[Rybags]

Especially if it's the overdone lame rainbow thing.

 

Arbitrary placement of colour is a much better indicator. Early example there was International Karate - he could have settled for a 4 or 5 colour backdrop but put the effort in with use of PMG underlay and DLI for lifelike landscapes.

[+Adam+]

Philsan, your motto in this thread is "I want more colours" But how would you like to add additional background colours in, let's say, Zybex, with all PMG already used for 2 players and software sprites moving all over the screen? There are not "regions" where you could use independently different colours except the upper and the bottom panel. Would you like to see there some rainbow effect for all playfield colours?

And sometimes the using of less colours is a conscious decision. There exist things like good taste and aesthetics and people who are focused only on technical aspects often forget about it

For example in Deathchase XE we could put multicoloured rainbow on the screen, getting over hundred of colours there, but what for? It would ruin the mood, it would look rather silly, but not better.

It's like if someone would analyse piano compositions and count how many keys are used on the whole keyboard while playing different works on the piano. You cannot say that one composition is better than the other just because more keys are involved.

 

Sometimes less is more, look at some modern games like Limbo.

[+Philsan]

The number of colours says nothing about how good the game is. It also can be very misleading in judging how good the graphics is (for example beautiful black and white Amaurote).

 

 

 

Philsan, your motto in this thread is "I want more colours" But how would you like to add additional background colours in, let's say, Zybex, with all PMG already used for 2 players and software sprites moving all over the screen? There are not "regions" where you could use independently different colours except the upper and the bottom panel. Would you like to see there some rainbow effect for all playfield colours?

And sometimes the using of less colours is a conscious decision. There exist things like good taste and aesthetics and people who are focused only on technical aspects often forget about it

For example in Deathchase XE we could put multicoloured rainbow on the screen, getting over hundred of colours there, but what for? It would ruin the mood, it would look rather silly, but not better.

It's like if someone would analyse piano compositions and count how many keys are used on the whole keyboard while playing different works on the piano. You cannot say that one composition is better than the other just because more keys are involved.

 

Sometimes less is more, look at some modern games like Limbo.

 

 

Adam, perhaps you didn't understand my question.

 

It's a technical question, I know that colors aren't everything in a game (BTW, I played excellent Limbo on PS3 and I gave 8 points to Deathchase XE in ABBUC Contest 2013 - 10 points to Assembloids XE ).

 

And I know that you cannot use DLIs in games like Zybex (in my first post I wrote "otherwise all games, perhaps with the exception of scrolling games, would have colorful backgrounds").

 

I only would like to be able to answer questions people from other platforms ask.

 

For example I would like to know, if we make a 16 color 160x200 static background (C64 like), how much CPU time is stolen?

[Bryan]

For example I would like to know, if we make a 16 color 160x200 static background (C64 like), how much CPU time is stolen?

 

It will be different depending on what you're trying to show. If you just want to change the palette in a few places down the screen, then that can be handled with a custom display list and some DLI code. If you want a lot of colors per scanline then you'll need to throw 100% of CPU time at those regions. So, the answer is, it takes what it takes.

[Rybags]

You could probably say for each DLI where a few quick changes are made, that's a scanline worth of CPU gone.

312 scanlines in PAL, so about 0.333% per DLI.

 

For long running DLI or kernal you generally lose all the CPU in that region.

 

One exception is the Project M engine - he uses Timers instead of DLIs and narrow mode - this frees up some cycles that otherwise would be lost. In most game situations we wouldn't care much but with the raycast + render there every extra saving becomes important.

[+Philsan]

Thank you very much to all!

 

In fact, as Brian pointed out, a 16 (or more) colors 160x200 pixels image can be easy or hard to achieve on A8 depending of what you want to show.

I think we have problems on scrolling games.

 

Regarding CPU time, it takes what it takes.

Gary tried to quantify but I know it's not an easy task, too many variables involved; at least now I have an estimation.

 

Peter's RGB work in progress is a good example of what can achieved on A8 with a good design.

As I wrote in another thread, IMHO RGB engine could be used to make Impossible Mission.

BTW, Peter, I know your demo (with Nils and Adam), it's inside my best demos folder

[ricortes]

About 10 uS per interrupt is a good'nuff number. It will change depending on how you do it. For example, a character mode with ANTIC DL will<may> have 24 DLIs so 240 uS per display. A graphics mode like GR. 15+32 will<can> have 192 DLI or 1920 uS. If you are running a character mode changing the colors every scan line you will be at the 1920 uS per frame because you have to do it with a kernal that does nothing but wait for the screen while it is being displayed. Depending on PAL or NTSC, this time will be used 50 or 60 times per second. 60x240 uS, not to bad, 60x1920 uS is about 115,200 uS or .1152 seconds if I'm not having a brain fart. Figure we lose 1/3 of our processing while ANTIC is on so we are only working with .7 seconds/second to begin with => you lose at least .1152/.7 or just over 16% of your possible processor tics.

[+Adam+]

Adam, perhaps you didn't understand my question.

 

Yeah, you're right, maybe I did not understand what exactly you were trying to ask.

I tried to explain here that there exist also different reasons why there are not many colours in some games - not just CPU.

For example sometimes it's not really possible to add colours if the game is not specifically designed in this respect. Take as an example, instead of Zybex, another Zeppelin game: Draconus, with software sprites that can be put anywhere on the screen and the main character is created from 4 players. Blinky's Scary School is a similar case.

 

Peter's RGB work in progress is a good example of what can achieved on A8 with a good design.

 

You mean Marek's and Zdeněk's work in progress, not Peter's? Yeah, it's a good design, it's also an example of many restrictions used wisely.

[+Philsan]

Adam, you read my mind!

Draconus is a game I was thinking of in these days.

Is it really impossible to program it using 160x200 resolution instead of 160x100?

 

Yes, I know awesome RGB is by MaPa and PG. My sentence was wrong, I am sorry!

I forgot a word: "Peter's RGB work in progress example is a good example of what can achieved on A8 with a good design".

(awful English language sentence!)

[+Adam+]

Draconus is a game I was thinking of in these days.

Is it really impossible to program it using 160x200 resolution instead of 160x100?

 

It's probably possible. I was talking about the number of colours, not the resolution.

[emkay]

Sorry, but Draconus and Zybex were done in GR.7 . There had been NO "Hardware" limit to add several colours in the game though. On a PAL machine probably 50% CPU time is free. And, if it's not, there were surely ways to enhance the game speed , and to remove many bugs. Compared to X:8 (superb job by XUEL) , it has approx. 3 times more CPU for moving objects available. At least 2.5 times...

If you'd use a 100 scanline high kernel for colour changing .... or even NOP commands, it might run at the same speed.

I understand that such a game had to be released to a low credit market , the limits were not in the machine.

[emkay]

It's one of the "last" challenges, to use the GR.7 mode and to add as many colours as possible for a fast game, like Zybex.

Optimisations as in X:8 and colour usage fitting to the game as in RGB, playable as ZYBEX ...

[+Adam+]

AFAIK in X:8 there is no interaction with background at all. And to move one object you just need to move several bytes, several precalculated characters. It's a different situation than in Zybex.

[emkay]

X:8 shows the "double" of enemies and uses PM Overlay for the collectable objects.

And the movement in Zybex is rather limited, as the objects have the same speed as the background. Bit comparision is also "half" , when using double scanline mode. So "byte boundaries" were given. For a reliable looking of the "overlay" only the first and the last byte of a softwaresprite has to be "bit calculated" per graphic line.

[+Adam+]

And the movement in Zybex is rather limited, as the objects have the same speed as the background.

?

Maybe we have played different Zybex games, in my version the majority of enemy objects has completely different speed than the background, sometimes they are slower and sometimes extremely dynamic

 

The memory size of one Zybex animated object is probably about 48 bytes and also there has to be done some masking. In X:8 it's simplified: every enemy ship is drawn by moving 9(?) invariable characters.

But returning to the colour topic: how in your opinion could those dynamic enemy objects get a different colour (than the background)? By dynamic midline colour changes?

Edited August 23, 2014 by +Adam+

[emkay]

?

Maybe we have played different Zybex games, in my version the majority of enemy objects has completely different speed than the background, sometimes they are slower and sometimes extremely dynamic

Have a look at the C64 version. All objects there move freely, except the shots that use the character resolution movement...

 

On the A8, there is a "static" movement, which also causes a Bug that you cannot collect all items.

 

Nothing really to blame with the movement of the enemies. But you could observe how they move and how they change their look and height

 

A 4 line high object doesn't need to be handled as a 16 line high object. The good part is that the "changing" of the height gives a nice animation and the CPU can always be shared...

 

 

 

The memory size of one Zybex animated object is probably about 48 bytes and also there has to be done some masking. In X:8 it's simplified: every enemy ship is drawn by moving 9(?) invariable characters.

 

But returning to the colour topic: how in your opinion could those dynamic enemy objects get a different colour (than the background)? By dynamic midline colour changes?

 

 

 

Using GPRIOR 0 with underlayed big sized shapes of the PMg, and ofcourse colour DLIs , since it's already using 48 bytes, open the border and use a playfield for the background...

The part that really would cost more CPU time, is to create the Protagonists also in software.

Edited August 24, 2014 by emkay

[+Adam+]

For a reliable looking of the "overlay" only the first and the last byte of a softwaresprite has to be "bit calculated" per graphic line.

In Zybex many enemy objects are transparent in the middle and some objects "disappear" when you shoot at them (they become more and more transparent).

 

Have a look at the C64 version. All objects there move freely, except the shots that use the character resolution movement...

On the A8, there is a "static" movement, which also causes a Bug that you cannot collect all items.

I have seen Commodore version and ZX Spectrum version - in all those version collectable items are static (compared to the background) which makes them sometimes impossible to collect. So it's not a "A8 bug", it's a feature in all versions.

You can clearly see such situation in this moment of ZX Spectrum video. I haven't found any long play videos from C64, but we can see that the speed of those items is the same as the background (the link), so every time you kill the enemy while it's entirely over background, you cannot reach it.

Nothing really to blame with the movement of the enemies. But you could observe how they move and how they change their look and height

A 4 line high object doesn't need to be handled as a 16 line high object. The good part is that the "changing" of the height gives a nice animation and the CPU can always be shared...

I'm not sure what you're trying to say here. Yes, a few of Zybex enemy sprites on Atari are designed to rotate vertically (thus they change their height in cycles). Yes, there is possibility to make their movement in such way, that "the sum of their heights" doesn't exceed a specific limit: they would rotate, but in every moment some of them would have to be expanded while the others would have to be "folded". So what is your proposition: "let's make EVERY sprite rotate"? It would be quite boring for the player I suppose. And what about many objects that the player meets during the game, which initially have the same height (and then they become smaller or slowly disappear after every hit)?

Using GPRIOR 0 with underlayed big sized shapes of the PMg, and ofcourse colour DLIs , since it's already using 48 bytes, open the border and use a playfield for the background...
The part that really would cost more CPU time, is to create the Protagonists also in software.

 

The meaning of my previous posts above was:

"In Zybex (and Draconus) we have all PMG already used for the protagonist(s) and we have software sprites designed to be drawn with pixel precision, without any blank space around them, in any place of the playfield. In such situation I find it impossible to add to the existing version independent colours for specific elements."

 

The meaning of your posts is, as I understand:

"In Zybex we can use PMG in a different way, making protagonists as software sprites, we can add specific restrictions, maybe redesign enemy players and their movements, maybe simplify several things (like in "X:8") and that's how we could have different colours for enemy objects."

 

So there's really no difference of opinion here, 'cause we are talking about different assumptions. I agree that when we change a lot in basic Zybex mechanics, we could get more colours, but it would be a different Zybex, with some different gameplay, many specific restrictions, and with (most probably) less diverse, differently looking and moving enemies.

[emkay]

So there's really no difference of opinion here, 'cause we are talking about different assumptions. I agree that when we change a lot in basic Zybex mechanics, we could get more colours, but it would be a different Zybex, with some different gameplay, many specific restrictions, and with (most probably) less diverse, differently looking and moving enemies.

Ofcourse, some mechanics were similar in the C64 version. But you really should have a closer look and compare them . On the C64 "some" objects were at the same speed. On the Atari everything is bounded.

If everything was as "freely" moving as in the C64 version, I'd say "wow".

 

You also stated the "enemies" could use 48 Bytes. Since it's double scanline mode, the enemies use 24 bytes then. If it runs smoothly on NTSC Ataris, you have 60/50 more CPU cycles available on a PAL machine, and you get even lesser cycle stealing.

 

edit:

 

I tried to find a video showing what I'm writing about. But every of those "gamers" miss to kill the necessary attack wave. An example is almost at the beginning of the 1st level, where you can get a powerup that makes the whole level easier. But, you never get that on the A8, because it everytime on the same position, in the background. On the C64 it passes out of the background, so you could collect it.

Edited August 24, 2014 by emkay