Atari v Commodore

[andym00]

Also another good video to see would be MSX version of Elite but there isn't one only useless screenshots.

I was working at PDS/Bits when we were doing the NES port of Elite.. That was the bees knees of the 8bit versions as far as I'm concerned.. Braben & Bell (aka Bed & Breakfast) were in a lot to oversee that, and I think it shows in that it's way better than the other 8bit versions, imho

 

Edit:

Edited September 9, 2009 by andym00

[Lazarus]

It's true that on the Amiga you do actually have line draw and fill functions built into the Blitter BUT the set up time is so wasteful you couldn't gain any real advantage using these functions for something like Carrier Command solid 3D or Starglider hidden line wireframe 3D.....hence the ST versions are 10% faster

Some things could have been done via using the Blitter. For example screen buffer clearing, the chessboard floor of Starglider 2 or the landscape in Interceptor. All the other stuff (buildings, objects etc) would have to be rendered by the CPU.

[oky2000]

It's true that on the Amiga you do actually have line draw and fill functions built into the Blitter BUT the set up time is so wasteful you couldn't gain any real advantage using these functions for something like Carrier Command solid 3D or Starglider hidden line wireframe 3D.....hence the ST versions are 10% faster

Some things could have been done via using the Blitter. For example screen buffer clearing, the chessboard floor of Starglider 2 or the landscape in Interceptor. All the other stuff (buildings, objects etc) would have to be rendered by the CPU.

 

Yes but all you are doing is taking the output of the CPU's 3D geometry calculations and drawing them, they don't really help any calculations which was my point.

[oky2000]

Also another good video to see would be MSX version of Elite but there isn't one only useless screenshots.

I was working at PDS/Bits when we were doing the NES port of Elite.. That was the bees knees of the 8bit versions as far as I'm concerned.. Braben & Bell (aka Bed & Breakfast) were in a lot to oversee that, and I think it shows in that it's way better than the other 8bit versions, imho

 

Indeed Ian Bell himself advises people that they should run the NES version of Elite rather than the BBC B version from Acornsoft, that is as high as an endorsement as you can get I think

[PeteD]

Also another good video to see would be MSX version of Elite but there isn't one only useless screenshots.

I was working at PDS/Bits when we were doing the NES port of Elite.. That was the bees knees of the 8bit versions as far as I'm concerned.. Braben & Bell (aka Bed & Breakfast) were in a lot to oversee that, and I think it shows in that it's way better than the other 8bit versions, imho

 

Edit:

 

Blimey, Bits/PDS, that's something I've not heard of for a while Used to use a crappy old amber screen pc to dev on using PDS back in the day. Was Foo still there in the NES days? I also remember going to see Jez about a dev system for Philips CD-i with the Philips bigwigs. Jez said, look at the speed of the assembler, 10000 lines in 2 seconds. Then he went out the room and I had a quick sneak at the source, 10000 NOPs

 

 

Pete

[andym00]

Blimey, Bits/PDS, that's something I've not heard of for a while Used to use a crappy old amber screen pc to dev on using PDS back in the day. Was Foo still there in the NES days? I also remember going to see Jez about a dev system for Philips CD-i with the Philips bigwigs. Jez said, look at the speed of the assembler, 10000 lines in 2 seconds. Then he went out the room and I had a quick sneak at the source, 10000 NOPs

 

PDS was cool and changed the way I worked forever.. Foo was still there back then in the NES days.. I left before Elite was completed, and the Bits thing was just starting to take off in a big way for them.. The speed of the assemblers was the big pissing competition back then, nothing else mattered.. I recall that Argasm (or whatever it was called) got rumbled because at some point in its life it specifically checked for a specially named source file, and cheated a bit with regards to what it outputted.. If I recall it was discovered by accident when a source file generated totally the wrong output

Edited September 9, 2009 by andym00

[atariksi]

Technically, it's not "2 pixel positioning" but one color clock positioning as these machines are targetted towards TVs w/3.57Mhz color clock. So in many cases, it's sufficient given TV resolution and the way our mind looks at fast scrolling images.

2 pixels = "one color clock" is not true on any C64 model.

 

Regardless, it was more to do with reducing overhead and optimizing for 8-bit accesses. Heck, I prefer VCOUNT as 8-bit value since there's also the option of using a PADDLE counter in case you need a scanline counter.

VCount on C64 is fine as it is, in 99% of the cases you only need bits 0...7 anyway since that covers the entire visible area and a lot of upper/lower border area aswell.

 

You still have to map to color clocks on the output unless you have a higher frequency RGB connection. Hard to say "99%". What about PAL?

[atariksi]

First of all, you have to write two registers even if you scroll every color clock and secondly I don't see that big of a difference extracting LSB or MSB (algorithm differs).

 

You said before it would have been more optimal to use a packed LSBs versus packed MSBs, now you're saying there's not much difference.. That difference between the two methods is as best as I can figure something to the tune of 2-3 cycles per sprite assuming an entities x-position is accessed at least once per frame by logic.. In a 64 sprite multiplexer that's 3 or 4 scanlines in C64 slowland, which is pretty far from optimal, and is actually a big difference..

 

It is more optimal for packed LSBs because you have the option of not using them whereas now you have to write to two registers even if you scroll every color clock. As far as the cycle difference when you do have to use them vs. MSB packed, I suggested splitting up so you save color clock count in one byte and fractional in another:

 

LDA XPosH

Sta XReg

LDA XPosL

And #$80 ;or whatever the mask for given sprite

Or ShadowLSB

Sta PackedLSBReg

[Lazarus]

You still have to map to color clocks on the output unless you have a higher frequency RGB connection. Hard to say "99%". What about PAL?

No? PAL doesn't know about pixels and the color carrier only vaguely describes the color resolution (which is waaaaaaay lower than the carrier frequency btw).

[andym00]

It is more optimal for packed LSBs because you have the option of not using them whereas now you have to write to two registers even if you scroll every color clock. As far as the cycle difference when you do have to use them vs. MSB packed, I suggested splitting up so you save color clock count in one byte and fractional in another:

 

LDA XPosH

Sta XReg

LDA XPosL

And #$80 ;or whatever the mask for given sprite

Or ShadowLSB

Sta PackedLSBReg

 

I know what you meant with that, and that's all fine and good, but you'll pay the price for holding it like that when it comes to manipulating those numbers in game logic..

[Heaven/TQA]

 

 

It's true that on the Amiga you do actually have line draw and fill functions built into the Blitter BUT the set up time is so wasteful you couldn't gain any real advantage using these functions for something like Carrier Command solid 3D or Starglider hidden line wireframe 3D.....hence the ST versions are 10% faster

 

 

I've written some simple code on the ST and ported it to the Amiga and haven't even touched the blitter yet and the screen management (being able to repoint the video addresses on a line by line basis and the screen buffer format) actually removes a lot of overhead that I had on the ST from working around its video memory format. What I've gained from having linear planes has wiped out any advantage of having a faster CPU.

 

But more experienced 68k coders might prove me wrong on this one - it's just my experience.

 

wasn't the original Blitter in the ST line not even slower than the CPU doing the same? or was it the Amiga?

[atariksi]

You still have to map to color clocks on the output unless you have a higher frequency RGB connection. Hard to say "99%". What about PAL?

No? PAL doesn't know about pixels and the color carrier only vaguely describes the color resolution (which is waaaaaaay lower than the carrier frequency btw).

 

"99%" you mentioned was for VCount so the PAL was for VCount not pixels.

[atariksi]

 

 

It's true that on the Amiga you do actually have line draw and fill functions built into the Blitter BUT the set up time is so wasteful you couldn't gain any real advantage using these functions for something like Carrier Command solid 3D or Starglider hidden line wireframe 3D.....hence the ST versions are 10% faster

 

 

I've written some simple code on the ST and ported it to the Amiga and haven't even touched the blitter yet and the screen management (being able to repoint the video addresses on a line by line basis and the screen buffer format) actually removes a lot of overhead that I had on the ST from working around its video memory format. What I've gained from having linear planes has wiped out any advantage of having a faster CPU.

 

But more experienced 68k coders might prove me wrong on this one - it's just my experience.

 

wasn't the original Blitter in the ST line not even slower than the CPU doing the same? or was it the Amiga?

 

Never had a blitter-based ST, but even if CPU is faster at it as long as it's coprocessed it should still be beneficial.

[emkay]

[quote name='popmilo' date='Wed Sep 9, 2009 11:48 AM' timestamp='1252489732'

Existing Driller 3d part runs in 128x128 and pixels have 2x1 ratio.

How would it look in 80x60 with square pixels ?

 

The C64 version of driller uses transitions to have some more colours viewable.

But transitions are "somehow" colour blocks with a lower resolution than the screenresolution. The Atari has at that lower resolution 16 solid colours.

The higher resolution may support the borders in that resolution, but with 16 colours and the lower resolution, you can easily do antialiasing where needed.

[Lazarus]

Never had a blitter-based ST, but even if CPU is faster at it as long as it's coprocessed it should still be beneficial.

The STe blitter was quite slow and lacked a lot of features which the Amiga blitter did have.

[Rockford]

10 - ZYBEX

 

C-64

C-64

C64

 

The C64 version has much better graphics, sprites and more colours. The Atari version has ugly low-res graphics with limited number of colours. C64 reigns with style

 

ATARI

ATARI

ATARI

[emkay]

Zybex.... well, I liked the game very much by it's presentation and title music.

But the game really isn't a good conversion. It's not just the usage of gr. 7, the game itself isn't fully playable, because the "moving objects" have the same speed as the background. This results in unreachable objects to shoot, thus it is not possible to get all bonus items.

The C64 version isn't much better.The resolution is higher, but the shots are based on char movement, which destroys the fun in playing it.

Also the title screen of the C64 version... really nothing to mention.

[andym00]

Zybex.... well, I liked the game very much by it's presentation and title music.

But the game really isn't a good conversion. It's not just the usage of gr. 7, the game itself isn't fully playable, because the "moving objects" have the same speed as the background. This results in unreachable objects to shoot, thus it is not possible to get all bonus items.

The C64 version isn't much better.The resolution is higher, but the shots are based on char movement, which destroys the fun in playing it.

Also the title screen of the C64 version... really nothing to mention.

 

Funny, I just watched a load of YouTube videos of Zybex on the A8 this afternoon.. I didn't think it was that bad, apart from the half-res thing going on, and the appalling colour choices and the pretty bad enemy attack patterns.. Looked very much programmer made The shots were character based on the A8 as well from what I saw..

And I didn't see in the full game play through any examples of the unreachable objects thing.. I was certainly surprised by the A8 video how much it had going on, okay character based, but it was a pleasant surprise.. And the title music was pretty well done by Adam.. I was expecting the worst when it went into one big sound diddling around for a long time, but then smiled when it broke out into a full on tune that you'd expect But it's a pretty poor game, even on the C64..

Edited September 9, 2009 by andym00

[STE'86]

yeah what u want are some really good title screens like these:

 

 

 

Steve

[atariksi]

Zybex.... well, I liked the game very much by it's presentation and title music.

But the game really isn't a good conversion. It's not just the usage of gr. 7, the game itself isn't fully playable, because the "moving objects" have the same speed as the background. This results in unreachable objects to shoot, thus it is not possible to get all bonus items.

The C64 version isn't much better.The resolution is higher, but the shots are based on char movement, which destroys the fun in playing it.

Also the title screen of the C64 version... really nothing to mention.

 

In C64 pictures, they substituted colors for shades (like usual). In general for games, what you don't see from screen shots is hardware collision detection, hardware priority/playfield settings, etc.

[Heaven/TQA]

Zybex.... well, I liked the game very much by it's presentation and title music.

But the game really isn't a good conversion. It's not just the usage of gr. 7, the game itself isn't fully playable, because the "moving objects" have the same speed as the background. This results in unreachable objects to shoot, thus it is not possible to get all bonus items.

The C64 version isn't much better.The resolution is higher, but the shots are based on char movement, which destroys the fun in playing it.

Also the title screen of the C64 version... really nothing to mention.

 

Funny, I just watched a load of YouTube videos of Zybex on the A8 this afternoon.. I didn't think it was that bad, apart from the half-res thing going on, and the appalling colour choices and the pretty bad enemy attack patterns.. Looked very much programmer made The shots were character based on the A8 as well from what I saw..

And I didn't see in the full game play through any examples of the unreachable objects thing.. I was certainly surprised by the A8 video how much it had going on, okay character based, but it was a pleasant surprise.. And the title music was pretty well done by Adam.. I was expecting the worst when it went into one big sound diddling around for a long time, but then smiled when it broke out into a full on tune that you'd expect But it's a pretty poor game, even on the C64..

 

I love Zybex and Draconus...

 

neverless they use bitmapmode 7 (160x96) for the sprites but it is ok... the panel is nice done... multiplayer is not slowing down... great msx and it was nicely done in terms of using atari specific features...

 

btw. I played it through without trainer so fair enough...

[andym00]

In C64 pictures, they substituted colors for shades (like usual). In general for games, what you don't see from screen shots is hardware collision detection, hardware priority/playfield settings, etc.

 

I don't recall that colour substitution or having heard mention of this before.. You mean in magazines ? Box Art ? Posters ? I think the C64s (eye cancer inducing as is often mentioned here) palette is pretty damn memorable and it's pretty hard to tart it up without it being noticed

[Heaven/TQA]

yeah what u want are some really good title screens like these:

 

 

 

Steve

 

but why are you not touching Atari gfx then?

[andym00]

I love Zybex and Draconus...

 

neverless they use bitmapmode 7 (160x96) for the sprites but it is ok... the panel is nice done... multiplayer is not slowing down... great msx and it was nicely done in terms of using atari specific features...

 

btw. I played it through without trainer so fair enough...

 

Okay, so bitmap based I'm still learning all these new fangled graphics modes you have on this contraption

I forgot I did see some slow down a few times, but I couldn't figure out why, they were always at times when things didn't seem so loaded..

But it gets a bit more kudos from me since it's actually bitmap mode then..

[oky2000]

 

 

It's true that on the Amiga you do actually have line draw and fill functions built into the Blitter BUT the set up time is so wasteful you couldn't gain any real advantage using these functions for something like Carrier Command solid 3D or Starglider hidden line wireframe 3D.....hence the ST versions are 10% faster

 

 

I've written some simple code on the ST and ported it to the Amiga and haven't even touched the blitter yet and the screen management (being able to repoint the video addresses on a line by line basis and the screen buffer format) actually removes a lot of overhead that I had on the ST from working around its video memory format. What I've gained from having linear planes has wiped out any advantage of having a faster CPU.

 

But more experienced 68k coders might prove me wrong on this one - it's just my experience.

 

I'm sure you will start to hate bitplanes after a while and definitely curse Commodore's decision to use 8 of the sodding things on 256 colour AGA screens...the bitplane processing time is horrendous on EHB mode, both have advantages and disadvantages but there is a fantastic french demo of what looks like Powerdrome tracks and Starglider II tunnels running almost 2x as fast as either of those games. There are definitely situations where bitplanes are an advantage though yes, but some of the improvement you are seeing is simply because even in machine code on the Amiga you can actually make calls to virtual data types via system libraries like for example using GELs instead of manually manipulating the hardware sprites for multiplexing yourself, it's just a more efficient system all round anyway IMO.

 

I've not coded the ST at anything like the serious level but a friend of mine used to dabble in ST coding and it's all down to how you organise your writes and package your data on the ST he drums into me. He's even managed some pretty fine parallax horizontal scrolling routines with a reasonable amount of CPU time after tweaking tile sizes on word boundaries and some such. We ripped the graphics from 1 level of Gauntlet and he wrote his own scrolling routines and they used nearly half the CPU time just be rethinking how to address the screen memory and manipulate it.

 

wasn't the original Blitter in the ST line not even slower than the CPU doing the same? or was it the Amiga?

 

I think it was either Byte magazine or PCW in the UK that ran some tests and estimated the Amiga CPU + blitter combination was akin to a 70mhz 68000 in perfect situations. Apart from the setup time for multiple tiny blitter objects (a general problem with a blitter) it was a fine piece of hardware to have and implemented on DMA very nicely. Hell you could even do some pretty fine games in Blitz Basic thanks to the Copper/Blitter/CPU combo with a bit of thought. I'll see if I can find a scan of the page somewhere.

 

At the same time the software blitter/A-line routine replacement utility called Turbo ST was just as effective as using applications in GEM on an STE with a hardware blitter. I think if memory serves correct that's just as much to do with the A-line hardware calls/drawing routines on the ST version of GEM being a bit of a kludge...Stardust for the STE is pretty close to the Amiga version in terms of graphics shifted allbeit in 16 less colours....nobody uses any part of the system on ST games coding...have enouhg trouble doing virtual everything on CPU power alone