Jump to content

Sheddy

Members
  • Content Count

    806
  • Joined

  • Days Won

    1

Everything posted by Sheddy

  1. 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/
  2. 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 )
  3. 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???
  4. 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.
  5. 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
  6. Thanks for your thoughts on this, people. I'll be making some changes because of them. Joey Kay here's some shots:
  7. 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
  8. 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:
  9. Just didn't want people to think you're cheating by using the anti-aliasing that jpeg images end up with Here's a .gif of the relevant bit from the emulator.
  10. Can you post the pic as a .gif or .tiff emkay? ...We can't see the details of the clever stuff you've done because of the jpeg artifacting Thanks
  11. Golly, does Andrew Davie know this? You better stop him quick before he actually finishes his game that uses it! Heck .... what is he doing? A game with triple interlaced GTIA-Screens? ... and in 10 years all ATARIfreaks are blind? Do you have a link? It is unbelievable to me anyone would even take a thought on this.... Check out the Fu Kung forum emkay - it's for 2600, (and pretty interesting too) But yes, you might need the So "Chronocolour interleaved " = ColorView? What's that "TM" all about then. Get an American patent on it too Andrew, should be no problem! I'm curious to see how the objects look when they are moving in Chronocolour - Because of the triple interlace, I would imagine you'd get some kind of ghosting effect... Cheers for the MCS explanation, emkay - interesting
  12. Very Interesting! Umm.... I don't know whether I should be happy or sad! But thanks anyway for the kind words, people. The graphics are less accurate on that old demo, but because of the full screen size and some oversized objects (compared to the original), the objects have more detail and the scaling would look better, I guess.... so the question is, what should I do now? Carry on regardless....or tweak what I have been doing recently...or revisit the idea of 4 colour (maybe with a colourful twist, as emkay suggests)
  13. It is no miracle The 64 colors I mentioned in earlier threads are a calculation of the colors that are truely different and worthy to use in Games. The MSC uses up to 9 colors at a scanline. The usage of the colors is still depending on the Game. So you can chose to create pictures by using fullscreen "DLI" and you can add colors by using the GTIA bug of mixing the colors... so a blue dot with a yellow dot under it in the next scanline will become "real" green... You have to find the right technique to produce graphics with as much colors as possible for each game... Another possible way to produce a scrolling game ist to use a fixed mcs screen (8 fonts and 5 colors) and use the PMg (3 color in overlay)with much as possible multiplexing to create a scrolling screen and use the fixed background with its 5 colors for the sprites: For Turrican you need: Black White Brown Blue Yellow Red Green will be mixed by blue and yellow... Brown can be mixed by red and green... Due to the fixed background, you can use as much DLIs until no more CPU time is available.... So it is only a clever usage of the capabilities ... nothing else... In theory it was possible to create games with a PMg-multiplex-screen and using Hi-res Sprites. Due to the fixed screen you could left the "HERO" allways in the center of the screen and make it colorfull with DLIs... Thanks Emkay - I'll read your other threads as well. I'd like to have the extra colours but reduce the flicker; I can't do some of the really clever, smart techniques like Andrew Davie's "Interleaved Chronocolour" (and also TIP/HIP of course), because they take away too much CPU time, and are not so suited for fast animation
  14. Thought you all might be amused to see this... an early proto, before I gave up first time round (as it was too crap) Avram asked about my first attempts at Space Harrier in another post, and I had good hunt round and found some of the original disks - surprisingly some of them still work after all this time. I finally managed to get it into an .ATR image after giving up on ProSystem and just using APE. I think this dates back to around 1991 before I had some sound effects put in. strangely in some ways it is better than what I have done this time around ...full screen, up/down scrolling when the man dies...but hopefully you can see why I don't want to do a 4 colour only version.... shdemo91.zip
  15. I'm sure it could be done - but I'm not so sure it could be as good.. OK, you CAN multiplex Players and Missiles in x position, but only at the expense of having DLIS every line where that is required, or more efficiently, a VCS 2600 style kernel. Both options severely limit the amount of CPU time you have left for any actual gameplay logic or anything else. Sorry, but the C64 sprites are just awesome compared to the Ataris - if only just for the fact of getting all 8 of them on a scanline at once, 12 pix wide with 4 colours each. Even with horizonal multiplexing on the Atari, it can't come close to that. Sure, things are different vertically, and on the Atari its easy to split them this way - whereas the C64 may well be a bit more tricky (I'm not 100% sure about this since I'm not a C64 coder) Parallax (which is always a big cheat on nearly all 8-bit systems) I suspect is also harder, due to having only 128 characters in the character set with the Atari, and having to resort to interrupts mid screen again to up the count....
  16. I think when a system has reached a certain amount of market penetration, the one-upmanship between developers becomes much greater (plus there is marketshare to go for). To show you can do the best on a leading platform is an intense buzz, I suspect!
  17. Tell me more about MCS mode, guys. EmKay is that where you stretch the players and use them as background colour? How'd you get to 64 colours that way? Maybe 8-bit developers did not push the Atari as hard as the C64 in the day. During most of the Atari's lifespan it proved more than capable of making good versions of simple games, without a huge amount of intense programming effort to REALLY push the boat out. It had no real competitors. It was only towards the end of its life that arcade, and other systems games were becoming more sophisticated (visually and sonically) that people even felt the need to try for better. The C64 was born into this age of vast improvements in arcade graphics etc. so it was necessary for its developers to keep up with the trends...the Atari was more or less dead by this time, so no one tried - except the demo coders and crews. They were not responsible for the lack of impressive software - they only showed what could be done, even if it might not be possible to make some of the effects into a full game. Still IMHO the gameplay is more important than graphics or sound. Maybe someone could make something fantastic looking and sounding but utterly unplayable - but to me there would be no point in that at all. Each has to complement the other, so there are limits to what should be done, as against what could be done. just my 2 cents...
  18. Maybe! You got me thinking and I found an early version of the original ........but can I get my darn ProSystem to work Won't detect the drive all... Had enough trouble getting APE going too - as it is it doesn't work on my nforce2 PC, and I had to put it on our "file server".
  19. Would have loved to have seen those protos. Maybe Tempest knows more, but we only have theses rumours I find it hard to believe BallBlazer only runs at 20fps! It's just so well done though.
  20. You've got some interesting sounds out of Pokey
  21. Even though I've bought every issue (including the ultra rare no.1) they just don't call Edge do sometimes cover retro - but they are not really interested in ports - only original content. BTW Paul Slocum got a small mention in there last month, with his excellent "Marble Craze" for the 2600
  22. I'd love to make the game work on all Ataris, but there are a couple of problems, as sTeVE has mentioned. RAM is a problem if you want more than a "standard" 4 colour screen - which I refuse to use for this game ( it does the original Space Harrier no justice at all - its main pull is the graphics and sound - my original work on this game in the late 80's was 4 colour, and I just didn't like it - although it was blindingly fast). I'd need all 16K RAM of the 5200/400 for the screens alone, and preferably 24K to maximize the speed with triple buffering as I'm doing at the moment. 32K ROM size on the 5200 would be a major problem too - interested if anyone knows how to work round this. Also intrigued by prospect of adding RAM... Until I hear a reply about officially licencing the game, either yea or nay, (I rather NOT just produce a clone), or being given some kind of response from Sega or Elite Systems (they haven't replied to anything I have asked via e-mail, so far), I don't want to get invoved in anything that would involve money changing hands (which involves any kind of Cart of course) Saying that, however, I'm very keen on the idea of a mega cart that could run on 800/800xl/600xe/130xe - anything with 48k or more of RAM. Also using the full expanse of the cart, I can take away a lot of the limitations that I've had to place on myself: I'd do more colourful objects - I'm limited to 4 colours per object right now. There's another faster sprite routine that's waiting in the wings if I get a whole load of rom space (and I mean something like 2MB ) ...And the rest of the sound samples.
  23. Ah ha! so this is the secret project for which you wanted to know about voice samples. Wish you well. Don't forget to check out the arcade version using mame. Always nice to try and get as close to the original IMHO
×
×
  • Create New...