Sheddy

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.

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

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

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

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) Quite so, it'd still be the wrong shade of beige 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)

Well, not a lot is really happening. Just speculation! Let's go and do some of the good stuff, like TMR suggests I know you did some fantastic stuff. It's a shame you were the exception to the rule, and more people didn't push the Atari further. Still it all boils down to simple economics - supply and demand - No money to be made on 8-bit Atari, just as games were getting more interesting and complex - and coders were taking up and meeting the challenge on other platforms

I think you pretty much answer your own question Heaven, with the examples you're giving here, if you're not talking about what people are doing today. LucasFilm, Archer McLean etc. were the ones showing innovations when it mattered. And after that?....heard of the expression "flogging a dead horse"? That there are only a relatively small handful of exceptional titles is not surprising, given the quantity of software. As others here have eloquently quoted - "90% of everything is crap!"

We are still stuck in the eighties here, after all, this machine is dead! It's asking a lot to expect homebrewers to be able to surpass some quite awesome efforts from back in the day. Only recently is there any renewed interest in these old systems, and you can't expect amateurs to produce triple A products straight out the door, even if they're "standing on the shoulders of giants" and have a lot more help these days/ A demo is not the same as a complete game. I doubt even the demo writers themselves would claim to be able to turn some of their superb efforts into whole games. Some of the effects leave little room for anything else to be added - fully using the available memory and CPU cycles. Not to say anything regarding the amount of time and effort required to develop said games. Still I agree that there's not a lot of point doing what has been done to death before. It's just that everyone feels obliged to write a space invaders clone to get themselves started

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.

Nearly forgot: PacLand (Please JetBoot, resurrect this project!)

I think you guys are a little harsh on the old games - because it's damned hard (if not impossible) to create a playable game with moving graphics using some of the techniques Emkay is describing! Just my opinion but - for several years after the 8-bit came along there was nothing to touch what it could do using fairly standard Atari techniques such as player/missile reuse and DLIS, and they were easy to use (these were used right from the beginning. Don't know of a much better documented 8-bit than the Atari). Only a year or two after the C64 came along, did anyone really up the ante, and programmers were seeing stuff in the arcades, and thinking "I wonder if...". The Atari's market share was plummeting by this time, so the only market left was for bargin basement budget games - why chase technical glory for no reward?

OK, so most of these were arcade as well as 8-bit ports, but... Space Harrier (of course) Out Run Mad Planets/Crazy Comets Super Sprint Sanxion (or any other good horizontal shooters from C64) I Robot (Fox, if you're ever bored..) and Elite (Mark, don't let David Braben put you off, I really can't believe he gives a stuff about our obsolete systems) 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. What do you think about this Mark?

Oh Wow! One of my all-time favourites on little Atari! A bunch of us used to play this game lunchtimes at work (quite a few years back now ). Absolutely excellent multi-player game. Just love the choices of weapons, shields etc ("So....How do you want to die today?"). Looks like this could be a really good version too, although I only fired it up once so far. Thanks guys for making this! I suppose if the "free sex" links were not free but to paysites, you would get taken to Cray computers or ASCII "Blue" ?

As an aside, i heard a rumour ages ago from someone not entirely reliable in the industry that an excellent Atari 8bit port of Elite was done and dusted but some clause in the license Firebird had said it couldn't look better than the BBC version and it was canned... anyone know if this is true? I think you'll find Mr. Wrathchild knows more about an Atari Elite than most... 30-Jul-03 Edit Maybe I should have noticed Mark's post mentioned Atari Elite before posting this

Pretty close, but things always look different on a video monitor vs. VGA. You just don't get that same intensity. Okay, so if something appears right on 800Win it's a good bet that the real deal will be fairly close to perfect too right? I'd say yes. I run my stuff on a real XL to select colors, because sometimes certain shades look sharper next to each other than others. This can be important in a small area like a multi-color sprite. For the most part, though, rely on the emulator and you can always tweak later. If I had a PAL XL, I'd loan it to ya! Any chance we can hear a sample of the music? -Bry Firstly - nice work, TMR! If it's any help, I found the closest colour settings for AtariWinPlus 3.1 to my UK PAL Atari 130XE (but unfortunately running on a crappy old TV) was the "real" palette which has to be selected as an external palette.

Thanks for the compliment about my demo Calamari! Transparency is no longer my enemy - only flicker :wink: Looking forward to your stuff. I think considering the deadline Ziggystar is aiming for, he has done a good job here responding to some of the concerns regarding a 3d look. It's too late in the day to make major changes for the release date intended. Some of the other suggestions would take too much experimentation and require large changes, I would guess, even though they would probably look better.

Dedicate 1 colour of each of the 2 screens as black to work round the transparency effect - Works OK for what I'm doing with my game. Flicker should just about be acceptable as long as no large filled areas of colours are used - for that and then you need to interleave (which Zylon knows all about)

I don't know the answer to your questions Bry, but if you can make head or tail of it, there is some info in the 8-bit faqs section about Ramdisks...(I still haven't quite figured out how those larger ones are supposed to work from the info there though... ). http://www.faqs.org/faqs/atari-8-bit/faq/

OK guys, these ideas could be brilliant for static pics and maybe fairly low CPU usage games - what's the best way to get more colours with lots of software sprites, without sacrificing all the sprites too???... (not that I have anything particular in mind )

Charmode sprites can certainly be done very nicely. Steve's own Menace proto is a fine example. But I can't get my head around a character set sprite routine (yet), that would be as quick as one in a bitmap mode - because of the memory layout of the characters - but then I'm not used to using the char modes much, and there probably is a good way (c64 folks at least must know the best ways!) I imagine there could be a really quick routine, if there are areas of a sprite which don't need to be eor'd (maybe when its a big sprite, and has solid characters in the middle), then just the character code could be changed rather than writing the whole "bitmap like" reserved characters? You'd need lots of pre-shifted versions of the characters for smooth vertical and horizontal movement. Could that work, or am I not thinking that through properly???

Yep, you guys are right. Thanks for straightening me out on that. Should have checked my facts before shooting my mouth off! Strange how I got to 114 though.

Actually emkay, I think we may both be wrong! I think the 114 cycles per scan-line already allows for DMA? Maybe someone else can confirm that, without us having to plough through the hardware manual? reasoning as follows: the Atari is designed to do one clock cycle per colour clock. There are 160 colour clocks in a normal size screen. The most Antic can fetch is 40 bytes every line (normal mode), and Player/Missiles have to fetch 5 bytes. 160 - 40 - 5 = 115, is darn near 114. Surely that can't just be a coincidence? Ah, I forgot the Display list also has to be included. Once that is set up for normal screens it will take only 1 byte per line. If that's right, I think the figure of 15% of stolen cycles is fairly accurate. Just to confuse things further - memory refresh also has to happen, but I don't remember how many cycles it steals - I'm sure it's more than just 1 per scan-line though! I've also tried to think what useful work could be done instead of waiting for WSYNC - but I've not come up with anything useful, except more colour changes, etc. EG Time slicing code has too much overhead

Thanks for your thoughts on this, people. I'll be making some changes because of them. Joey Kay here's some shots:

OK - that could be fun! Why don't you have a go, and post a proof of concept in the programming forum? The DLIS do affect the speed a fair bit. Here follows a rough calculation: Approx cycle count per NTSC frame = 1,790,000 / 60 = 29833 cycle count per DLI (assuming a WSYNC) = 114 cycles for 40 DLIS = 114 * 40 = 4560 4560/29833 = 0.153 or about 15% of the total processor time if I did the math right That doesn't factor in any DMA fetches though

Only one colour gets changed on each DLI. The amount of DLI's varies from stage to stage. Some of the stages like stage 1 only have about 10 DLI's, stage 3 now has just over 40. What makes you curious??? PS regarding 3d engine...I do cheat horribly wherever possible Hardly any real 3d calculations are going on. Normally the "scenery" (things on the ground like trees, bushes etc. and rocks in the air) have one division calculation on their x position. y position is all table driven. Nearly all the aliens run in 2d, only some bosses have 3d when I can't fiddle it in 2d to look right :wink: