Anyone ever thought in ways to get RAINBOW ISLANDS on A8

[sack-c0s]

the C64 does a decent job of the game. Yes the Atari has no sprites but to be honest the 64 version tends to outstrip the available sprites and end up using character graphics anyway and the Atari has a bit more CPU grunt behind it which should avoid any stuttering or slowdown.

 

I'd just forget the 'getting the highest quality graphics' argument for the moment - people who want that can just play the arcade version. It's a game (not a demo) and the objective is for it to be smooth and fun. I reckon that can be pulled off.

[Synthpopalooza]

Another idea ... Super IRG for the display, making most of the graphics based on the primary colors ... PF0 - PF3, which when used by themselves, don't flicker ... set PF0-PF2 as red, yellow, and blue ... on the rainbow, you could mix PF0 and PF1 to get orange, PF1 and PF2 to get Green, etc. Careful choice of the colors would reduce flicker, as you aren't changing color registers, you can use a checkerboard antiflicker dither. I think if you used the colors, like in Space Harrier, it could look decent.

[José Pereira]

Could you get a static screen to try irg?

The first level, the one with blue sky and brick walls, like this:

- gfxs:

pf0 blue sky

pf1 wall bricks light colour

background bricks lines darker colour

pf2 green plants

pf3 white clouds

 

 

then second irg font for the rainbows you choose the looking and the appropriate (colours,luminances).

 

 

 

I never understand very well the flicker's reduce luminances and colours... But really like to see something super irg (if there's possibility with less flickers than that old puzzle game).

Thanks.

[Synthpopalooza]

This is a preliminary screen ... just a rough sketch:

 

Original Amiga

 

Test Super IRG render

 

This is not an actual final screen, but it gives you some ideas what the rainbows will look like. In this example, there is some mixing of PF2-PF3 due to screen flipping, the actual game will not allow for this ... so instead of 15 colors, it's only 14. Also ignore the player sprite, I imagine we'd be using PMG's for him.

 

This is also just the playable area, there would be two lines above for the score (you can use a normal non interlaced mode for this, maybe antic 2), and a line at the bottom for lives left

 

I did this from an Amiga screenshot as its closer in resolution to the Atari. What I am going to do next is to render a single optimised font from this screen, load them into ICE editor and see if I can spruce up the colors and graphics some more, then render a test screen.

[Synthpopalooza]

Ok, I have results! Keep in mind, this is just some hack coloring of the fonts using ICE editor, after converting an Amiga screen using G2F, with character optimization on.

 

As per your request, I used these base colors:

 

PF0 - Sky (light blue)

PF1 - Bricks (yellow)

PF2 - Trees (green)

PF3 - Clouds (white)

BAK - grouting in the bricks (dark red)

 

When these colors are set in ICE IRG, using Super IRG mode, you get this color palette:

 

 

You will note that the top bar is normal mode colors, the bottom is inverse mode colors (PF2 combos replaced by PF3) ... there are 10 possible colors per character cell and 14 overall colors usable in this mode. Some of the PF3 colors (bright pink, bright orange, and a higher level grey) did not get used in this screen. If we are using character sprites, these colors might well go for the player sprite, you'd just have to watch out for PF2-PF3 conflicts whenever the green color and any combinations using it, are encountered,

 

At the very bottom, the squares represent the base colors of this mode ... anytime you use these base PF colors (and the BAK color), they will never flicker. Using the combo colors, offsetting them from each other in a checkerboard pattern reduces the flicker.

 

You will also notice that a 6-color rainbow (red orange yellow green blue purple) is also possible with these settings. Also, the grey shade used for some of the platforms, is actually a blending of PF0 (blue) and PF1 (yellow) ... when you blend two colors from opposite sides of the color wheel, the result is a grey.

 

Here is the original Amiga screengrab, followed by the Super IRG screen, and the .ATR ... boot the ATR and RUN "D:RAINBIS.TUR".

This looks best on a real Atari. Emulators will show horrible flickering ... tho you can eliminate this by using Frame Blending on Altirra.

 

Amiga Original

 

rainbow islands demo screen - super irg.atr

 

 

I have also included the D:ICEIRG.TUR font editor on this ATR if you want to play around with the font any further ... the font name is D:RAINBIS.ICE ...

 

The colors on this demo were set using the NTSC palette ... you can play around with the palette settings on this font in ICE IRG to readjust for PAL, and re-save the ICE file, and the display program will then load the new color settings the next time you run it.

Edited September 15, 2012 by Synthpopalooza

[Xuel]

Wow, the flicker is not that bad. +1!

[miker]

Check on PAL machine then...

 

Edit: Not bad indeed, but checked on LCD monitor.

Edited September 15, 2012 by miker

[Synthpopalooza]

You will get worse flicker on PAL than NTSC, because PAL's refresh at 50 hz while NTSC uses 60 hz. The key, is that most of the graphics should be heavily based on the primary non-flickering PF colors (yellow, light blue, white, green, dark red) and the blended colors used as accents.

[sack-c0s]

sorry for not being that clued up on this one - but the overhead with superIRG are memory because you need 2 charsets and you'd need to double up on softsprite processing but other than that it's just a different set of charset switches on odd/even frames?

[Synthpopalooza]

That's all it is, a character set switch between two frames, no color changes, screen changes, or display list changes needed. In fact the softsprite processing itself would probably not change (still only need 960 bytes for the screen), you just need double memory for the character sets.

Edited September 16, 2012 by Synthpopalooza

[sack-c0s]

That ain't bad at all if you can get the colour selection right. I'll have to have a play with that one...

[José Pereira]

That's all it is, a character set switch between two frames, no color changes, screen changes, or display list changes needed. In fact the softsprite processing itself would probably not change (still only need 960 bytes for the screen), you just need double memory for the character sets.

Never understand some things about Super IRGs Modes:

 

1.)- We have two charsets, right? Rainbow Islands as an example, can I have like this:

-> Charset1: Platforms and Walls

-> Charset2: Clouds and Trees(or other combination because of the appropriate (colour,luminances) to reduce flicker)

(and then Mix of the two to produce new/more colours on the Rainbows)

 

 

2.)- I know that BACKGROUND Register must be the same in the two charsets and then two charsets doubles the other PFs.

Thinking simple it would be: 2x(PF0,PF1,PF2,PF3).

a.)- If, for example, charset1/char1 it's a Brick then charset2/same char1 it's next and it's a Cloud we get each ot them with their own colours (each frame displays one of the charset and some flicker because of this)?Like this SuperIRGs would only display 9colours, right?

b.)- To get the 14colours it's because of what? You're displaying the two chars of the two charsets at the same (x,y)Pos so, at 50/60th of second the colours of the two charsets seemed mixed and just one.

 

 

3.)- If all of my previous two points are correct then with what will I get less flicker (colours and luminances choosing apart), '2.a)' or '2.b'?

Edited September 17, 2012 by José Pereira

[Synthpopalooza]

How Super IRG works is, the two character sets are blended over the entire screen ... There are no screen map changes or display list changes, you get only the normal 128 characters in Antic 4, but CHBAS (756 decimal, shadow register) is changed every VBLANK. There are no color changes done at all, just the character set ... which will get you 10 colors per character cell ... 4 of these (the ones based on mixing PF2) will change when you use inverse, for a total of 14 colors. The equivalent of this in bit map mode would be the Interpainter mode (interlaced Graphics 15 with no color palette changes).

 

So you basically have your primary colors (in this case dark red, light blue, yellow, green, and white for inverse) ... the other colors are a result of blending of these primary colors.

 

This is illustrated in this graphic:

 

 

This is cut from an ICE editor screenshot ... the bar on the left shows the normal colors, and the bar on the right shows inverse.

 

Colors 0, 5, A, and F on these bars are your primary PF colors (BAK, PF0, PF1, PF2/PF3) and will never flicker.

 

The other colors are the result of the mixing of these colors. These occur in pairs, because you can mix the primary PF colors on different frames, in this case:

 

Colors 1 and 4: BAK + PF0 (dark purple)

Colors 2 and 8: BAK + PF1 (orange)

Colors 3 and C: BAK + PF2/PF3 (dark green - normal / light purple - inverse)

Colors 6 and 9: PF0 + PF1 (grey)

Colors 7 and D: PF0+PF2/PF3 (dark blue - normal / light blue - inverse)

Colors B and E: PF1 + PF2/PF3 (green-yellow - normal / light grey - inverse)

 

So, using the primary colors comes about when you use the same PF or BAK color on both frames ... PF0+PF0=PF0, PF1+PF1=PF1 etc. These do not flicker at all.

 

When you use secondary colors, you want to place the color pairs on alternating pixels on the grid, like this:

 

 

This is called antiflicker dithering. This produces a better result than the full frame flicker of two solid colors ... so, if you wanted to produce a solid field of dark purple (BAK+PF0) you'd do your character like this:

 

1 4 1 4

4 1 4 1

1 4 1 4

4 1 4 1

1 4 1 4

4 1 4 1

1 4 1 4

4 1 4 1

 

I have the ICE editor and the RAINBIS.ICE file on the previous ATR, so if you want, you can load the file, play around with it, and see how the colors work.

Edited September 17, 2012 by Synthpopalooza