Flimbo's Quest

[Allas]

I'm thinking about to implement parallax scroll technique in Atari. I don't remember a game or demo that use parallax scroll in the same line.

 

First I'm studing how can be in C64 , in Flimbo's Quest Game.

 

 

I imagine we need escencially 3 bitmaps in memory:

 

1 - First bitmap that contains the graphics in primary plane (holes with pattern color 00)

2 - Second bitmap that show the holes in primary plane (holes with pattern color 11)

3 - Third bitmap that contains the background graphics

 

Parallax image = 1 v ( 2 ^ 3 )

 

For example:

 

1- 10 11 00 00 00 00 01 11 <--- Primary plane

2- 00 00 11 11 11 11 00 00 <--- Hole map

3- 11 01 00 11 10 01 00 10 <--- Secondary plane

 

P- 10 11 00 11 10 01 01 11 <--- Parallax Pattern

 

It appears to me works fine...

 

In Flimbo's Quest there is a adicional combination of map color mode. But When study the screen in C64 I see 5 colors per 8x8 cell: Brown, Yellow, orange, black and light blue. I thinked C64 get 4 colors per 8x8 cell, It's a trick or I'm wrong with hardware capacibilitie C64.

 

In other way, I want to know if my teory is right or there is a better way to get parallax scroll. I wait too much numbers don't confuse.

 

Someone remember a demo or game in Atari with Parallax scroll in the same line. Moonpatrol, James Bond Living days Light, use parallax technique but don't get parallax in the same line.

Edited November 7, 2005 by Allas

[Dr. Van Thorp]

I'm thinking about to implement parallax scroll technique in Atari. I don't remember a game or demo that use parallax scroll in the same line.

 

First I'm studing how can be in C64 , in Flimbo's Quest Game.

 

 

I imagine we need escencially 3 bitmaps in memory:

 

1 - First bitmap that contains the graphics in primary plane (holes with pattern color 00)

2 - Second bitmap that show the holes in primary plane (holes with pattern color 11)

3 - Third bitmap that contains the background graphics

 

Parallax image = 1 v ( 2 ^ 3 )

 

For example:

 

1- 10 11 00 00 00 00 01 11  <--- Primary plane

2- 00 00 11 11 11 11 00 00  <--- Hole map

3- 11 01 00 11 10 01 00 10  <--- Secondary plane

 

P- 10 11 00 11 10 01 01 11  <--- Parallax Pattern

 

It appears to me works fine...

 

In Flimbo's Quest there is a adicional combination of map color mode. But When study the screen in C64 I see 5 colors per 8x8 cell: Brown, Yellow, orange, black and light blue. I thinked C64 get 4 colors per 8x8 cell, It's a trick or I'm wrong with hardware capacibilitie C64.

 

In other way, I want to know if my teory is right or there is a better way to get parallax scroll. I wait too much numbers don't confuse.

 

Someone remember a demo or game in Atari with Parallax scroll in the same line. Moonpatrol, James Bond Living days Light, use parallax technique but don't get parallax in the same line.

961424[/snapback]

 

For the record, the C-64's multi-color hight-res mode uses 4x8 cells.

 

It looks like the graphics in this game were very carefully designed to that, even though there are more that four colors in the background (I see purple, yellow, two brownish tones, and black) there are only four colors per 4x8 cell.

 

You could also get around this limitation by using multiplexed sprites for parts of the front scrolling layer or primary plane. In your sample picture, the back plane, with the rock shapes, looks simple enough that you might be able to do it with sprites. If you can manage to create one of the scrolling planes entirely from sprites, this will same a lot of code and a lot of run-time proccessing time.

 

And if you are using a "00" pattern in memory to represent holes in the primary plane, then you don't need need a hole map. The 00's are a build in hole map.

[Allas]

For the record, the C-64's multi-color hight-res mode uses 4x8 cells.

 

Yes, that is I want to say 4x8 med res.

 

It looks like the graphics in this game were very carefully designed to that, even though there are more that four colors in the background (I see purple, yellow, two brownish tones, and black) there are only four colors per 4x8 cell.

 

Yes, I noticed there are only 4 colors per cell, but I think C64 couldn't scroll the color map, only the bitmap.

 

You could also get around this limitation by using multiplexed sprites for parts of the front scrolling layer or primary plane. In your sample picture, the back plane, with the rock shapes, looks simple enough that you might be able to do it with sprites. If you can manage to create one of the scrolling planes entirely from sprites, this will same a lot of code and a lot of run-time proccessing time.

 

Sure, It's a good way...

 

And if you are using a "00" pattern in memory to represent holes in the primary plane, then you don't need need a hole map. The 00's are a build in hole map.

961432[/snapback]

 

Pattern "00" in primary plane can be color 0 or only a hole. The hole map make the difference. In this way can be used all 4 colors and we don't lose 1 color.

[Heaven/TQA]

i have converted Flimbo's gfx to Atari in a small parallax demo which i have posted here months ago (or years?).

 

flimbo uses 4 fonts and the background gfx is preshifted in memory so actually while scrolling left and right flimbo seems to flip through the fonts and this gives you an illusion of parallaxing... of course the foreground is painted over the background but that's nothing special as on commie in general you are doing that when you are playing with scrolling...

 

i have to look where the demo file lies.

[Heaven/TQA]

just found the topic...with the demo...

 

it's from 2002... huj...boy... times goes by...

 

http://www.atariage.com/forums/index.php?s...18341&hl=flimbo

[Allas]

just found the topic...with the demo...

 

it's from 2002... huj...boy... times goes by...

 

http://www.atariage.com/forums/index.php?s...18341&hl=flimbo

961479[/snapback]

 

 

Wow!! excelent!! a parallax scroll with font graph mode... very cool. This is the real way C64 go.

 

And a question... you found the error and put 2 planes move in different speed?

 

Only 4 fonts? are you sure?

Edited November 7, 2005 by Allas

[TMR]

Yes, I noticed there are only 4 colors per cell, but I think C64 couldn't scroll the color map, only the bitmap.

 

The C64 can scroll the colour RAM, but it can't be banked so has to be done single buffered.

[Jetboot Jack]

Both Contagion and Plastron used simple versions of this technique, as does Adam Billyard's Bellum too - all on the little A8

 

sTeVE

[Allas]

Yes, I noticed there are only 4 colors per cell, but I think C64 couldn't scroll the color map, only the bitmap.

 

The C64 can scroll the colour RAM, but it can't be banked so has to be done single buffered.

962227[/snapback]

 

 

The C64 is the king of the font graph modes, I apreciatte much those hard code level tricks based in fonts to display parallax , 3D, giant sprites, motion. Only it's a pity that they are not scalable.

 

 

*** Really Contagion is parallax (in the same line)... I've never had take count on this... thanks

Edited November 8, 2005 by Allas

[Allas]

Yes, I noticed there are only 4 colors per cell, but I think C64 couldn't scroll the color map, only the bitmap.

 

The C64 can scroll the colour RAM, but it can't be banked so has to be done single buffered.

962227[/snapback]

 

 

This a question out of topic, but I think you could answer me. I heard a long time ago a C64 demo that can put graphics in the margins. I don't know the demo name and never saw for study.

 

My questions are, if it is posible:

 

- How can get access to the margins

- How C64 can break the 40 bytes barrier per line screen, or just only a visual trick?

 

Mario

[Heaven/TQA]

i would assume that they used sprites with nasty raster interrupt tricks to open the boarders... but i am not a commy...so maybe TMR can answer...or froehn.

[TMR]

This a question out of topic, but I think you could answer me. I heard a long time ago a C64 demo that can put graphics in the margins. I don't know the demo name and never saw for study.

 

There's a couple of thousand demos do it... keep reading, i'll name some more examples but it's also worth checking Deus Ex Machina by Crest, Royal Arte by Booze Designs and Cycle again by Booze.

 

- How can get access to the margins

 

Border work is divided into two, upper and lower borders is done with the vertical scroll register and side borders with the horizontal scroll register; essentially "all" that is done is using the change between 25/24 row mode or 40/38 column as appropriate to confuse the VIC-II into thinking it's already closed the border and not bothering to do it. For upper and lower that's pretty easy, waiting for rasterline $f9 and writing $4 to the vertical scroll register's low nybble, then waiting for rasterline $fc and writing $B does the job and it's not particularly timing heavy.

 

Sideborders on the other hand are much nastier because the changes to the horizontal scroll reg need to happen at cycle precise places in order to work, it works on a scanline by scanline basis so a 200 pixel high screen needs 200 rasterlines of changing the scroll register to keep it open, the the cycle timings per scanline change if it's a badline and putting sprites over the routine shunts things around again, so what appears to be quite simple is an utter bitch to actually do! But it gets done and sometimes to incredible effect, it's an oldie but UpFront's Freezer not only puts 14 sprites in the border over a picture in the second part (you have to wait for the rasters to disappear, it's controlled by the scroller) but they're moving vertically.

 

- How C64 can break the 40 bytes barrier per line screen, or just only a visual trick?

 

The screen never changes size (well okay, with a bit of trickery it's possible to repeat the last 7 scanlines of the final line into the lower border and Royal Arte does that at one point) so anything that appears in the borders has to be rendered with the sprites or, if it's a repeated 8 bit wide pattern, the last byte of the video bank gets tiled into the space in the upper and lower border.

 

If you want to see something "impossible", have a look at Irrational by Chorus, in particular the part in the screenshot on the CSDb; The logo is on the screen and goes into the sideborders, the bitmapped picture scrolls very fast considering the C64 can't officially change the origin point of it's screen like that and the word "Irrational" is in the lower border. Which is neat, since it's ten characters long and it's not possible to recycle a sprite into to positions on the same scanline... =-)

[TMR]

i would assume that they used sprites with nasty raster interrupt tricks to open the boarders... but i am not a commy...so maybe TMR can answer...or froehn.

970002[/snapback]

 

Pretty much yeah, sprites, hardcore raster tricks, features of the hardware smooth scroll registers and whatever other ideas people've come up with. For best effect when watching C64 demos, mark the corners of the screen with a bit of Blu Tac and if it goes outside those boundaries it was a sprite. If it goes out sideways, it was bloody hard to to, an' all. =-)

[Allas]

Reviewing the Adam Billyard production I found this simple interesting game with parallax efect. I never saw it before.

 

Bellum

[Heaven/TQA]

bellum seem to use players/missles for the starfield and the planets in the background as they cross the sideborders where the playfield does not... it would be so easy to cover this simply by using wide playfield mode...

[Fröhn]

- How C64 can break the 40 bytes barrier per line screen, or just only a visual trick?

The C64 screen is hardwired to 40 bytes per line. You can consider that the price the C64 has to pay for it's relatively big sprites because the clock cycles in the side border area are used for the sprite DMA. This also means that anything which is displayed in those sideborders has to be build up from sprites.

[Heaven/TQA]

ah....that makes sense... thanks, Fröhn.

[Allas]

- How C64 can break the 40 bytes barrier per line screen, or just only a visual trick?

The C64 screen is hardwired to 40 bytes per line. You can consider that the price the C64 has to pay for it's relatively big sprites because the clock cycles in the side border area are used for the sprite DMA. This also means that anything which is displayed in those sideborders has to be build up from sprites.

992662[/snapback]

 

Then, I undestand C64 hasnt DLI programming ?

[Heaven/TQA]

it's called rasterinterrupt...

[Allas]

it's called rasterinterrupt...

992682[/snapback]

 

But, thats time when the beam is on painting screen?

[Fröhn]

Then, I undestand C64 hasnt DLI programming ?

Yes, you select a graphic mode and then the VIC-II will display without any display list or CPU intervention. The VIC can generate raster interrupts though, so if you want to do screen splitting you can tell the VIC to cause an interrupt at any rasterline you wish (unlike DLI you can have raster interrupts in the middle of a character line).

[analmux]

[Happy New Year to everyone]

 

Then, I undestand C64 hasnt DLI programming ?

Yes, you select a graphic mode and then the VIC-II will display without any display list or CPU intervention. The VIC can generate raster interrupts though, so if you want to do screen splitting you can tell the VIC to cause an interrupt at any rasterline you wish (unlike DLI you can have raster interrupts in the middle of a character line).

992705[/snapback]

 

????

 

Are you sure?? I thought c64 can only generate raster interrupts at beginning of a certain rasterline....

[sack-c0s]

[Happy New Year to everyone]

 

Then, I undestand C64 hasnt DLI programming ?

Yes, you select a graphic mode and then the VIC-II will display without any display list or CPU intervention. The VIC can generate raster interrupts though, so if you want to do screen splitting you can tell the VIC to cause an interrupt at any rasterline you wish (unlike DLI you can have raster interrupts in the middle of a character line).

992705[/snapback]

 

????

 

Are you sure?? I thought c64 can only generate raster interrupts at beginning of a certain rasterline....

993500[/snapback]

 

that's true... you have to manually wait until the middle of the line

[emkay]

that's true... you have to manually wait until the middle of the line

993562[/snapback]

 

 

It's almost the same as the charmodes on the A8...

[TMR]

that's true... you have to manually wait until the middle of the line

993562[/snapback]

 

It's almost the same as the charmodes on the A8...

993734[/snapback]

 

No, with char modes on the A8 you can only trigger a DLI at the start of each char line; raster interrupts trigger on the scanline y'ask for, regardless of screen mode.