sack-c0s

I wrote a goatTracker editor file data extractor whilst I was trying to write a BBC music driver, but I don't know where it is these days. If I find it I'll throw it out there and someone could maybe look at re-encoding the data for RMT or some other editor

I want to like the ST, but I just can't quite bring myself to do it. It's like you want the bigger machine to be better than the original, but in many ways the A8 is more flexible. The Amiga feels like a nice step up though

I think it could be done - but you'd lose the more subtle colour usage. I think the Atari wins this round. Regardless of the technical stuff it also looks like there's a nice, solid playable game built around it too - which is the most important thing in the end. Looking forward to having that on my SIO2SD. (Oh - and ignore the multiple edits - they're all spelling and stuff because I'm full of cold and typing in a Lemsip-fuelled haze today...)

I'm just gutted that my BBC time was spent on Grannys Garden and Frogger instead of this. Looks like fun

Great C64 screenshot - when's the Atari version out seriously though - that's some mighty fine use of colour. It looks like you got the C64s freedom of colour placement with the subtleties of the Atari palette and it works out really nicely. Like the music too

To be honest I'd not bothered downloading this because I've got a text editor/assembler/emulator setup I can carry between mac and PC so I really didn't think I needed it. Then about a week ago my curiosity got the better of me, seeing as I'd had to install eclipse for something else anyway. In terms of ease of use and speed of iterating through attempts at coding things it's been like night and day - everything feels way more comfortable and quicker now. I really should've switched earlier...

I picked up the A8 again last week after getting around to finally getting an SIO2SD, and forgot about this to be honest. I might get lucky and get a small contribution together but no breath holding - there's a queue of other people who'd like me to finish other games first (one of which is paying my wages...)

anyone else tempted to just *write the bloody thing* for a laugh?

and there's people who code in c++ all day at work you can always ask in the usual places...

The megadrive has planar tile definitions, so you would only need to store data for the used planes, which would save you some cartridge memory at least.

people say this to me, then shortly afterwards ask me how i crafted a neat little optimised solution to some code problem on the Mac. I just reply asking 'and how exactly do you think I learned to do that?'

also another comparison to the CPC - seeing as it shared a CPU with the ZX Spectrum and you could get a similar screen mode out of it there were plenty of rushed ports that made no use of the extended abilities there either. Although in a lot of cases the Z80 just wasn't up to it until a few screen shift tricks were discovered later on

the ST acts more like an upgraded Amstrad CPC to be honest

This comment means nothing to me...

Maybe I should just switch tracks a little, play with the parallax a bit more and go for the theme of an empty, dull game with lots of graphics and do 'Shadow of the bird'

D'oh - looks like I can throw the C64 code back in the bitbucket and finish up the A8 version then.

really? my copy shows a top score of 65535, and the hex editor shows way more digits available I'm reading the bitching about the original and other suggestions between builds, so I'm taking it on board. I might add a few other little things if I can to perk the game up a bit if possible

I thought it'd be nice to prove that you could do it on a 1/1.7mhz machine in very little time and *actually not bugger up the collision detection* It's pretty much a nice to have throwaway game that someone was going to do sooner or later sdo I figured I'd give it a try...

Reading the manual was part of the pre-Amazon experience. It was something you did on the bus home with the fresh copy of the game in your hands in anticipation of playing it. I always did that - mentally I was already playing the game

the gameboy has a 32x32 tilebuffer that automatically wraps around (so you don't need to move the tiles - you just keep redrawing them on the left of the buffer to carry on scrolling right). Nice thing is you can set the X and Y positions on a per-line basis to do some cool distortion effects. If someone hacked up an emulator you could potentially trap all the columns being drawn to the tile memory to build a bitmap of the scrolling map

I seem to remember there being some pretty good emulators with the ability to view the graphics memory to get tilesets and the like, but I can't remember which one I used for debugging now. In fact I can't even remember much about coding for the gameboy at all. I had an idea for how to extract maps in an emulator by logging writes to video memory, but I've not gotten around to hacking about an emulator to do that.

I think the lack of response might also be down to the time of year. I like the idea, but I've literally only just seen this thread.

I was a C64 user back in the day, but eBay and the internet gave me the opportunity to broaden my horizons and see how everyone else spent their 80s. For me in all honesty the difference would be that My Atari would've been the one I got in the mid-80s and the C64 would have been later

D'oh - that's what I get for trying to cycle count whilst up to my neck in Python script.... At least you save a ZP address that way if needs be.

wouldn't this be slightly faster and save a byte (assuming running from RAM)?: pha stx xRestore+1 . ; Rest of code here as before . xRestore: ldx #$A2 ; the A2 operand is overwritten by the initial STX, so it doesn't matter what the value is. pla ; A2 was chosen to match the preceeding opcode, so it might give a packer something to work with.