Favorite 8-Bit Game Never Ported To The Atari Series

[sack-c0s]

The Acorn A3000 has a CPU without that complex commands an can handle any command by using less Cycles. Against the Archimedes the ST is like a snail

 

Yes but the sound hardware was an utter *bastard* (thank christ for people like Quantum for coding modules for tracker playback:) )

 

and everything up to the VIDC20 (i think) in the RISC PC had a fixed 256 colour palette which is (a) awful and (b) by it's fixed nature makes some things damn awkward.

 

Take screen fading:

 

on the ST:

 

Just reprogram the palette every frame with darker colours until you hit black. that's what? 256/512/768 bytes per frame? I was an archie coder too, so forgive me for not knowing

 

On the Archimedes:

 

Get a pixel, look up to find what the next value should be to replace it with, write it to the shadow scren bank. 320*256 bytes later, wait for VSync, flip the screens.

 

Conclusion: Mindbogglingly slow compared to the ST.

 

Never underestimate how much even a small hardware feature can boost/cripple the CPU

 

but it is nice being able to do:

 

ADR R0,sprite

LDR R1,screenbase

LDR R2,spriteX

LDR R3,spriteY

 

ADD R3,R3,R3,ASL #2 ; Quick MUL by 320

ADD R3,R2,R3,ASL #6 ; (If i'm not too drunk to mess this up)

ADD R1,R1,R3

 

#rept 32

LDMIA R0!,{R2-R9}

STMIA R1,{R2-R9}

ADD R1,R1,#320

#endr

 

for a damn simple 32x32 sprite plotter

 

(not to self: don't ever post drunk again - writing the same post 3 times in an effort to get it right is tiresome:) )

[Heaven/TQA]

well... i thought tonight about this method...

 

i guess thimo that you would organise the screen in this way

 

05a

16b

27c

38d

49e

 

(just an example...)

 

so that when coping sprite data into vram(charset) you could simple have sta font,x while moving data in "stripes" simple as you would do with player/missles... (in RAM the bytes of chars 0,1,2,3,4 are linear)

 

i see the advantage compared to a highres screen BUT you need extra logic in the sprite engine taking account regarding the zones... or how would you solve this? as on zone boundaries the chars are not resting behind each others in RAM? or is there a possiblitiy?

 

hve

[TMR]

I think on the C64 some programs used this technique.

 

Some demos use a variation on that idea, although it's tricky to use properly because you'd have to dynamically retime the change overs between fonts to allow for a sprite passing over the split.

[emkay]

Steve

 

Have you ever created or seen a PM-wrapper? I think not.

 

 

 

BUT there are games where this method is not totally appropriate, a vertical shooter for instance, like last guardian would not benefit from this technique I think, nor would a true 3D game like Mercenary be useful in char mode...

 

sTeVE

 

 

Vertical shooter will also take profit. The difference is, that you can't use the VSCROL and have to code a scroll.routine by DList-changes.

 

 

Mercenary truely dos not need charmode. Because it don't need any more colors.

See the difference: To make a very fast Screen, use antic mode 6 (charmode 20*8 res.) so you can get frames per second a modern PC is dreaming of But it is useless to create games, that still need a high resolution. The max. res. wihout any flicker-tricking or CPU overloading is still 160x192(240) 4 color + PM overlay resulting colors.

(For Game Titlescreens the fullscreen DLI/Kernal can be used... )

 

To build games with the most possible quality in graphics, charmode with PM overlay is a must, not a question.

[emkay]

well... i thought tonight about this method...

 

i guess thimo that you would organise the screen in this way

 

05a

16b

27c

38d

49e

 

 

Here are some possibilities:

 

Use one Charset for the whole screen:

Now build a cluster

 

 

048c

159d

26ae

37bf

 

 

Build a graphics routine which is working in it like in a real screen. Then you can copy this cluster (4x4) to the whole screen and the full screen seems to move...

 

 

Second way (MCS like):

 

Use 8 charsets...

 

Align allways 120 Bytes one after one

Put seven DLIs on the Screen to actuate charbase.

So you can use charmem for fullscreen

 

 

 

Third Way:

 

USE PMg like a Bitplane.

Every movement on the screen calculates the needed resulting color and sets the PMg Bits....

 

Then use one or more charsets only for lineups and set clusters where needed.

 

Or use 7 chasets...

[emkay]

Here a small conclusion:

 

On the C64 everything is possible, because it is right looking how it is done...

The C64 can rebuild allmost everything a 16Bit shows....

 

Looking at the 16Bit....: In my weak memories I am shure that I had read once, that a simple NOP Operation on the 68000 takes 20 cycles. (correct me if i am wrong). Simple copy operations are taking 10 times more on cycles like a 6502/6510

 

So all that is to do on the C64: Prepare data to optimize for the Hardware-abiities. And for gaining speed: copy Data as hell ...

 

Now think about the 80% real more speed compared to the C64.

[Sheddy]

I can't see how character mode could be made to work very fast for a game like mine (with smooth vertical movement, and masking overlaps) ??? Whatever arrangement of characters I can think of makes it slower to draw to than a bitmap - but I'd love you to prove me wrong

 

Also don't foget you do still need to clear areas of memory in the character definitions themselves if you're treating them more like a bitmap (but not the whole lot necessarily) - negating some of the speed advantages

[emkay]

I can't see how character mode could be made to work very fast for a game like mine (with smooth vertical movement, and masking overlaps) ??? Whatever arrangement of characters I can think of makes it slower to draw to than a bitmap - but I'd love you to prove me wrong    

 

 

 

By the achievement of your Gameengine, there is no Charmode needed.

 

The only thing is, that by using the Charmode with PM Overlay, it would never be needed to clear some memory. Just make the sprites one or two dots bigger with the backgroundcolor. By using the PM overlay, which will build the "optical buffer" for the charmovement, you can easy allways "LDA STA" into the Char-memory.

The most complex thing would be to correlate Char-moving with the sprites in the charmem...

[ZylonBane]

On the C64 everything is possible

Really? Can it display 128 unique colors without flicker?

 

[emkay]

On the C64 everything is possible

Really? Can it display 128 unique colors without flicker?

 

 

Try to tell this to ZylonBane. He is very shure, the C64 is the allmost advanced machine.

 

Oppps... You are ZylonBane

[ZylonBane]

Ummm... did that make sense to anybody?

[Jetboot Jack]

emkay,

 

Whilst I may not have experiment along the lines of using prior to create PMG/PF overlap colors, I can assure you I have looked long and hard into the methods you and Lord_Chaos are on about..

 

Although I've not tried setting up a whole screen as a charmapped display I admit, this sounds interesting, but surely you need 16 characetr sets to support a true double buffer display in this mode -- so it cost more than an ANTIC E display in the end, 16K plus 1920 exta bytes for the two display buffers -- or am I missing something??

 

I can see the idea having merit for static screen games primarily.

 

As soon as scrolling enters the equation I fear that this will be more hassle that it is worth, and resorting to normal char mapped display techniques will be better, flexible and faster, since hardware scrolling is the only acceptable method I feel.

 

In vertically scrolled games I can see no use for this system, and altough workable in horzontally scrolled games -- you would need to limit each scrolling mode line to 128 characters so you could uniquely map the entire line for sprite positioning. I also think the amount of effort to do this for the gain of one extra playfield color really out weighs the advantage IMHO.

 

Although low resolution I always admired Zybex's ANTIC D scrolling -- chunky but VERY flexible...

 

sTeVE

[Bryan]

I'm really not sure why things get so weird in these discussions. Suddenly there's no point to programming at all unless you've used every available cycle and stacked all 5 players on a character mapped graphic with colored plastic overlays on the TV for good measure and convinced fans of every other platform of how wrong they were.

 

Discussing programming tricks wouldn't be so bad if didn't always derail the topic and degenerate into bickering.

 

TMR isn't even (officially) an Atari coder and he's produced more visible work recently than anyone else. I'll be a lot more impressed by someone's theory when I see it produce real results on the screen.

 

-Bry

[Bryan]

the C64 is the allmost advanced machine.

 

Wasn't that Commodore's advertising slogan for a while?

 

-Bry

[TMR]

the C64 is the allmost advanced machine.

 

Wasn't that Commodore's advertising slogan for a while?

 

It was C64 - buy it 'cos we need the dosh! =-)

[Bryan]

Ummm... did that make sense to anybody?

 

I figured it out, but I spent way too much time on it.

 

-Bry

[Jetboot Jack]

I resemble that remark Bry

 

I've done or been involved with my fair share of real 8bit work (check out my website), and although all these ideas are kinda cool to hear, lets see some examples please, less theory and more practice...

 

I can certainly say that synchrnoizing 5 animated PMG overlays with software sprites can be very time consuming, and error prone, often more time than you have CPU cycles left to do any logic in!!!

 

If you play Project Xanthien from my site you'll see the main character is a char mode software sprite with the missiles overlaid for more color, all other enemies are PMG and there is a buggy, but occasionaly functional horizontal multiplexer that gets 3/4 multicolor PMG on one line, I forget how it was done (I lost touch with the author many years ago), but I did design the game and did the art for it...

 

sTeVE

[Heaven/TQA]

@ lord chaos/emkay

 

what about a tech demo with some sprites moving around???

(hehehehe.... so you can not pull out MCS, etc... )

 

hve

[TMR]

i can't help thinking that it'd be best to prove the technology at a simple level first, perhaps an action puzzler puzzler or single screen action game with MCS graphics. i know emkay has done work with it already (although i don't know what titles to look for...?) but a new product would be better and opening the source up too.

 

i, on the other hand, don't open my source because my labels reveal a little too much about me! =-)

[Bryan]

i, on the other hand, don't open my source because my labels reveal a little too much about me! =-)

 

Hummm... any guesses?

 

jmp i_feel_pretty

 

J/K

 

-Bry

[TMR]

i, on the other hand, don't open my source because my labels reveal a little too much about me! =-)

 

Hummm... any guesses?

 

jmp i_feel_pretty

 

Well, my core loop is only called "bondage" because it ties the runtime code up - honest...! (Actually, that only applies to demos, it's called "main_loop" for games... =-)

[sack-c0s]

i, on the other hand, don't open my source because my labels reveal a little too much about me! =-)

 

Hummm... any guesses?

 

jmp i_feel_pretty

 

J/K

 

-Bry

 

There are some question in life best not asked... and having done so myself I can confirm that this is indeed one of them

[TMR]

i, on the other hand, don't open my source because my labels reveal a little too much about me! =-)

 

Hummm... any guesses?

 

There are some question in life best not asked... and having done so myself I can confirm that this is indeed one of them

 

Oh, i forgot that someone here knows me that well...! =-)

[Lord-Chaos]

I think that in most cases you won´t need a full 160*192 screen for a game , so you won´t need 8 different charsets.

 

It depends on the game :

 

traditional adventure games with their static graphics could look very good with additional colors by using charmode+DLIs , usually only 2/3 or 1/2 of the screen is used for graphics , rest is text-window.

 

Tile-based action adventures or role-playing games - ULTIMA or console-like games like Final Fantasy (NES) without many moving objects would be possible ,too , with graphics similar to NES.

 

3D rpgs like "Dungeon Master" would also benefit from the larger number of colors , usually their graphics windows take only 2/3 of the screen and it´s rather static , since objects always appear on the same places and zooming is limited to 3 or 4 distances.I once wrote a "Dungeon Master" 3D graphics routine.

 

puzzle or strategy games usually have a quite static graphics , so this technique could be used.

 

Isometric 3D games are a little bit tricky - look at Last Ninja on the C64 , it isn´t really fast although only 2 moving objects are in most screens.

Could be done I think since there is no scrolling , but I never worked with isometric graphics.

 

Vector graphics games usually use only 2 colors , so the best idea would be to use graphics 14 or a similar 2-color mode and a DLI to separate the sky from the ground ...

 

1-screen games/platform games : Without any scrolling , a platform game with many levels should be possible.Somethink like "Bubble Bobble" , since it has only black background and no complex graphics.

 

Fast action games : Software sprites are no big problem , if the background is not complex - black in a space-shooter for example.

But a complex background makes moving a lot of objects difficult , I´d use the missiles for shots or laser beams etc. and software sprites only for bigger objects.

You can pre-shift objects , store a lot of data pre-calculated in RAM , especially on a 130XE.

 

Please note that with the memory of a 130XE you can pre-calculate a lot and store it in the extra - RAM , so that you can gain speed.This can be done on a 64K machine,too , if you have a small main program and divide a game into levels that can be loaded from disk.

A new game could be made with added 130XE (128K+) support , means smoother animation on 128K machines possible etc.

 

And data on disk can be compressed , many C64 games like load huge level data and decompress it , although a few very impressive games like Wizball are in 64K.

 

Player-Overlays are also possible with normal bitmap graphics , but some colors are lost.

 

And although PAL ATARIs can display up to 240 lines , it´s not recommended to use more than 200 , otherwise such games coul become unplayable on an NTSC machine.

 

And there are computers with no sprites/scrolling at all - Amstrad CPC for examples - that have fast action games.The Amstrad for example is a ca. 4Mhz Z80 machine , but uses a 16K 160*200 16 color screen AFAIK (or 4 colors in 320*200) and this means twice as much as the XL (so it loses the advantage of the twice-as-fat CPU) .But Turrican , Silkworm and other fast action games are available !

 

BTW.: vertical scrolling is possible with 2 entirely differnt ways - first , by using the scroll register , and second by adding or removing the different "blank" lines in the Dlist.I once wrote a small demo for this , but it´s lost one of my 5.25" disks.

 

Thimo

[Goochman]

Bubble Bobble - Theres a game that would be a good conversion for the 8bit.....