Favorite 8-Bit Game Never Ported To The Atari Series

[Heaven/TQA]

@ emkay

 

quatsch... vector engine was not developed for numen but for a game and "unfortunatly" just used for numen.... sad but true...

 

you seem to be a clever guy... so grabb your assembler and start coding not like just living in theory... or let others code...

 

ask our screen designers how they feel when non designers (esp. marketing guys like me... ) popping in their room and just dropping stuff like "why not doing it in this and that way"... or telling our sound engeniers to code the engine in this or that way... but never written any piece of code... ok. is it not that any thesis becomes reality just by prooving it???

 

at the end of the day...you seem to be on the stage to show something new... if its so easy (the MCS w3d... then it's up to you to proove... )

 

hve

[emkay]

Heaven/TQA

 

>quatsch... vector engine was not developed for numen but for a game and "unfortunatly" just used for numen.... sad but true...

 

Sad but true is, that the engine never will be a game. Allthough Taquart is a big crew which has a high knowlegde about the 8-bits and they are trained in coding on that machine....

 

 

>you seem to be a clever guy... so grabb your assembler and start coding not like just living in theory... or let others code...

 

 

...So, give me a crew like Taquart and I will active help in development on techniques that are really working on the XL/XE.

What do you think, how am I trained by doing the last coding at about 12 years ago?

[TMR]

Mood's pretty impresive all right.

 

Is there a reason why the Atari couldn't do something similar, TMR?

 

Well, Half FLI and Wolf engines aren't really my territory (i'm very much an "oldschool" coder, i've never even considered doing either) but the mode itself, although lighter than FLI still puts some load on the C64's CPU so the Atari should be able to surpass Mood since the display list could build a similar screen without needing any real CPU time. Numen possibly isn't the best example, i assume that because it's a demo engine it's trading off the user interface against complexity (Heaven can probably comment far better on this than me) but a partially educated guess says that the Atari could probably do Mood with a bit more colour.

 

Maybe emkay's ideas are slightly "pie in the sky" for this kind of game (Heaven's right emkay, we'd need a demo to prove the concept of the ideas!), but it's amazing what has been done already on C64.

 

i believe the Speccy guys have a Wolf engine writing to bitmap but they have a CPU power advantage over the C64; said advantage is a lot less for the Atari (the C64 is just over half the speed) so i'm not sure how much extra power that would work out to in real terms but it's do-able at a "reasonable" rate in theory. Perhaps 160x96 is a more viable mode?

[emkay]

Mood's pretty impresive all right.

 

Is there a reason why the Atari couldn't do something similar, TMR?

 

Well, Half FLI and Wolf engines aren't really my territory (i'm very much an "oldschool" coder, i've never even considered doing either) but the mode itself, although lighter than FLI still puts some load on the C64's CPU

 

 

 

 

This is one thing I will never understand.

 

 

 

1. C64s CPU is half of the XLs

2. VIC II has to shovel more bytes due to the higher colorrange and Sprites through the half adressbus-speed.

3. FLI Mode cost additional CPU-time....

 

In theory some routines must be 4 times faster on the XL But the C64 has allways the better programs at hand.

 

Has the VIC caching abilities? Is the adressbus-speed higher than the CPU-speed?

[ZylonBane]

This is one thing I will never understand.

 

In theory some routines must be 4 times faster on the XL But the C64 has allways the better programs at hand.

 

The C64 has (in some ways) a more powerful graphics chip. There, poof, now you understand.

[Bryan]

2. VIC II has to shovel more bytes due to the higher colorrange and Sprites through the half adressbus-speed.  

 

I believe the C64 (can anyone verify this?) runs on a even/odd clocking scheme, where the CPU and VICII never conflict, and this is why the CPU clock is so low, and VICII can maintain a high bandwidth.

 

-Bry

[ZylonBane]

BTW, anyone curious how good a Wolf3D clone the A8 could pull off, should check out the old Asskicker demo:

http://pouet.net/prod.php?which=9085

[TMR]

3. FLI Mode cost additional CPU-time....

 

FLI takes any rasterline you want FLI running on for CPU, but Half FLI only needs one line in eight. Essentially, what it does is "builds" a new graphics mode by forcing twice as many badlines as there normally are. At the top of each character row there is a badline, it takes about 40 cycles of the 63 available (PAL) to fetch the next line of screen data. Half FLI forces a second badline halfway between each normal one so attribute maps can be changed every four pixels, that means it's possible to fill a bitmap with $0f and get the top half of each 8x8 pixel cell from one colour RAM and the bottom half from a second meaning four possible colours for each "pixel".

 

Okay, that oversimplifies it quite a bit but the general gist is right; CPU overhead is quite low because there are only 25 rasterlines that need "nudging" to be badlines, the hardware already supplies the rest.

[TMR]

I believe the C64 (can anyone verify this?) runs on a even/odd clocking scheme, where the CPU and VICII never conflict, and this is why the CPU clock is so low, and VICII can maintain a high bandwidth.

 

i'm not a hardware bod, but the VIC-II interrupts the CPU 25 times a frame to pull in each character line of data - that anything the CPU is up to or DMA transfers from or to a RAM expansion. Similarly, sprites take a couple of cycles from each rasterline they're passing over so the VIC-II is getting priority there as well.

[Heaven/TQA]

i have a vector game engine at home running in same resolution as numen and you can move around / open doors etc...

 

as i said "numen" is just build around vector... so fox reused that code... (i hope he does not read this... )

 

and don't forget... vector engine is "real 3d" as far as i understood so no wolf clone...you can look up/down jump etc... where in w3d (like asskicker etc...) its cheated as your viewport is determinated...

 

@ emkay

 

unfortunatly i can not code so highlevel like it might be needed to do your stuff (fox, eru are more the real freaks) so... i can tell you another example...

 

they haven't believed me in 1999 that bump mapping & hip must be possible... i got just my gut feeling...so i was like you... going eru & fox on nerves until fox came up with the numen bump mapper and the numen "flower" plasma...so actually it was possible as i thought in the beginning....

 

let's wait until fox publishes the numen source code into public... (read the stats in the note in numen to get a feeling how big numen really is....)

 

and remember that numen uses the mode9++/10++ mode which is little bit faster than the general mode... and i still do not understand exactly how it works... vscrol caching... to use the internal antic buffer to avoid data fetching...

 

http://www.s-direktnet.de/homepages/k_nadj...dj/mode9++.html

 

 

hve

[emkay]

I believe the C64 (can anyone verify this?) runs on a even/odd clocking scheme, where the CPU and VICII never conflict, and this is why the CPU clock is so low, and VICII can maintain a high bandwidth.

 

i'm not a hardware bod, but the VIC-II interrupts the CPU 25 times a frame to pull in each character line of data - that anything the CPU is up to or DMA transfers from or to a RAM expansion. Similarly, sprites take a couple of cycles from each rasterline they're passing over so the VIC-II is getting priority there as well.

 

So my question again:

Can VIC II cache the whole character-line?

[emkay]

This is one thing I will never understand.

 

In theory some routines must be 4 times faster on the XL But the C64 has allways the better programs at hand.

 

The C64 has (in some ways) a more powerful graphics chip. There, poof, now you understand.

 

That does not explain, why there is a lower resolution on the XL/XE necessary to get faster graphics (Rescue on Fractalus, Mercenary...)

[Sharky]

Ghost'n'Goblins and Maniac Mansion were never ported to the Atari 8bit.

[Jetboot Jack]

emkay -- ROF and Mercenary are the same resolution on C64 and Atari -- the 48k version of Mercenary is low res, but the 64k is not...

 

Sharky -- G&G was started on the XL (I know I was doing it), but whilst we got geat background look and feel, much more like the arcade than the C64 version (grey gravestones rather than blue on level one etc), we had little luck with the sprites.

 

Since Arthur was 2 PMG for 3 colors, the missiles were all the weapons for Arthur and we only had 2 sprites left for the enemies -- one 2 color zombie, 2 mono zombies, or LOTS of flicker -- never did solve it

 

Software sprites looked real bad since the backgroud colors had lots of DLI to make them look good -- maybe we shoulda used PMG over char sprites, but even then I doubt we coulda got a great look

 

sTeVE

[TMR]

So my question again:

Can VIC II cache the whole character-line?

 

i believe it does, although i'll point you back to my previous statement about not being a hardware bod. Unless you force a badline, changing the contents of the character screen presently being displayed doesn't have a visual effect until the badline happens again on the next frame. This doesn't apply directly to bitmaps, although it does to their colour maps, which are generated by the character screen when bitmap mode is on.

[emkay]

emkay -- ROF and Mercenary are the same resolution on C64 and Atari -- the 48k version of Mercenary is low res, but the 64k is not...

 

 

ROF is res. of 160*192. in the range of the instruments. The World "outside" is created by using the 160*96 resolution. Check it out.

 

A Hires Mercenary version I have never seen allthough...

[Heaven/TQA]

ROF seems to be mode D (ref. to DLIST command of atari800win, instruments are antic 4)

 

what is interesting is that the rasterlines are $60 bytes per scanline... little bit unusual... and seem to be generated each vbl.... as changes there have no effect... but you can change the antic 4 lines...

 

mercenary... the cracked version (file version or cassette one) has 48k and 64k version... on the disc version you could choos by pressing SELECT (as far as i can remember) while booting into highres mode which is gr.8... definitly...

 

hve

[ZylonBane]

ROF is res. of 160*192. in the range of the instruments. The World "outside" is created by using the 160*96 resolution.

Yes. We know that.

[emkay]

So my question again:

Can VIC II cache the whole character-line?

 

i believe it does, ...

 

 

 

I think too... this is something like changing colors by DLIs, but the registers are changed by hardware.

The chip has to read the bytes. But to read the bytes, the VIC must use quite the double of time than the ANTIC does for reading byte for byte...

 

ANTIC ever runs at 1,79(1,77 PAL) and stops out the CPU at max. usage up to ~30%. This is only by the cause of reading the screendata-bytes over the Adressbus. The CPU has in the worst case ~1,2MHz available. And from the last displayed dot until the first byte of DL reads, the CPU has ~1,79MHz to work with. In theory the XL was allways faster than C64, but C64 is allways a resolution higher.

This is a paradox ... half bus speed / double resolution.

So there must something be on the C64 I still don't know.

[Jetboot Jack]

emkay -- I KNOW ROF is mode D -- the C64 version was the SAME resolution...

 

As to why -- have you any ide how much logic is running -- so by using a lower res mode you get more CPU time -- easy trade, this game has always looked KICKASS to me, high resolution or not...

 

Mercenary runs in ANTIC D for 48k units and ANTIC E for 64k systems (its always 4 color)

 

sTeVE

[emkay]

emkay -- I KNOW ROF is mode D -- the C64 version was the SAME resolution...

 

 

 

sTeVE

 

On the XL there is a double scanline mode used. It is ok because the hardware can do this.

 

On the C64 version you see sometimes between the black dots 3 lines which means, an equal engine is running, but the computer has to work with two lines, which means the double on handled screen-data.

If on the C64 a hardware two-scanline-mode was used, you would always have two scanlines a dot can jump and not 3 or 5 ...

So the computer has more work to do....

[ZylonBane]

As to why -- have you any ide how much logic is running -- so by using a lower res mode you get more CPU time

And don't forget all the RAM a lower-res mode frees up.

[TMR]

On the C64 version you see sometimes between the black dots 3 lines which means, an equal engine is running, but the computer has to work with two lines, which means the double on handled screen-data.

 

Yup, the C64 doesn't have an easy way to do 160x100 so games like Fractalus that appear to be using that resolution are "faking it" with a 160x200 display. So, although in this case they're doing the same calculations to handle the environment, it then takes a susbstantial number of extra memory writes to build each frame.

[emkay]

>Yup, the C64 doesn't have an easy way to do 160x100 so games like Fractalus that appear to be using that resolution are "faking it" with a 160x200 display. So, although in this case they're doing the same calculations to handle the environment, it then takes a susbstantial number of extra memory writes to build each frame.

 

 

So Jetboot Jack was a bit wrong and ZylonBane knowed it already

 

But, by the game-feeling, the XL ist probably 3 times faster in ROF. It would also be faster in Antic e ... I think.

 

Maybe here is the lacking of C64s architecture (only speculations): The more is happening on the screen the more the speed falls back against the XL/XE.

By putting the Graphics in ranges with static elements (Last Ninja, Turrican Characters) the C64 gains speed. Maybe the Chip can cache graphics in some ways....

By moving- and never repetitive elements the chip can cache nothing...

 

TMR ... what do you think about this?

[TMR]

Maybe here is the lacking of C64s architecture (only speculations): The more is happening on the screen the more the speed falls back against the XL/XE.

 

Yup, because the more the environment has to deal with the more the CPU load becomes and that 80% speed difference in the Atari's favour comes to the fore.

 

By putting the Graphics in ranges with static elements (Last Ninja, Turrican Characters)  the C64 gains speed. Maybe the Chip can cache graphics in some ways....

 

Not really, it just has to work a lot less to get larger moving objects. Something like Turrican is using every trick in the book to get it's scrolling done and maintain the sprite multiplex, even down to dropping the scrolling back to 25FPS (which is rare on the C64).

 

By moving- and never repetitive elements the chip can cache nothing...

 

In the case of what Fractalus is doing, it needs to refresh the entire display every redraw so it can't rely on smooth scroll to give it a few frames to get the next display ready cleanly so it all boils down to CPU power and the C64 will always lose out on that front. From what i understand, Fractalus draws the outlines of the mountains into character definitions and plots them to the screen, then fills the gaps with solid colours, that's a lot faster than just writing to a bitmap but still quite slow.

 

For pseudo 3D like Space Harrier uses, the advantages are reduced because the C64 can resort to lobbing large gobs of coloured data around at a reasonable rate of knots and it gets the advantage of the larger hardware sprites on top of that. Look at the later work of Chris Butler, when he wrote C64 Space Harrier it was pretty much the first of it's kind (Encounter covered the idea of large char based objects at speed but Harrier had more detail) and as he honed what he was doing the results improved until his final game, Turbocharge for System 3, blitzed Harrier for look and speed (having Robin "Armalyte" Levy on the graphics helped... =-)