View Full Version : info on scrolling games' backgrounds
Marcuz
30 September 2005, 14:20
[BippyM: i post here as it seems you guys knows more about the problem, but please move my post if you think it better.]
i'm working to this (http://eab.abime.net/showthread.php?t=20035) project with Graham Humphrey, i need to figure out how to work up the tiles for the background of the screen. Graham has given me some specific, but i have a general interest on how the stuff was made in the games in the day, consider i'm completely ignorant about it. for instance, how the tiles were managed in Shadow Of The Beast?
in the meadow there was the sky wich was fixed and scrolled; there were clouds and mountains that scrolled at different velocities and some level of the ground, again scrolling at different velocities. was the whole screen flat with tiles mapped to specifical places? or was it like differents layers one above the other?
i clarify with another exemple: Project X, in the space: you have the skyscape the size of one screen always the same and variety was given with the occasional dust cloud/nebula/planet. were those mapped to be contiguous to the other tiles, on the same level, or were those big objects floating on the carpet?
in the first case i need to create a map, in the second case it's like the occurrences are scripted to appear at some particular time etc.
can you clearify with some exemple for me?
thanks!
bippym
30 September 2005, 20:14
hehehe ;)
Moved to Coders HEaven as you wanna know about parallax scrolling (I think) and also how to join the maps together!
I am not 100% certain but you need to use an array or similar and for example you give each map tile a number.
Then the map data would simply be a layout of the level with the number in place of the tile, the game can then drop the proper tile onto it :D
I *think* that is what you are asking.. though I could be wrong!
Marcuz
30 September 2005, 20:54
thanks BippyM, it is exactly this, but i also believe that it has been handled differently in different games; or so i assume, where for instance part of the scenery overlaps the background by mooving, as the big ballons in the sky in SotB
bippym
30 September 2005, 21:15
If they move independantly then they are probably sprites or bobs..
Parallax scrolling is achieved by having 2 (or more) layers.
Each layer (Front/middle/back etc..) will be used just like a single display.. you simply draw onto that plane, to show the background through the front pane you simply make some of the forground plane transparent :D you then scroll each plane at a diff speed (So if the front plane is scrolling faster than the back plae it would have to be physically bigger than the back plane).
One of the coding guru's would be better at this than me :D
Codetapper
01 October 2005, 00:13
There are 2 main ways to achieve this on the Amiga:
1. Dual playfield mode. If you setup the game with 2 playfields of 8 colours, you effectively have 2 maps. Where colour 0 is set in the front playfield, you will see the colours from the back playfield. The Amiga has hardware for scrolling these 2 playfields independently so you can make the front one scroll 2 pixels while the back one scrolls one. Check out Soccer Kid for an example.
2. If you are prepared to have a more repetitious background, you can "cheat" by repeating sprites hundreds of times as the screen is being drawn. This will simulate a second layer with 16 colours. You waste a lot of memory building up an enormous copperlist but you can effectively have a lot more colours than with dual playfield mode. Check out Risky Woods or Leander for an example - note that the background repeats regularly.
Most games in the early days used dual playfield mode, and later on the sprite trick method became more and more popular. Shadow of the Beast uses dual playfield mode in addition to sprite tricks, and the background layer itself appears to have about 10 layers due to adjusting the copperlist at various points in the display.
Marcuz
01 October 2005, 03:10
Codetapper: thanks, that's exhaustive :)
last question: by what are limited the palettes of the different playfield in one case and of the different sprites in the other? i mean, provided that however on screen there should be a certain number of colours as a maximum based on the chipset, is there a constant maximum indicated by (i put it roughly) number of sprites and size of them X number of colours on palette used? like a memory size you can't go past?
Codetapper
01 October 2005, 06:12
In dual playfield mode, one playfield uses colour palette entries 1, 3, 5, 7, 9, 11, 13 and 15. The other uses colours 0, 2, 4, 6, 8, 10, 12, and 14. If you put sprites over the top of the 2 playfields, you can gain another 16 colours - OCS/ECS sprites use colours 16-31.
If you skip dual playfield mode, you can use all 32 colours (pens 0-31) for the graphics as the background (made up of sprites) will only be visible where colour 0 has been drawn. You have to be very careful when choosing colours though as the sprites will share whatever colours are in palette entries 16-31.
I'm not sure what you mean by the maximum size stuff - if a game doesn't need 50 frames/second updates, you can happily run 64 colours on an ECS Amiga. (Super Cars 2 for example uses halfbright mode so 64 colours).
Games that don't update much of the screen (eg. All Terrain Racing) can easily run at 50 frames per second in 32 colours without double buffering the display.
Lots of older games like Turrican 2 reduced the main action to 16 colours to keep it as fast as possible. Turrican 2 had sprites over the top (eg. the player) and the old background copperlist to emulate more colours. But it's basically a (damn fine) 16 colour game.
Rodland is another interesting case as the game is only 16 colours and 256 pixels wide, but they draw the screen far over to the left then use sprites to draw the score panel on the right.
Marcuz
01 October 2005, 15:44
ok, understood thanks.
i've still a more practical question.
i'm working now on indexed palettes on PC side, using GIF files for colour proof, i will then convert them on iff but still on pc side. i use 4 and 16 colours palettes, with or without a transparent colour. the question:
will the amiga invert or scramble the order of the palette? i believe any pixel refers to a given position on a colour table: the transparent colour or color zero needs to be in the first position of the table? or can i forget all of this and work as the two sides are completely compatible?
bippym
01 October 2005, 18:46
my advice is to use the amiga and determine the colours.. then do the work on PC using correct colours and finally load into DPaint but use the palette you originally set, DPaint (should) be able to fix the gfx to the new palette
Marcuz
01 October 2005, 18:58
good advice, the problem to me is only that i state the colours on pc because is easier to do corrections to the tones on photoshop, at least to me, than on amiga. however, i will try that and also i give you this link to a free painter program much like DPaint (also the interface is similar to the amiga 'one) but on PC, for the ones that want to try it. i suggest to use a resolution < or = to 800*600:
http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Editors/Grafx2.shtml
gifgit
01 October 2005, 19:15
:agree GRAFX2 is a cool program,I used it to make most of my sprite rip sheets.Anyone who has used Dpaint will be at home with this program.;)
Codetapper
02 October 2005, 00:22
You can easily remap the colours later on the Amiga in PPaint if the PC programs screw them up anyway. Simply load the picture, load the correct palette and hit Remap and you're done.
Marcuz
02 October 2005, 11:42
You can easily remap the colours later on the Amiga in PPaint if the PC programs screw them up anyway. Simply load the picture, load the correct palette and hit Remap and you're done.
this was very useful, thanks :)
as a side note, is there a program that can convert iff palettes (.col) to pc palettes (for photoshop they are .act files)?
vBulletin® v3.7.0, Copyright ©2000-2013, Jelsoft Enterprises Ltd.