Software sprites and scrolling

[Lord-Chaos]

The problem of a scrolling background is,that a software sprite would be scrolled with the screen,too.Players/Missiles are independent from background.

 

The question is : how was this problem solved on machines without sprites (and scrolling) ?

 

There are many games on the Spectrum or the Amstrad CPC and the ATARI ST,computers without any sprites.

 

The ATARI ST has lots of RAM and graphics can be precalculated and the 68000 has mighty copy instructions like movem it allows to copy the whole screen in 1/50 second.So the ST can handle the problem with its hardware power.

 

But is the ATARI XL fast enough for a software-sprite based scrolling game ? Can you precalculate enough to have only copy-operations ?

Can self-modifying code or illegal opcodes help ?

Is it possible to use the hardware scrolling (the STE in "Wings of Death"

uses STE Scrolling and Blitter-Sprites AFAIK)

 

I mean the Amstrad has some games with good software sprites and although it is twice as fast as the ATARI , it´s screen RAM is twice as big (160*200*16,320*200*4,640*200*1).

Maybe it would make sense to look how they made certain games on the Amstrad CPC.

 

Thimo

[Jetboot Jack]

Lord Chaos,

 

Many games use bitmapped modes with software sprites and scrolling (Zybex and Ninja Commando from Zepplin spring to mind) -- in Antic D and Antic E.

 

Others have used Antic 4 with software sprites and scrolling -- Black Lamp from Atari, Menace and Project Xantien from Harlequin (check them on my website, the ATR files are available for download)...

 

Black Lamp is the most impressive one IMHO, although if we had finished Menace you would have been blown away

 

As to the CPC, altough its clock speed as high its a Z80 and they are instruction for instruction much slower than a 6502...

 

sTeVE

[Bryan]

But is the ATARI XL fast enough for a software-sprite based scrolling game ? Can you precalculate enough to have only copy-operations ?

Can self-modifying code or illegal opcodes help ?

 

First of all, games don't always have to run at 60/50fps. Slowing the framerate can give you a lot of time for screen modifications. On the Atari 8-bit the best method would probably be to use hardware scrolling, and use fast methods of drawing, then removing the sprites. This usually involves saving the data under the sprite. Character mapped graphics can make some things easier because fixing the screen may just involve putting some original characters back.

 

Self-modifying code can speed some operations a bit, since the fastest thing the 6502 can do is deal with immedaite values and absolute addresses. Unless you're really tight on cycles, illegal opcodes probably won't help much.

 

-Bry

[Heaven/TQA]

lord chaos... depends what you EXACTLY mean with hardware scrolling...

 

will you scroll a complete level like uridium etc... then you have several options:

 

build the level in memory and the software and use HSCROL + setting the LMS commands in displaylist to move the background....

 

or you use ONLY hscrol to move 1 char and build/copy every time the next frame... (which costs CPU) i guess zybex etc... are doing this...

 

if you use antic e than obviously you will run in memroy restrictions when using method a...

 

regarding positioning of the software sprites...should be no problem as you might deal with "relative sprite positions" so you have to add the actual screen positions to the positions of the sprites... simple example:

 

you want to position sprite on pos 10,0

you scroll 1 pixel left... so you have to add #1 to the sprite position 10+1,0 to let the sprite stay on the same position...

 

 

i guess on ST,spectrum armstrad, etc... they do this:

 

clear sprites, build the screen, scroll the screen, move sprites internally in relative position to the new screenposition, paint the sprites on screen...

 

antic 4 charmode helps you in build screen, clear sprites to make it maybe faster than in antic e...

[TMR]

The problem of a scrolling background is,that a software sprite would be scrolled with the screen,too.Players/Missiles are independent from background.

 

It really depends on what you're doing i s'pose, have a look at Tusker on the Atari for one work-around...

 

But is the ATARI XL fast enough for a software-sprite based scrolling game ? Can you precalculate enough to have only copy-operations ?

 

i s'pose it depends on how you do the work and how many concessions you're willing to make; look at the Commodore Plus/4, it clocks around 1.7MHz in "fast mode" (when not refreshing the screen, since it has twice as many badlines as the C64!) but there are scrolling games with soft sprites there like Airwolf 2, Starforce Fighter or the simple b ut reasonably playable homebrew job Dex and all three (and more besides) run in 160x200 character mode.

 

I mean the Amstrad has some games with good software sprites and although it is twice as fast as the ATARI , it´s screen RAM is twice as big (160*200*16,320*200*4,640*200*1).

Maybe it would make sense to look how they made certain games on the Amstrad CPC.

 

The CPC isn't twice as fast as the Atari, each command requires amost twice as many cycles to perform the same operation so it's only a little faster - instead speed concessions are made and i'm about to comment on that in another reply... =-)

[Lord-Chaos]

lord chaos... depends what you EXACTLY mean with hardware scrolling...

 

will you scroll a complete level like uridium etc... then you have several options:

 

build the level in memory and the software and use HSCROL + setting the LMS commands in displaylist to move the background....

 

or you use ONLY hscrol to move 1 char and build/copy every time the next frame... (which costs CPU) i guess zybex etc... are doing this...  

 

if you use antic e than obviously you will run in memroy restrictions when using method a...

 

regarding positioning of the software sprites...should be no problem as you might deal with "relative sprite positions" so you have to add the actual screen positions to the positions of the sprites... simple example:

 

you want to position sprite on pos 10,0

you scroll 1 pixel left... so you have to add #1 to the sprite position 10+1,0 to let the sprite stay on the same position...

 

 

The idea is that if I make a game it would certainly be cartridge-based.

 

That means I have lots of memory ,at least 128K if I use an old "Crossbow" cart.

 

Then I would precalculate as much as possible,so that screen-building does not involve any big clculations anymore , software-sprites will be stored pre-shifted and the masked sprites,too.

 

The only thing the CPU must do is copy the stuff to the screen or the buffer and then to the screen.

 

It should be possible to use players for color-enhancement only but missiles for fast-moving objects.

 

Usually a game uses only about 2/3 of the screen and no more than 200 lines to make it NTSC compatible , so there would be plenty of time left for code-self-modifications etc.

 

Games like Zybex are not satisfying,because they use a low resolution and not enough colors.Although the game plays better on the ATARI , the C64 version looks better.

I don´t know if they used the blocky resolution because of memory or because of speed - the ATARI should be fast enough for such a game.

(An Draconus with its few sprites/screen certainly could have looked like the C64 version with its much superior sprites).

 

Because there are older games which use software sprites , all the Graphics-8-artifacting games like Treshold,Lunar Leeper,Lode Runner / I think Zone Ranger,too and Zone X uses dozens of smooth moving non-flickering colorful sprites.

 

Since Zone X is a 4-way-scrolling game it is possible to use lots of software sprites + scrolling , I suppose the games uses charmode.

 

Thimo

[TMR]

First of all, games don't always have to run at 60/50fps. Slowing the framerate can give you a lot of time for screen modifications.

 

Anything that doesn't move at full framerate looks a lot "dirtier" than it's compatriots, for example Transmuter looks slower and chunkier than Zybex.

 

There are ways to "cheat" and produce a reasonable number of moving objects that are just character blocks with precalculated movement; assigning 24 characters (6 characters per frame times four frames of motion and it can work in less if the graphics are optimised) is enough to produce one nasty that can be repeated across the entire screen.

 

These blocks can just be written back into the screen (mirroring off what's under them to "repair" the screen between frames) and their positioning can offset against the scroll to allow them to move faster, match speeds, go slower or stop. Similarly, a vertical object needs another 24 characters max, tracks along horizontally with the scrolling and can move two pixels a frame in either direction vertically. Each object needs six bytes written to the screen and another six repair bytes per frame, so five objects is 30 writes overall.

 

The Atari has an advantage, if you do the nasties with soft sprites you can then process the player's object with... erm, players! =-) If that's the only one that needs any kind of real position flexibility you've got it made.

[TMR]

Games like Zybex are not satisfying,because they use a low resolution and not enough colors.Although the game plays better on the ATARI , the C64 version looks better.

I don´t know if they used the blocky resolution because of memory or because of speed - the ATARI should be fast enough for such a game.

 

Speed, i'd put money on it.

 

The "trick" to getting things really fast (that Zybex doesn't use) seems to be not allowing the software sprites to pass over background detail... =-)

[analmux]

I don't see the problem. Most of the time you only have to worry about the playing character (f.e. the mario's sprite in the super mario series). The enemy-sprites move with the background, so don't stay on the same place.

 

The main player sprite can easily be redrawn every frame. In antic 4 or E.

[TMR]

I don't see the problem. Most of the time you only have to worry about the playing character (f.e. the mario's sprite in the super mario series). The enemy-sprites move with the background, so don't stay on the same place.

 

The main player sprite can easily be redrawn every frame. In antic 4 or E.

 

Depends if the enemy needs to move over the background; something like Mario has gaps where the nasties pass through and is almost designed for software sprite use but Zybex passes it's nasty sprites over the background all the time. My preference is to cheat my arse off and only write in the former model... =-)

[analmux]

Well, that's why you'd need a smartfont engine I'm working on (in antic 4).

It precomputes possible spriteshapes, including background overlap. When an enemy only walks horizontally you can cancel off all other possible, but not used, graphical configurations (of enemy movement), and the smartfont system needs only concentrate on horizontal movements.

 

The smartfont system will only update the possible shapes when moving to another screen, so will eventually steal 1 or 2 frames (while scrolling to that next screen) to precompute the next set of possible spriteshapes.

[TMR]

It all comes down to what you've got to work with, force of habit means i work on a 64K system and it's rare that my stuff multi-loads so i can't pre roll graphics in the same way. Most games stick to about the same base model of machine so they have similar restrictions to work with although one or two do it better... =-)

 

(Oh, back from my little break by the way... =-)

[Heaven/TQA]

@ Lord Chaos

 

Zone Ranger does not scroll... it's a simple "copy as fast as possible" antic e sprites (preshifted in memory) there...

 

we discussed similar stuff here

 

http://www.atariage.com/forums/viewtopic.p...highlight=pilot

 

hve

[Bryan]

I always liked DROL for a SW sprite game (high-rez, turn on Artifact colors). It's probably not as fast as it could be, and looks like it runs at about half frame-rate (& drops lower at times).

 

-Bry

[Goochman]

I always liked DROL for a SW sprite game (high-rez, turn on Artifact colors). It's probably not as fast as it could be, and looks like it runs at about half frame-rate (& drops lower at times).

 

       -Bry

 

Drol was awesome - I still like to play it to this day

[Jetboot Jack]

HELLO!

 

Don't any of you read "other member's posts" -- geeze...

 

It's like my reply was in-frikking-visible, you're ALL talking of simple techniques shown in the games I mentioned -- please check out the games I mentioned for ANTIC 4 software spries and hardware scrolling -- its easy!

 

Sure you're NOT gint to be hitting 60fps (30 is much more realistic), but char mode softsprites have been done on the A8 for years...

 

sTeVE -- yes I am frustrated!!!!

[TMR]

HELLO!

 

Don't any of you read "other member's posts" -- geeze...

 

It's like my reply was in-frikking-visible

 

Who said that?! [looks around?! =-]

[Bryan]

HELLO!

 

Don't any of you read "other member's posts" -- geeze...

 

 

I was actually mentioning DROL as an addition to the list you posted.

 

-Bry