Sheddy

Could probably go on and on about those things for hours! ...but must get back to finishing stuff on the game. Hope the video below is not too much of a spoiler for these last levels. So only quick answers You may see up to 40 sprites at once. Compiled Sprites. "Paths" are lists of vectors and times - EG go little bit up and into screen for 2.5 seconds, then go left for 1 second, etc. No scaling used - all pre-rendered. Doesn't use a lot of RAM, but does use a lot of ROM! http://www.youtube.com/watch?v=5LpcdfZsjww

I'm more interested in the coding, so that's not really my type of thing. I think it is the original graphics design that makes Space Harrier...the gameplay is not that wonderful really (although I've worked on that for the Atari version). I haven't got the kind of artistic imagination that'd be required to make a good job of it. IMHO even Space Harrier II for the Genesis/Computers (never was an arcade machine) is just a poor and pale imitation of the original. Maybe it's not wise to keep it, but I also feel it takes away some credit from Sega for the game if it is removed. I think it needs some kind of graphic in that part of the title screen...hmm...tricky. If you think there's room for some improvement, I'd be quite happy for you to have a look if you'd like, but only if Sal is OK about it. You may not get onto the splash screen (unless radical changes!), but there will be a credits and thanks screen.

OK, I've posted a video of Stages 13 and 14 http://www.vimeo.com/17620531 Sorry, can't figure out how to embed it here at the moment. [Edit] Ah, youtube can be embedded http://www.youtube.com/watch?v=Yk6Of2NUwGY

The high score save is one of the things left on the to-do list. Haven't got round to it as it needs a bit of thinking through - it could permanently activate any cheat codes that may be added, which is not necessarily a good idea? I'm hoping to have a 64k block left, but may go down this route as, unbelievably, it is getting a little tight. It's a good idea, but I'd just be concerned in case the write fails for any reason it'd mess the whole game up instead of just the score saving.

The finished game cart will work on any XL/XE with 64K or more memory. So pretty much all standard XL/XEs except for the 600XL which only has 16K as standard.

There's a thread with screen captures from NTSC and PAL Ataris, which you may find useful. thanks! I'd forgotten that thread

Why does it hurt my brain to read this - telling always - " i knew it i knew it i knew it"? The Game is Sheddy's work, your part here is something like "riding on the shoulder of giants". The "possible" prize for this belongs to him only. If he wants to share with people who was helping, it has to be up to him. well, not really .... Please do not get personal. I don't think that is a fair way to interpret Sal's comments. I asked for help with music and Sal came up with the goods, for which I'm very grateful.

Thanks for the info, I will try what you suggest with the adding 1 to the colours and Altirra. Though I'm still not really sure how accurate even Altirra is for judging NTSC vs. PAL colour palettes. No, no big rewrites! No such thing as a perfect sprite routine of course What's in SH may be pretty good for bitmap graphic mode games with large sprites, though. PS Hope you continue to get such excellent results with your project Unfortunately the way I decided to improve things over the demo version means it won't be possible to have a disk image that runs on a standard machine like the cart does. The sprites take up too much memory, but like with most standard Atari carts the sprites can just be bank switched in and out of memory as required (but instantly, not slow like a disk) José, not sure I fully understand your question, but I'll write some more and maybe the answer will be in there! Palette on SH changes only every TV frame (50/60 times a second) not every line. There are 2 palettes which alternate, so palette 1, then palette 2, then back to 1 again (50/60 times a second) etc. If you try more than 2 palettes then the flicker is really bad on the eyes. Changing palette every line makes flicker less bad, but takes a lot (most) of the CPU cycles. EG Line 1 - palette 1, Line 2 - palette 2, Line 3 - palette 1 etc. Then next frame Line 1 - palette 2, Line 2, palette 1, Line 3 - palette 1...and so on. Jeff Potter's Colorview shows still pictures with 3 palettes in a similar way. It is probably not so good for a moving game though. Yes, that is the plan, the game is designed for standard 8mbit maxflash cartridge.

Binary file will be free

Yes. Some people do have problems to see the difference here. Producing a game with a copyrighted background and give it away free, will cause no problems. Make a bundle to sell it, could result in big problems. Renaming Bomb Jake (for example) does not save it from some copyright issues. Yes, I know. I tried to contact with Tehkan (BJ's copyrights owner) twice. Unsuccessfully. So I decided to make a small homebrew cartridges bundle. I know that this is a risk but BJ is a great game and I really tried to be fair. I didn't get any replies to my enquires to Sega or Elite Systems (who had the licence for at least some of the home computer versions). Unfortunately I bet their lawyers will not be equally as uninterested!

Thanks! Unfortunately it still has to use flicker, so some adjustment of TV brightness/contrast may be wanted for long periods of play by some people. It will use stereo pokey tunes if stero pokey is detected.

This may sound a little weird, but you really don't have to do that. What I would ask is to make sure you cover your costs of course, but maybe have the price a little lower? (I know there is not much margin in these things anyway)

I can only offer it as a binary, but I wouldn't be surprised if Sal's AtariSales will be able to offer it as a cartridge (I see from a post a couple of months back he has already designed a suitable label) Although I haven't asked him, Steve from Atarimax may also be able to pre-load one of his "blank" 8Mbit Maxflash carts if you ask nicely The coding is all mine. Figuring out how to do things and writing it from scratch is what I've enjoyed most about the project. The other 8-bit versions are way too different from the Arcade original for my liking (with the possible exception of the PC-Engine), so reusing or porting any code was never really something I considered.

I'll get some done in the next day or so. Phaeron is doing great work with Altirra, and I'm using it for pretty much everything these days, so I'm really looking forward to giving that a go. I did have to use Atari800WinPlus for the "interlaced" screenshots though.

I'm not sure it will quite make it in time for Christmas, but maybe when you are getting a little fed up of all your new presents it will be ready Thanks, but it's really just down to using a really big cartridge and me just keeping on plugging away at it over the years. No idea about doing any other games yet, but if I do, they'd probably not be quite as ambitious; at my usual pace of work, I'd never live long enough to finish them! Yes, I suppose it could be read the wrong way - I'll make it clearer. Thanks!

Just to let you all know I've actually got round to posting some new stuff on the website. The website has been redone a bit too - do let me know if it breaks!

you're welcome it should be every 6th frame as Rybags says though. You need to lose 10 NTSC frames every 60 to be same as PAL. Don't know where my 12 came from last night - it was late!

just skip the playback routine every 12th VBI when it's NTSC. I was surprised it works so well, but it seems you really don't notice any timing problems (well maybe some people with amazing hearing/musicality can!).

180

There were quite a lot of buggy GTIA PAL chips released (GTIA modes show as partly corrupted). I used to have one in my 130XE. If anyone still has a machine with one in, just wondering whether the buggy chips pass the test or not?

You're welcome! Didn't want to see you get too held up on all that testing you've been doing on Altirra.

I know it's not exactly of great interest to most people, but since I can't edit the previous post, thought I'd better post a fix for my rather dumb bug in the converter that messes up conversion of some 8Mbit cart images. Sorry if anyone ran into that issue after having great expectations(!) atr2bin.zip

Surprised at what a pain it is to create the .bins in the emulator! Since I've just started playing with FreeBASIC recently I thought it might be good practice to have a go at trying to create this converter. It's a bit of a quick and dirty hack really, but it seems to work on the maxflash images I've tried so far, including newer ones that don't store the unused banks. Please find attached Win32 console program and source (FreeBASIC can compile to a few platforms). It takes the atr path and filename as an argument and spits out a bin in the same folder as the atr if it thinks it can do it. Easiest way to use it is to drag and drop the atr onto the program. Usual Caveat applies - use at your own risk. It's no masterpiece of code, but I learnt some things and maybe it could be of some use atr2bin.zip

I've found ATasm to be pretty good. It's based on MAC/65 which is similar to MA65. It's straighforward, powerful and the documentation is good and natively in English. That's not to put a downer on MADS as it has a ton of features, but it might be harder to get to grips with initially.

looks like Mark added the fix to the 1.07 preview version on the main site. didn't look to see if there were any other changes