Jump to content
IGNORED

Favorite 8-Bit Game Never Ported To The Atari Series


Bill Lange

Recommended Posts

BTW I'd be surprised if Firebird managed to do a version superior to the beeb original, after all the BBC runs at 1.8Mhz as well as the Atari, and I don't see any huge speed benefits to be had from the Atari hardware in this kind of game? Also presuming Braben and Bell used efficient line-draw and division routines.

 

Well, one thing that springs to mind is double buffering - the BBC version isn't and that's passed on to every other implementation. The C64 version alone could be very much less flickery for it...

Link to comment
Share on other sites

BTW I'd be surprised if Firebird managed to do a version superior to the beeb original, after all the BBC runs at 1.8Mhz as well as the Atari, and I don't see any huge speed benefits to be had from the Atari hardware in this kind of game? Also presuming Braben and Bell used efficient line-draw and division routines.

 

Well, one thing that springs to mind is double buffering - the BBC version isn't and that's passed on to every other implementation. The C64 version alone could be very much less flickery for it...

 

No double-buffering??? WTF! Didn't know that. Little excuse not to do that unless they needed all-out speed (but then there's always triple buffer). Memory wasn't a problem for the C64 or Atari. Just got to look after another set of co-ords is all - if you don't want to clear the whole screen.

Link to comment
Share on other sites

Hi,

 

The Elite line drawing worked on a simple EOR approach with the last set of lines drawn being held in a buffer. This is used to erase the last frame when the new one is drawn. Flicker on the C64 was reduced by keeping the plotting execution outside of when that section of the screen is being drawn. I didn't put this into the A8 demo though, hence its a little more flickery, but not too much.

 

In order to go double buffered, I'd need to employee a third buffer. One to hold the new lines, another to hold lines drawn in screen 1 and a third to hold lines drawn in screen 2. Certainly you couldn't totally erase a screen and redraw it (i.e. don't use line buffers) because it takes too long.

 

However, the pain of a second buffer is that the text overwritten on a the display must be done in both screens. Also you can have flashing messages, therefore there's a little overhead in blitting a string to both screens. Once the direct port is completed then these bits can be added.

 

Finally, the game would need to use all 64K in order to support a double buffer (shades of the tradeoff Mercenary had). Therefore a 48K version could use the 1 screen, 2 line buffer method and the 64K version use the 2 screen, 3 line buffer method. However, I might end up using a bank switching cart and run it in 32K RAM.

 

Regards,

 

Mark

Link to comment
Share on other sites

Memory wasn't a problem for the C64 or Atari..

 

Hey ;) Memory is the only problem of the 8-bits...

With a real amount of 4MB I would try to convert Wolfenstein 3D onto the XL and you all would think, it is a PC (seriously)

 

No, we wouldn't. Seriously.

 

Quite so, it'd still be the wrong shade of beige :roll:

 

Of course I only meant memory size in comparison to the BBC model B which only had 32k. BTW, you know you CAN produce 4MB carts (or bigger)? Seriously. *Holds breath*

 

Just kidding with yer, emkay. But you really can make a cart as big as you like (according to Sunmark, anyway)

Link to comment
Share on other sites

Hi,

 

The Elite line drawing worked on a simple EOR approach with the last set of lines drawn being held in a buffer. This is used to erase the last frame when the new one is drawn. Flicker on the C64 was reduced by keeping the plotting execution outside of when that section of the screen is being drawn. I didn't put this into the A8 demo though, hence its a little more flickery, but not too much.

 

In order to go double buffered, I'd need to employee a third buffer. One to hold the new lines, another to hold lines drawn in screen 1 and a third to hold lines drawn in screen 2. Certainly you couldn't totally erase a screen and redraw it (i.e. don't use line buffers) because it takes too long.

 

However, the pain of a second buffer is that the text overwritten on a the display must be done in both screens. Also you can have flashing messages, therefore there's a little overhead in blitting a string to both screens. Once the direct port is completed then these bits can be added.

 

Finally, the game would need to use all 64K in order to support a double buffer (shades of the tradeoff Mercenary had). Therefore a 48K version could use the 1 screen, 2 line buffer method and the 64K version use the 2 screen, 3 line buffer method. However, I might end up using a bank switching cart and run it in 32K RAM.

 

Regards,

 

Mark

 

Well, I'm glad you're seriously considering double buffering. Guess I'd underestimated the likely RAM required though. BTW I hope the line erasing code doesn't use the same routine as the draw - I'd hate the thought of a superfluous EOR ;)

Thanks for the insight into the game :)

Link to comment
Share on other sites

Quite so, it'd still be the wrong shade of beige :roll:

Cute. I -- like the poster I was responding to -- was referring to what's on the screen.

 

No matter how much RAM you have to throw around, you're not going to get anything up there that would make someone think they were looking at Wolf3D on a PC.

 

Gobs of RAM would make a rough Wolf-alike practical though, since then you'd be able to pre-scale all your texture strips.

Link to comment
Share on other sites

It's an interesting idea - so I hope someone does try it

 

Bane seems to put aside, how blocky Wolf 3D on the PC was and how small the playfield on a 386 25 has to be adjusted to for a playable framerate....

 

A game like Wolf 3D would be a bankswitching-copy-orgy.... And it would also be possible to change the whole Displaylist, Playerpositions and DLI-code at every VBI. By preshifting every element, you can simply copy all of them onto the screen and additional use MCS techniques to enhance the colors....

Link to comment
Share on other sites

Bane seems to put aside, how blocky Wolf 3D on the PC was

PC Wolf 3D ran on a 320x200 pixel, 256-color display. The Atari can't do this, period. It can approximate it at reduced resolution and with a lot of flicker, but using so many cycles that you'd be running at about 2 FPS.

Link to comment
Share on other sites

If not, I think I just thought of my next project!   ;)

 

Hey, I'd nearly forgot about Bomberman! What a great game that is - still remember the PC Engine original. I believe there is a clone for Atari, but I can't think what it's called or where I saw it now :?

Link to comment
Share on other sites

Damn, I forgot one I had started converting myself...

 

Speedball!

 

I had (still have) an STE which I played this on, but a friend

had a C64 and their conversion was pretty decent. This has to

be one of my most favourite tunes too!

 

But you could add most everything else from the Bitmap Brothers,

e.g. Xenon was on the C64.

 

I'll see if I can get the ATR of screens together...

most of the graphics were done by staring at the ST version

on the telly and drawing it onto graph paper, then using

the touch tablet to enter it in to A8... ouch! But I guess some

of you have been there too! :)

 

Regards,

 

Mark

Link to comment
Share on other sites

I can think of three: Pang, Dynakillers, Tekblast. Tekblast is wonderful and deserves a cartridge edition ;)  

 

++

RC

++

 

Thanks RC. That many! Dynakillers was the one I was trying to remember. I'll be sure to check out Tekblast now though.

 

Xenon! I was (am) a big scrolling shoot-em-up fan. That was the first 16-bit game that made me think I'd seen a properly done 16-bit game - very talented artists. Speedball was great and very playable too. Sure would be interested to see your preliminary work Mark.

Link to comment
Share on other sites

Bane seems to put aside, how blocky Wolf 3D on the PC was

PC Wolf 3D ran on a 320x200 pixel, 256-color display. The Atari can't do this, period. It can approximate it at reduced resolution and with a lot of flicker, but using so many cycles that you'd be running at about 2 FPS.

 

160x200 (including scoreboard)

Charmode blitting

PM-Overlay for walls

Up to 64 colors

Approximatly 20fps

 

The biggest problem is the lack of Memory for the preshiftet objects and sprites.

 

 

The PC is not truely using 320x200. The Engines resolution is much lower. And you never see 256 colors the same time. Please compare to the Jaguar version.

Link to comment
Share on other sites

Here's the Speedball bits.

 

PRG1 = Intro fist

PRG2 = Non-game screens, press START to stop animation,

then SELECT to see the league table, then START to start over.

PRG3 = Game screen - use joystick to scroll (slow) and various

keys do bits, 'O'pen or 'C'lose the 'L'auncher. '*' = timer

and 'T' places a token randomly on the pitch.

 

A couple of extra little bits, a scroller using graphics from

Joe Blade (given to me by the author himself), and another

intro, this time a conversion of the intro to Paradroid 2000.

 

Enjoy,

 

Mark

spdball.zip

Link to comment
Share on other sites

but wolfenstein uses mode 13h which is byte per pixel and 256 colored index palette...so W3d actually uses 256 colors weather the textures are painted in 256 or not... you are not saving anything when using less colors...

 

hve

 

Since there are VGAs with more than 16 million colors... If you want to paint grass, you don't have to use 16 million colors but only green colors in some variations and different brightnesses.

 

Wolf 3D has no lightning effects or somewhat about a real 3D Engine. So you can use fixed colors.

 

....

 

Ok I see I mentioned something, everyone will only believe, if it is done...

For shure I am not trying to make such a projekt. There had to be to much to be done previously like an active memory-controller and converter tools to build XL/XE accurate graphics- and sound- patterns...

Link to comment
Share on other sites

Charmode blitting

PM-Overlay for walls

Huh? Are you proposing using redefined characters for the graphics? Ugh.

 

The PC is not truely using 320x200.

Yes, it is. Look at the screenshots. The only time you see duplicated pixels is where it's drawing a texture that's being enlarged beyond its native resolution.

Link to comment
Share on other sites

ZylonBane

 

> Are you proposing using redefined characters for the graphics? Ugh.

 

 

Ofcourse Charmode. So it will save a lot of CPU-Time on repetitive graphics. The movement on Wolf 3D is very simple...

 

 

 

>Yes, it is. Look at the screenshots. The only time you see duplicated pixels is where it's drawing a texture that's being enlarged beyond its native resolution.

 

The possibility of 320x200 is given... so maybe you are right here. So the resolution of the Engine would be slighty less, which is nothing real to care about, because the objects are mostly bigger as their "native" resolution.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...