Sheddy

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

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

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

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

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.

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....

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

(...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

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

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

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

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

Damn! still a couple of months for us PAL users to wait.....and it'll cost more too.

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.

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

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.

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!

Andreas, It'll be in my will to post the source code to the web site....

I never thought the packaging very important on 8-bit. - it rarely got very interesting on the 8-bit in my opinion. and..... there were so many different (and non-consistent) styles from loads of companies, unlike your 2600 or other consoles. I think it's that consistency that gives the packaging appeal - I'm not an artist, but where would you start on something for an "Atari 8-bit" look? Maybe Atari's own carts? Even their presentation wasn't a patch on the 2600 and 5200's, (and there aren't that many carts anyway). The boxes were nearly all stupidly large (even that wasn't consistent)- ok with some nice artwork, but the carts themseleves just have some dull text. Do many people here collect 8-bit, still shrinkwrapped software like on the consoles? I'm guessing hardly anyone because the packaging is mostly just horrible! Hey but that's just my opinion. I'd love people to prove me wrong here:)

Nice work, Mark. Like you say, any optimisation can always come later. Hope you carry on

Not used BCD much, but, apart from the obvious that you are not storing Scorehi2 in this example, it should work. Where is Scorehi2 in memory - Maybe it's getting overwritten by something else? Just try moving it somewhere else, see what happens.

Sorry I have no useful info on this. I just use the built in monitor too. Single step sorely missed from DDT. Luckily cross-assemblers are fast for generating test code... But I had to ask Mark about that mention of Elite though! I heard there was a demo of Elite for Atari 8-bit a while back. Is this the same thing and is it something you're still working on? Chris

Eidolon, Koronis Rift - Lucasfilm Games - superb games - played them lots on my 800XL - definitely work on 64k Ataris (all XL, XE) - think they will work on 48k ones too.

Can't remember how the arcade controls worked, but if it was like mame has it, then I don't think how you have it now affects gameplay. mame version doesn't spin the plane any quicker by you pointing the stick in the direction you want the plane. left/right for spin is fine IMO. I think you know my opinion on the clouds. It would be nice to have at least some big clouds Even if you only have them when things are quiet elsewhere on screen it would be cool.

Way to go on the Basic tutorial Nukey! Liquid Sky - if you're still stuck, could be zeros and o's problem. all but the sound and goto should be zeros. Just double check Cool idea for a game Atari Master. Remember clearly something similar on 8-bit, instead of more balls, the walls shrunk each round. It was a great game - very addictive gameplay. Can't remember what it was called - Think it was a type in listing from a UK mag..