Sheddy
-
Content Count
798 -
Joined
-
Days Won
1
Posts posted by Sheddy
-
-
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
-
It's an interesting idea - so I hope someone does try it
-
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
-
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
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)
-
Sheddy>We are still stuck in the eighties here, after all, this machine is dead!
If this machine is dead.... why is so much happening about it?
I think: The problem is in the "better" technique of newer systems, which is not really better.
Having a look at LPs... this year are more sold than the last ten years. Why? CD and DVD are "so much better" (but not in all cases).
>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/
Looking back to 1989 I (a true homebrewer) didn't truely stand on shoulders of giants. PCs were better typewriters...
I assumed all possibilities I knew and made a GAME that was looking better than most of the Demos in that time.
In the same case I did the MCS pictures...
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
-
sheddy, the point is that we are not talking necessarly about homebrewers...i coded demos only... (ok... several basic/MC simple games on VIC-20 and 8bit atari) and demo is something completly different than game coding but...
i was supprised how many from my point of view crap games were out there (i have even tons of them at home... on last weekend i found my original rampage disc...)... and how many of them i have bought...
look at www.c64.com and compare the games (no i don't count spectrum as a comparable machine...
no i don't want to start this discussion again... but where is the attidue to push the machine to the limit or try different things like emkay said?look... take a look at trailblazer.... a nice game with fast raster gfx... but WHY did they use gr.7 for the background and not like dimension X highres or gr.15??? it's "just simple display list changing"... they might be reasons but... i do not understand...
where are the rescue on fractalus, koronis rift, rainbow walker, summer games ii, ultimas, whizball, comet, pirates, seven cities of gold, pitfall 2, pole positions, dig dugs, etc....
i miss the innovation... and i have to admit that TMR might right...did atari coders ever thought "we are pushing the machine to the limit?"
why have Epyx experimented with overlay highres sprites to get better looking sprites in summer games and the atari version is absolutly bad compared to the c64 one?
but why on the other hand did archer mclean invented a fast softsprite routine for dropzone + international karate?
.... oops... back to work...
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!"
-
I mostly agree with emkay: this attitude has hurt and continues to hurt the Atari 8-bit. For one thing, always referring to the past is negative.I sometimes feel we're still stuck in the eighties... Why is it that so few people want technical PROGRESS? C64 users are really smarter: more thinking, more views, more complex games, nicer graphics...
Look at what's been done! Watch those European demos! There are tools available to do more than 1982-like games. This is year 2003 and the resources are numerous! Listen to people like emkay, Heaven, JBJ, Fox, Raster...: they know their stuff! Open up!
Classic games are OK but this is getting ridiculous. If people think a more complex program on the Atari necessarily has less playability, they're heading for the wrong direction. I'm not saying better graphics make for better gameplay but more ambition will benefit the entire community. Heck, if some of you don't want anything better, don't bother, just take your VCS!
Sorry if I sound aggressive but I've been an Atari 8-bit nut for twenty years and it's always the same old song...
++
RC
++
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
-
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.
-
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" ?
-
Y'all getting senile?ELITE!
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
-
Okay, a slightly loaded question; how accurate is Atari800Win's palette compared to the real deal...?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.
-
EDIT: I should mention that this way of combining screens will make the blocks semi-transparent. Dunno if that will be a problem.
calamari
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...
). -
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:
-
How much does it influence the speed of the game between 10 and 40 DLIs?
With approximatly 40 DLIs it would be possible to multiplex PMs .... maybe .... to create Jump and Run Game platforms for the "Hero"(*) to stand above.
* The Hero could be made by a character-based Softwaresprite
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
-
@SheddyHow much DLIs/colorchanges are you doing in Space Harrier ?
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:
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Favorite 8-Bit Game Never Ported To The Atari Series
in Atari 8-Bit Computers
Posted
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.