Sheddy

I think if the Atari had been commercially viable for just a year or two more, I'm sure we would have seen these kind of games done just like that - ported over from c64. I wonder if the c64 having more characters in its character set for redefining has anything to do with it not being done like that on Atari? - I would have expected to see at least some attempt at it too.

Lack of colours per scan-line always a problem with our baby Atari The c64 has its arse whipped from that point of view. I think G2F style mode would place some pretty heavy restrictions on where things can be drawn on screen. I can't see it working well with how OutRun moves things all over the screen. But maybe if limitations are worked to... IMO Char-mode always looks ugly for these 3D style games (although it'd certainly help with speed). You need the freedom of y movement to give a good effect of moving into/out of the screen convincingly - things won't look like they're actually on the road otherwise - even with as much character redefinition as possible i think it'd be working against the grain. I imagine going over the "hills" in OutRun would not be very pretty sight. 80x192 is too chunky for these type of scaling game I would say (check out Koronis Rift) although it'd give us some more colours to play with. 160x is really too chunky as well. 3D engine for OutRun? Just for example I'd look at doing an interlaced 160x96 graphic mode. (Using colour interrupts on background is going to mess with using any soft-sprites otherwise) For even a vaguely faithful port of the original, the road alone is going to be quite CPU intense I would guess. There are a heck of a lot of huge sprites being thrown around. The number of those would have to be cut down a lot, to render them in a reasonable time - maybe only one third the amount of the original at a rough guess (and probably smaller too). There is a lot of background clouds/mountains etc. to scroll around too, if we try and keep faithfull. I would imagine we'd be lucky to hit a top speed of 12fps, and probably slower most of the time. I'd probably use the players for the players car and move that in VBI to keep the game responsive (12fps doesn't give much feeling of control) Maybe missiles could help with lines on the road, but there wouldn't be time to reposition them all every scan-line. So maybe they'd need to drawn as graphics too. All in all, I think what was done with Turbo OutRun on the c64 is really pretty good considering the problems to be worked round. OutRun on the c64 looks like a sad and rushed and cash-in on the license though. Very few elements of what makes OutRun OutRun, actually seem to remain.

If the dark areas on the hi-res are taken as just see-through, then there is an advantage with doing the graphics in hi-res (they just need OR'ing together). Doesn't look like Kult does that though. It does seem to do proper masking of the sprites - there is no speed advantage in hi-res for masking sprites as far as I know.

ATASM's a great MAC/65-like cross assembler http://www.cs.utah.edu/~schmelze/atari/atasm/ I second Atari800WinPlus 4 as one of the best emulators for developing could be interesting - someone here http://www.cox-internet.com/wa5bdu/amac.txt gets AMAC working on the XFormer emulator (although that isn't such a great emulator IMO) but doing the editing on PC

This game is the only reason I've found for stealing the paddle controllers from my 2600! It's just such a fun game, and expertly implemented.

What you're wanting to do is still called interlacing A TV only displays a complete picture every 30th of a second (NTSC- a 25th for PAL). The 1st 60th of a second it only displays the odd scan lines, then the next 60th it displays the even scan lines - these two fields "interlace" each other to give a complete frame every 30th of a second. The code to swap between two different screens is not too mind bending when you get down to it: One way is to have 2 display lists that point to the two different screens. But instead of having the jump at the end of each display list pointing back to itself, point it to the other display list! Make either of the display lists active, and they will happily swap between each other every VBI without you having to get involved at all! That is a simplistic example because it doesn't deal with any palette swapping, double buffering, or cope well if your code drops a frame ocassionally, but it just shows how neat display lists are! So you can do pretty much the same thing yourself in the VBI. One of the easiest ways to alternate between things is to do an EOR EG lda whichdlist eor #1 sta whichdlist beq dlist2 dlist1 ...code to set dlist1 and palette colours jmp out dlist2 ...code to set dlist2 and palette colours out the whichdlist variable alternates between 0 and 1 every time eor #1 is done. That's all probably too simplistic for what you're wanting, but it's a start

Yeah, seems strange to start with, but we shouldn't blame the emulator. It's happily doing the right thing at 50Hz for a PAL atari or 60 Hz for an NTSC one. However your PC video card and monitor is probably set up nice for that ultra smooth game of Doom3, and running at 85Hz+ !

In my experience, for the best results with interlace using emulators, set your monitor refresh speed to the same as the Atari, ie 60Hz for an NTSC Atari. Also make sure the vertical sync option is turned on in the emulator. When interlacing if you can also interleave the scan-lines and/or dither the pixels horizontally the results are much easier on the eye. Without breaking up the image in some way, large areas of colour appear to flicker worse otherwise (Unfortunately I haven't enough cycles left over to use these techniques effectively on my game) Keeping the luminances similar on overlapping areas also helps minimise flicker. For some really neat examples of interlacing check out any HIP/TIP pics, or there are some example pictures given with the Lepix program (see recent thread on the 8-bit forum). You can pause an emulator to see what it's doing on the different interlaced screens.

Thanks for sharing the code Cybernoid - I'll be looking at it with a fine tooth comb - My experiments with combining channel volumes on samples were awful! In fact I was even thinking that when using volume only the full excursion of the speaker was effected by just one channel. Nice to know it can be done

Nice one Cybernoid - Pretty good sound quality Just curious regarding your first one - 6 Bit, 4Khz. (I'm too lazy to dissable your code I guess) If your're not wiggling the volumes faster than the sample rate like the other example, how're you doing it then? thanks!

thanks for sharing - Very nice - has a good "look" to it already, even at this early stage. Of course a few little glitches to work out. As you are already doing, I agree it is important to get the basics working first, so you have more time to get the "feel" of the game right. I know this is only test level - but some gaps too big? Depending how big levels are, testing to make sure they are all playable could be tricky. Mind you, when it is decided exactly how many pixels the ball can jump across, it should be easy enough to make sure that when designing level that this is never over stretched. (But then again, I suppose there will be power-up to jump much further too!) Have fun

I just didn't want to get the screen cluttered up with bullets for the movie :wink: I really don't know why I still like this game - I've always totally sucked at it. My brother Nick is the expert - just the other day he played our real Space Harrier machine (discretely placed in the middle of our back room) all the way through without losing a life (again). I think he's only done that once before. Guess who's going to do the most of the later playtesting...I might not listen if he says it's too easy though!

Since you all seem to like it.... ...I suppose I'd better try to finish it... The movie was made straight from AtariWinPLus - the only changes to it were the black borders have been cropped to try and make the file smaller.

sure - I'll put some on the web site soon OK - some new pics are up on my www site Thanks very much Tezz Look forward to seeing your progress with Bubble Bobble (I notice yours got a mention in RetroGamer mag this month - they had a big article on Bubble Bobble )

You may need to install the XviD Codec if you haven't already got it. But here's a clip of Stage 2 Dial-up users beware - it's nearly 6MB (and it won't stream either )

sure - I'll put some on the web site soon

Thanks for the question - but the only news is that it hasn't completely stopped and I have been working on it again for a few months now. I put a small update on my website last month (or was it the month before - my doesn't time fly by!) Progress is slow (I'm at the end of redoing Stage 2 now) - but at least something is happening. I did a pretty major rewrite when I decided to move over to having it cartridge based. All the graphics drawing code changed. Also I've been redrawing all the graphics to be a more faithful to the original (well, as near as the A8 can be in my non-artistic hands) I'm not releasing any more code, but I will probably do a movie clip now I've figured a format that can do the interlace without looking absolutely terrible (Xvid). I hope people will think the rewrite is worthwhile. There's some sweet features I'm very pleased with (OK I'm a bit biased!) like parallax scrolling and samples playing while everything else is still going on.

... what to say? Take a tracker like RMT plus free POKEY programming abilities and some user-definable software-controllers at vbi speed, to get something similar to those tunes. Thanks - I was starting to have a look at RMT. Was kinda hoping I wouldn't need to create more routines of my own, and use it for the sfx as well as the in game tunes (I guess I'm just lazy) . Without delving into the internal code of RMT it doesn't look like it is very easy. (I'll have to e-mail Raster at some point, I think)

Extra byte saving and less cycles on your single bit per pixel mirror routine, Rob Doubt I would have thought of that approach. Ideal for mini-game.

yep, absolutely right Nukey - thanks. How could I miss that? In such a small piece of code too! - now you know one reason why I don't normally post much (even preview is no help for some people!) this code might actually work... ldx #0 ?1 stx mirror_this ldy #8 ?2 asl mirror_this ror a dey bne ?2 sta mirror_table,x dex bne ?1 mirroring 2 bit pixels - trickier, but more interesting - I'll have to look back at some of my code on how I did that - don't think it's as elegant as these though, as it wasn't a time critical routine

knew it would like to see the combat code too

creating a lookup table will of course be quickest in game. something like the following should create a 256 byte mirrored lookup table (this is a risk without testing or the edit button! look out for the fixes later...) ldx #0 ?1 stx mirror_this ldy #8 ?2 asl mirror_this ror a dey bne ?1 sta mirror_table,x dey bne ?1

Oops, Emkay already said it's an updated SidPlayer - hurry back edit button!

I want to do something better with the music and sfx on SH, but anything that steals too many cycles will be a problem. Something like TMC may be OK though (I don't know many good Atari trackers, or how to incorporate them into a game) I agree - these 2 songs are great sounding music - they do sound digitised to me though, maybe using something similar to the excellent SidPlayer. Awesome sounding, but far too many cycles for in-game Space Harrier I expect.