Games that didn't scroll smoothly - why not?

[Hungry Horace]

Originally Posted by TheCyberDruid

Normally the Bitmap Brothers had a real good taste and the colours they choose where great,

play Speedball 2 CD32 or Chaos Engine 2 and you might change your mind


i'm in massive disagreement with those who say Battle Squadron looks better than Xenon II - number of colours is totally irrelevant. Piet Mondrian would often do paintings with no more than 5 or 6 colours... does that make his art worse than that of mine because i happened to throw 32 colours on a canvas at random?

The graphical style of most Bitmap's games, especially games like XII are second to none. Unique and gorgeous.

a hard game, but so what? games are too easy these days. the powerups, graphics and sound are just great, and my eyes are far from bleeding with the scrolling. look at NZS on the speccy... the scrolling is awful, and the game is monochrome, but it still plays better than its blocky c64 counterpart!

[TCD]

Originally Posted by Retro-Nerd

@CD

Compare the She-Fox/Vixen C64 and Amiga versions.

Wow, that scrolling is really jerky on the Amiga What is it 10 FPS or so? Probably a nominee for the worst scrolling in a game on the Amiga

Originally Posted by Hungry Horace

play Speedball 2 CD32 or Chaos Engine 2 and you might change your mind

That was why I said normally

[Old Fool]

There's no use to point Ruff'n Tumble for a bad scrolling. It is a mindblowing beautiful game for A500 and it runs smoothly considering the quality of the graphics. Totally playable and a great game! I could make an endless list of Amiga games that look like C64 games and have so bad scrolling that no one can't play them...

[Marcuz]

if i was to say, out of the blue, in 2008, my reason why many amiga games of 20 to 15 years ago, had a poor scroll, i would say that's the fact that what you see on screen, the visual aspect in a good amiga game is built through routes and tricks a graphic designer don't understand easily.

of course, that could have been different then, i know nothing about it. i can only report my difficulty to understand parallaxes, fixed and non fixed palettes, copperlist, lines etc: so either a coder is also a graphician and he knows what he is doing (the more you go back, the easier that could happen: CBM64 etc) or a coder has a graphician learned in amiga display.

even if i tryed to help on Annihilation and the EoB aga and so i read the discussions involved, only thing i can see, for instance, in a game like SotB, is count on my fingers the levels of parallaxes, and wrap my mind around the concept that there is bound to be a transparent colour!

short of that you need to stick to the more basic and heavier on the memory ways to render a moving scene.

[Codetapper]

A few technical details to consider. I will assume a horizontally scrolling only game for this example and a tile is 16 x 16 pixels:

A full PAL screen in 32 colours is 320 x 256 x 5 planes = 51200 bytes of memory. To scroll sideways you need at least another column of tiles on the side which you smooth scroll onto the screen = 53760 bytes.

If you cannot guarantee your game will run every frame, you will need to double buffer everything. Another 53760 bytes gone.

If you want a parallax layer (say 2 rows of tiles) over a 5 bitplane display, you will need to mask those onto the display. 2 rows of tiles x 42 tiles x 5 planes will need to be drawn over the display whenever you scroll. eg. You scroll 2 pixels left, you will need the parallax layer shifted 1 pixel. That seems a hell of a lot of DMA time used when you add it up as you are effectively redrawing about 50% of the screen (2 rows x 5 planes)

If you decide to use a repeated sprite for the parallax layer, you face other limitations. It can only be 4 colours, or 16 if you bolt two of them together. You don't have enough DMA time left to change the sprite horizontally if you are going to repeat it across the display, so you have to have a small pattern repeated. eg. Risky Woods

If that's too much trouble, dump any parallax scrolling and then people complain that it doesn't scroll like the arcade version did!

Now you need some memory for your tileset - 2 entire screens of tiles will eat another 102,400 bytes of memory. You need your player and enemy sprites now, another say 4 screens worth would be a minimum. 204,800 bytes gone.

Add a few kb more memory for a copperlist or two (or if you are repeating sprites, you can easily use 50kb!) and you can see why it is difficult to get an entire game into 512k chip memory!

Now before anyone says you can compress all the graphics - not really. You have to either unpack them before you draw them (a problem if you have a big set of tiles), store them in a more efficient manner (eg. work out offsets for the tiles into memory so you store an offset into memory for each one), or do something very clever that I haven't thought of!

I'm not aware of any method that allows you to draw masked graphics onto the screen without having them unpacked. Masked graphics are required where you want a weird shape (eg. the player!) drawn over the display without erasing the background behind it. Also any graphics that partially obscure the player and background (eg. the trees in First Samurai, or the tables in Arabian Nights) also must be stored uncompressed and with a mask so they can be blitted onto the screen.

Plus more chip memory needed for sound! It's amazing any 512k games were made! :-)

You also obviously need some memory for the game maps, remember which tiles need to be redrawn, and the code - but that can reside in expansion memory.

I could be wrong with some of this, if you know better please yell! Now...

I just loaded Ruff'n'Tumble, and to me that does not look like it's 25fps - the scrolling really is quite bad on the eyes. Ditto games like Aladdin, Lion King or Cool Spot. Cool Spot is absolutely shocking imho. It would have been far better to dump the background layer and scroll smoothely. The screen isn't that big either, as there is a panel at the top and then borders around each edge. I am having a guess here but perhaps Cool Spot is only updating 12 frames per second?

PS: It would make a cool info section for HOL if people that know technical details about various games could write up information such as how many colours, screen size, scrolling, sprite tricks used etc... It would be very interesting stuff imho!

[TCD]

Originally Posted by Codetapper

PS: It would make a cool info section for HOL if people that know technical details about various games could write up information such as how many colours, screen size, scrolling, sprite tricks used etc... It would be very interesting stuff imho!

Thank you for the technical information codetapper It made clear why many ganes really needed the 512 KB expansion for A500.

I second the idea about the technical ideas thread. It could be made sticky in the prb.Games section. Will be very interesting to read about some details of the games we play

[Marcuz]

ditto, it would be a cool addendum to HOL.

by the way, i haven't understand the majority of it, and that's my point: to build a cool design and great graphics and over that structure and make it all move it's really difficult: couple that with great scrolling too is a gem!

[Codetapper]

A quick analysis of Sonic Boom (c) Activision:

Game area: 256 x 193 (equivalent of 16 tiles wide x 12 and a pixel high)
Double buffered display (buffer 1 = $70000, buffer 2 = $78000)
16 colours at all times (4 bitplanes), no sprites, modulo = 120
(Game stores a row of each of the 4 bitplanes in turn, then the next row of data)
Game redraws the entire display each update, there are no clever scroll tricks or copper split (no doubt due to ST compatibility)
Display is switched every 3 frames, so runs at ~17fps (PAL). You can alter the frame rate in WinUAE as follows:
W 117b x
Where x = (frames - 1) to wait before updating display, defaults to 2 (meaning a screen refresh every 3 frames = 17 fps). To update every 2 frames, W 117b 1 so 25 fps update. Game runs fine on level 1 at 25fps most of the time, but when there are loads of baddies and bullets it will slow.

[Retro-Nerd]

Ruff'n Tumble has no jerky scrolling, as i said before. At least nothing noticeable on a A1200 machine.

But what causes the annoying blur in motion? Lazy screens updates? You can see it in Wolfchild too.

[Old Fool]

It would have been great if Team 17 would have sold the engine from PROJECT-X to other software companies. Then we could have had lots of perfectly scrolling SCHUMPS..

[TCD]

Yep, Project X is one of the very smooth shoot 'em ups. It has many enemies on screen at the same time and is quite colorful. Would have been great to have more games based on that engine.

@Retro
You are right about Rugff 'n Tumble and Wolfchild. Scrolling is not bad, but still it looks wrong to the eye. Maybe codetapper has a clue what's goning on in these games

[Galahad/FLT]

Originally Posted by oneshotdead

Galahad/FLT:

You don't seem to be pig-headed about X2 like some others here are, so I was wondering if you would deign to explain to me some things...

(By the way, I agree that Battle Squadron is a superior shmup overall, but I disagree on the old "style over substance" thing regarding X2.
The game does have substance; it just happens to also have a lot of style, thanks to the superior graphics assets.
It seems fashionable to dismiss X2 on these forums, but I doubt some of these gamers would have denounced it, back in the day...)

Anyway... if you would deign to answer these few points for me, I would be grateful:

1. Do Battle Squadron sprites and backgrounds really have more colours? I think my eyes might be deceiving me. The tonal gradation looks rather... garish.
2. Is there really more going on in Battle Squadron, and how so?
3. Who did code X2. Were they lazy coders who could easily have made it 50 FPS like Toni asserts, or is he perhaps drawing a long bow?
4. How many layers of parallax does BS have?

Please excuse my ignorance, Galahad.

Battle Squadron does indeed have more colours, and uses sprites whereas Xenon 2 doesn't.

Xenon 2 is only 16 colours, though, stylistically what Marc Coleman achieved in 16 colours is pretty bloody good, and I prefer that style than Battle Squadron. Thats not to say I don't rate Battle Squadrons graphics, I do, but I simply prefer Xenon 2 in the graphics department. Less is more

The Assembly Line coded Xenon 2, they were more notable for their Vector based games, so picking them to do the game was always a strange one.

Battle Squadron doesn't have any parallax scrolling, simply because there is no space onscreen for it. Battle Squadron fills up the whole screen with graphics, Xenon 2 on the other hand has huge tracts of black empty screen, which makes it the more annoying that Xenon 2 slows down as much as it does.

Martin Pedersen was a far superior coder in comparison to The Assembly Line, he knew the Amiga hardware very well. Hybris at the time was stunning, it did all the things that an arcade shooter at the time did, it looked and sounded like one.

The one criticism I would say about Battle Squadron is that some of the tiles for the graphics are a bit crappy where the landscape changes significantly.

But technically and colour wise, Battle Squadron has Xenon 2 beat with ease.

[frikilokooo]

Originally Posted by TheCyberDruid

Yep, Project X is one of the very smooth shoot 'em ups. It has many enemies on screen at the same time and is quite colorful. Would have been great to have more games based on that engine.

ProjectX even slows down at some time,only in some occasion and slightly of course in any case it doesn't use parallax except some stars in the first level.

[Marcuz]

Originally Posted by Galahad/FLT

Xenon 2 is only 16 colours, though, stylistically what Marc Coleman achieved in 16 colours is pretty bloody good, and I prefer that style than Battle Squadron. Thats not to say I don't rate Battle Squadrons graphics, I do, but I simply prefer Xenon 2 in the graphics department. Less is more.

i couldn't have said better the same things. also because i'm italian.

succintly, there's not one single thing design, but various areas of production that have different designs and guidelines.

where Xenon II' level consistency beats the one of Battle Squadron, the code design of Xenon II was evidently (from what you more learned guys say) worse.

having played Battle squadron for the first time yesterday, i haven't enjoyed it much, though.

[Codetapper]

Battle Squadron also features that awesome almost-invisible fighter effect (some blitter trick no doubt) and games where you can destroy the scenery always get extra points in my book! Battle Squadron is very smooth, has a large playing area and feels like an arcade game. Xenon 2 doesn't!

It would have been interesting what kind of graphics Mark Coleman could have done if he'd worked on Battle Squadron!

[Codetapper]

Game is composed of 3 panels:
320 x 16 (score area)
320 x 168 (game area)
320 x 16 (credits, time, lives left, baddies left until Goosecopter)

Screen updates 50fps, 4 bitplane mode (16 colours), double buffered.
Background display scrolls 1 pixel every frame, and the parallax layer scolls 1 pixel every 2 frames. (Most of the game screen is the background layer)
Sprites are used for all bullets (player and baddies). Goosecopter and end of level explosions are not sprites. (Tested by turning off all sprites!)
Player, baddies, ground weapons are all blitted onto the screen.
Game does not use sprite collision for detecting bullet hits.

Scrolling area stores a row of data for bitplane 1, then a row of data for the hidden screen, then bitplane 2 etc.
The modulo for the 4 bitplane screen is a whopping $256 (598 bytes), so each screen area is very wide and only 320 pixels of it is displayed. Between the current screen and the double buffered screen is a gap of $34 (52 bytes).

[crabfists]

Very interesting analyses Codetapper. Thanks for sharing your technical knowledge. Just out of interest, how do you figure out these statistics? Disassembly of the games in question? Would be great to have a "Coder's HOL" with info like this on each game.

I wonder how many game authors have officially released the source code to their games? Bet it's close to none but that's a shame. Obviously it's up to them if they don't want to release the source code as they own it but it would be great to see some Amiga coders making the code public to save it being lost forever. I know you can techinically get the source code by disassembly but it would be great to see original comments etc.

[Codetapper]

To start with you just load the game, play it and break into it with the debugger. Check the copperlist (o1/o2 in WinUAE) for how it's creating the display. If it is moving values into the bitplane pointers and then ending the copperlist, it means there is no coppersplit trick. After a frame, check if the pointers have switched to another area. If so, it has double buffered the display. Sprite tricks can be seen with tonnes of sprite loads in the copperlist aswell. Modulos are in the copperlist too so you can see how the screen was arranged, how many colours etc.

[StingRay]

Originally Posted by Codetapper

The modulo for the 4 bitplane screen is a whopping $256 (598 bytes), so each screen area is very wide and only 320 pixels of it is displayed.

Not necessarily. The game is probably using graphics in interleaved format for faster blits, thus the distance from one plane to another is the width in bytes, however, to go from one line to another you would have to skip width*numplanes bytes which explains the rather big modulo value.

[oneshotdead]

Thanks a lot for the explanation and information, Galahad. I'm not technically adept: I just go by what I see, hear and feel with games.

And tho' X2 has less colours, it seems to have more, to me. And that is the result of a gifted graphician who knew how to place pixels and maximise limited palettes, as you alluded.

Edit: my question about BS parallax was sarcastic. Sorry about that!

Originally Posted by Codetapper

Battle Squadron also features that awesome almost-invisible fighter effect (some blitter trick no doubt) and games where you can destroy the scenery always get extra points in my book! Battle Squadron is very smooth, has a large playing area and feels like an arcade game. Xenon 2 doesn't!

It would have been interesting what kind of graphics Mark Coleman could have done if he'd worked on Battle Squadron!

You're speaking of the cloaking effect, there? That impressed (and creeped me out) also. But you can destroy the scenery in X2... or is this some other technicality where the scenery is not the scenery...

X2 felt to me like an Amiga game, and an arcade game - a hybrid. Some would say it fails at both - I doubt they all said it in '89.