Jump to content


  • Content Count

  • Joined

  • Days Won


Everything posted by Sheddy

  1. How many cycles is the new VBI. If it's a lot, maybe something is overrunning now? How far down is the last DLI - could it be holding back the VBI (probably can't be that far down.. but something to double check?) What timers are you using. For something to take that long to crash it could be some code that happens only when your slower ones are doing things. (Does that make sense? I mean, maybe you have a timer that only does something every second. And that thing is what goes wrong. Either screws up the stack or overwrites or something..). This doesn't explain why it works on the emus though. Atari800 is normally very good. It is only the exact horizontal scan-line timing it doen't emulate 100%. Is there any way you could have got a bad burn on the EPROM? (I know nothing about doing them though) Good luck. I hate it when something like that happens. I've had to go back to an earlier source and re-write the code again to get to the bottom of some strange errors.
  2. Defender (loved but never mastered) Space Harrier (loved but never mastered) - made me go "WOW!" first time I saw it -My brother wants the full size sit down for our 2 bedroom house.....hmm. Robotron (loved but...notice a pattern here?) Phoenix Mad Planets (such an original game, but you never hear much of it) Asteroids R-Type (original powerups) Strider (this was so varied for an earlier game) Super Sprint (favourite multi-player) Marble Madness (frustrating, but oh so pretty) Joust (nearly forgot this one) Truxton (frustrating, but with the mother of all powerups) Donkey Kong That one where you hammer the critters that pop out the holes....such fun! Berzerk (perversely I prefer the home versions coz they're easier!) Ordyne (...maybe it was just the flashy rotate stuff) Assault ("" "") I Robot (made me go "WOW! first time) Salamander (guess I'm a sucker for speech and gimmicks) Gosh! - that's a much longer list than I thought it would be. Note complete absense of Dance games though - Will any guys own up to liking them, I wonder? :wink:
  3. This is one sweet game shame the 5200 never came out in the UK Cafeman, do an 8-bit conversion , or release the full thing for the emulators sometime....PLEASE! Chris
  4. Fox and the other Taquart members have been kind enough to let me pass on their color editor for TIP mode and some example source code for displaying the TIP picture (in XASM form). Their TIP conversion of the space harrier title page has come out pretty good too (check out shtitle.xex) What nice guys Thanks! sh_tip.zip coloreditor.zip
  5. Please spare my blushes, O Merciful One. I kneel before thee in humble penance... Cheers Tempest.
  6. Cheers Jon for that info. It may come to that when I get my new 130xe
  7. I wondered a few years back why the characters in Doom were so chunky when zoomed in - one possible reason, I figured was because it could be a good way to hold the data - already zoomed. Tried a few routines on the 8-bit and it made it easier to have a byte per pixel for scaling down (rather than up) So you have a maximum of say 4x zoom in the 160 pixel modes. All you do is sample the data pixels every 1+zoom fraction and output them a pixel at a time into a temp zp, then chuck it at the screen when it gets a full byte. If you want to do an exact to pixel size you could use the Bressenham line draw method (keep adding size you want till get to actual size and sampling next pixel, then skip a pixel when you reach that limit) I expect demo coders have a better way of doing things, but this did actually work quite quickly. The hardest bit was centering it up..... Chris
  8. Never saw some of those games released over here. For whatever reason we didn't have that many carts, and managed to miss some of the stinkers. Favourite: Joust - Superb as a 2 player game. Least Favourite: Missile Command. It's ok I know - but the worst of our small collection. Chris
  9. Hi Steve, shame Menace never came out. Looking good in mode 4 already . Were there any plans to use the 5th colour? Mark, thanks for the explanation, so the way you address the screen is pretty much like a bit-map, plus you get the extra colour - nice! On alternating the players position every vblank, I can tell you that in my experience, yes, it will flicker, but it is less noticable if the colours are kept quite dark, but the intensity does also drop...so it needs a bit of compromise They also have a kind of see-through look to them, unless you put a black mask behind them (which kind of spoils any speed benefit - but you do get extra colours) Regards
  10. Mark, what is the "4 colour bit pair flipping" table used for. I get the mask one, but what's that one used for? For flipping left/right? Cheers Chris
  11. Neat! Like how you've got all the overlaps working right in Antic 4. Without plowing through the code, any tips you can share on the best ways to do this? I assume all of the Barbarian is chars that get redefined every frame? How many you have to use - there'll be enough left for other baddies? Chris
  12. OK, Heaven, let's see how this could look in TIP! Please pass to fox. I need to get into XASM anyway, so this will be a good excuse - The latest ATASM has changed how .includes work which I haven't got to work with relative filenames yet ( .folderfile or ..folderfile etc.) It has picked up some nice new features for cart coders though Thanks, Chris Edit: forget the part about relative filenames, that does work...it just does not accept a file name as part of a full path...ie %1 in .bat files won't work.
  13. Calamari, First guess to what the problems are: I had problems similar with Atari800 flickering and strange interference line too on my stuff. For mine it was the refresh speed of the monitor - it must be put in a 60hz mode (for NTSC), or it will not match the emulator's atari refresh speed and get out of sync on the screen drawing. (You need to set the vertical sync option on the emulator too, but I could never get version 2.5c to work right even then.) Also it seems to require a bit of luck with your PC setup as to whether it'll work right (video card, proc speed, etc) Must dash. Want to try your pics out and the Barbarian demo on the sprite topic....
  14. That would be fantastic if you can, and get time! I definitely couldn't write my own display routine at the moment without at least a bit of help. If fox has one he doesn't mind sharing, that would be even better. I'll try get a good shot of the title page from Mame onto my web site and post the link to it here if you want something to experiment with Thanks, Chris
  15. (...sigh) another DOH! for me then - 2 in 1 topic - impressive, even for me! Must get the C64 emu up and working again since the move to XP... What are they using the sprites for then? (can't imagine them not using them in a C64 game!) Can your lovely wife work out when we're likely to see any more IK+? Try showing her the icons post to show how much you care about her and appreciate her translation talent (or just use it as emotional blackmail ) J/K! Chris
  16. Unfortunately, I wouldn't count on it...the C64 is using its great hardware sprites, which have no respect for such limitations! But this does sound like a good compromise, which could work, if not going for huge carts. 16k for just the barbarian!....so all 64k for 4 shifted versions...jeez! A spite draw with real-time shift would be about 3 times slower than one without shift. May still be quick enough though to run in 60/50fps (or certainly 25/17 fps). The sprites are large but not that huge on Barbarian, and there's only a couple at once. Only other things I can think that might help (a bit).... decompress the other baddies into their shifted versions only when they are needed next. maybe the barbarian can be broken down into smaller chunks. some of the chunks may not change during certain animation. You could re-draw it so that was the case if necessary (lot of work though!) You could lose some frames of animation. Big sacrifice, and C64 owners would have an excuse to laugh. Can't think of anything else now Looks like the IK+ guys don't hang here. They haven't got the English version of their site up yet, so how's your Polish? Chris
  17. I can't believe how sneaky those 9++ and 10++ modes are. Who would have thought you could do that with the vscroll register to save the system doing extra DMA. How on earth did anyone think to try it! Awesome Chris
  18. Neat stuff everyone! Cool pics. I remember seeing some Technicolour Dream pics (or CIP, Calamari ) ages ago, and wondered how the hell they worked. Now we know! I don't think this is down to a GTIA bug here though(?). I seem to remember if you look real close, you can just about see the grey pixels under the colour ones. Could be wrong though... Sure wish I could do some of this for my game project (the sheer number of dlis will slow it down too much, I reckon - and it struggles already! ) If anyone else (like me) had trouble understanding how the HIP and TIP could make 160 resolution rather than just 80 like normal, Heaven has another doc you need to see, which explains a GTIA bug which makes HIP and TIP possible. http://www.s-direktnet.de/homepages/k_nadj/hip.html Without knowing Gr.10 shifts the display by 1/2 pixel, HIP and TIP don't make much sense. My understanding of this (please correct me if I'm wrong), is that Gr.10 pixels are always 1/2 pixel further across the screen than the same pixels in Gr.9 or 11 (which is kind of bizarre). Since all these modes are 80 pixels wide, the overlap area between Gr.9 or 11 and 10, is 1/2 a pixel, or 160 resolution. With a bit of careful selection of colour and rapidly swapping round the Gr.9 and Gr.10 every VBlank (called interlacing by some), the eye is fooled into seeing more detail - with the Gr.9 or 11 superimposed over the top of the Gr.10 - although it has to look a little fuzzy round the edges because of this. Without this bug HIP and TIP would not be possible - the hscroll register doesn't scroll 1/2 large pixels unlike the C64 (that is right, isn't it?) - So thankyou Atari for that screwup! Chris
  19. Doh! Well that will teach me for not checking! Zybex and Draconus sure look like Antic 4 games - would have thought they could have looked better than they do. I thought you guys were going to pick me up on fact that the code for 256 byte lines "inc screen+1" won't work with the example code ....it would have to be a "256+sprite width" wide screen to work right (or is it 256 - sprite width?)- or recoded somehow Chris
  20. Damn! still a couple of months for us PAL users to wait.....and it'll cost more too.
  21. AFAIK Zybex and Draconus aren't doing anything that smart. They are both in character modes. The aliens in Zybex are just redefined characters. Notice how they don't move that smoothly or overlap other aliens or the background much. That is harder to do in a character mode than a graphics mode I expect you all know most of this already, but here's a common way of doing graphics mode software sprites. It may not be the fastest possible way but it's not that slow (Zone Ranger does it quicker with some self modifying code . See programming topic "Timepilot Technical discussion and help needed" for some insight on how it does it ): Data for the sprites is taken as a rectangle as wide as the widest part and as long as the longest part of the sprite. A faster routine can be written if you draw all your sprites in a fixed size rectangle. Let's use a 4 colour mode with 4 pixels per byte and assume a sprite of 16 pixels wide by 16 lines high. This is stored as just a string of 64 bytes, one line straight after the other in memory. Let's say the graphics screen is 40 bytes wide (standard Atari width). All the routine needs to do is copy the bytes to the screen, then at the end of each line make an adjustment to the screen memory address (add 40 less the sprite width), and just carry on copying. To get the sprites to overlap the quickest way is to just to "eor" the screen data and the sprite data together. The colour of the overlap is not always perfect, but it looks ok. Apart from speed the other bonus of "eor" is that you don't need to redraw any background graphics. Just draw them in reverse order, and the background is magically restored! (The Zone Ranger topic has a post on how to do a "proper" overlap with masks too) To get the sprites positioned to pixel accurracy, it is quickest to have 4 different versions drawn, pre-shifted one pixel further over in each version, rather than try and shift them real-time. Some unrolled code might look something like this for a 4 byte wide sprite.... Assume screen address for drawing sprite at is in zp screen and screen+1 and sprite data address is in zp sprite and sprite+1 clc ldy #0 lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y ; line 0 drawn iny lda screen adc #screen width - sprite width sta screen bcc skip inc screen+1 clc skip: lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y iny lda (screen),y eor (sprite),y sta (screen),y ; line 1 drawn iny lda screen adc #screen width - sprite width sta screen bcc skip2 inc screen+1 clc skip2: ....etc. Repeat for every line to draw. See the adjustment for screen width is quite involved? That's why some demo writers like to setup the screen as lines of 256 bytes wide. All you need then is to use just an "inc screen+1" Hope this helps. Chris BTW, for larger "solid" (not seethrough) objects, a method similar to filling a polygon with texture can be quicker than doing an "eor" or mask on every byte. I found this to be helpful for the space harrier demo draw routines.
  22. Glad to see people are interested in helping out, or it would be sad news indeed. Hope you can find a project manager - sorry I can't help - I am not a project manager either. We all would like to see a full game with that brilliant engine, although it is a huge amount of work. Numen is a superb demo of what Vector could be like - An amazing achievement for a 6502 machine - no wonder many people thought it was a hoax to start with! Good luck
  23. I had trouble imagining how good beast could look on the Atari, but this has quoshed any doubts - I don't know how you could have had any doubts of it quality, Jet Boot - Brilliant use of colour.
  24. Wow! This is a superb demo. Love it. Lots of great things I'd have no idea how to implement to run so fast. The vector engine is especially impressive. Truely amazing. I liked the 160x200x30 colour Heaven! Getting away from primary colours and colour boundaries are a problem I imagine. Excellent! (Shame it has to use so much proc time though) Nice work Taquart!
  25. Andreas, It'll be in my will to post the source code to the web site....
  • Create New...