sack-c0s

good idea - I know I keep banging on about 'throwing CPU power and memory at colour is all well and good but *you need to leave resources for the game logic*' but in this case you have a relatively small playfield of a couple of screens where you could probably just fix up a pointer to the right part, sidestepping a lot of the work the C64 has to do. That means you should have a good chunk of runtime to actually throw at solving colour problems once you get the ball physics out of the way.

yep - the interal apps are basically an SYS call (SYS 1525 iirc) bound to a function key.

That's not really any fun on a relatively powerful 68K with custom hardware to back it up - I'd probably prioritise Stuntcar racer if you want a racing game, or something running in freescape where the gameplay is slower paced.

Robocop 3 intro tune - there's even a NES version of that which sounds good (and the NES rarely sounds good if you try to make it do SID stuff), so anything is possible

D'oh - i fell into the trap of changing country and getting a new project. I might start now for 2016 and maybe get a bloody game done. I think what I had in mind would be achievable under normal circumstances

a RMT network hack, which uses the PC editor but can keep an Atari in sync as a player would be pretty cool. Should solve the editor comfort problem and the playback accuracy

I suppose it's up to the individual author of the demo song. If it's one of mine then I really don't mind whatsoever. I can't imagine what else you expect is going to happen if you agree to one of your music files being packaged up with an editor to be pulled apart and messed with if I'm honest - it's fair game.

personally I'd stick an actual C64 in there so you can make your own mind up which machine $SOME_GAME is better on and just play it on the C64/Atari as appropriate. Not sure about recasing my Atari, mind, that 800XL seems pretty sturdy and solid as it is and doesn't really need messing with.

Illegal instructions? I'm sure a linear frame buffer, reasonable double-buffering and a faster CPU will get you most of the way there. It's plenty of fun at the C64 speed so it's not going to be 'all for nothing'

would end up being a cartridge job i reckon...

I vote emkay to do it

I agree with the cell locking - the logic revolves around everything acting in a particular way with cell-based movement, and being able to think ahead and predict the rules of that movement forms an import part of the game. I think once you start adding smooth player movement it feels like it breaks that If I were making a modern version I'd possibly compromise by having a kind of 'quick dash' movement into the next cell, so you have a little more animation and it's not a sraight jump but it does respect the cell-based constraint of the game.

I think what attracts younger people is the same thing that keeps me interested - it's that we can argue forever (and probably will) that one machine is better or worse than the other in some way, but there are actual differences there that give them character. PCs and macs - well some might benchmark higher than others but they're fundamentally the same.

It is incredibly easy - I tried a physical cartridge in a real NES and it's just like that. Although they do say the hardest version is the C64 conversion, which may have skewed my impression of how the game should be.

Should be able to match the NES version at least in terms of graphics. It plays pretty badly though, so we might want to at least aim higher in that respect

To be fair I think the BBC wiped the floor with the Atari and Commodore so far as loading speeds were concerned. Although to be fair the C64 and Atari 8-bit had stuff that was actually worth the wait, so it worked out nice in the end....

Technically I'm one of those 'C64 troublemakers' having grown up with a c64 and then broadened out when things were cheap on ebay, but if I were to class myself as anything it would be '6502 fan' even then that's a pretty loose rule as I'm partial to a bit of z80, 68K and ARM

It's not exactly easier - just s different skillset. A lot of demo coding works because you have precise control over what is shown, when and how and you can exploit that. In a game you just can't restrict people enough to make everything work, otherwise the player would be on rails. That isn't to say that there aren't a lot of transferable skills though - The more you can optimise and creatively cut corners the more you can throw into the game, but they do have to be more general purpose than a demo.

Good old misdirection also works, although not technically optimisation you can just draw attention away from the real framerate. For example, Imagine a spinning cube bouncing around the screen. You have translation (the movement around the screen) and rotation (the actual spinning). If you were to do the movement by moving the screen scrolling or the sprites that the cube is rendered to in the vsync interrupt then that happens at 50/60fps. The main loop will just be redrawing the spinning as fast as it can, which may be every 2-3 frames, but the eye will be tricked by the smooth movement and it'll appear faster than it actually is. Framerate isn't as important as consistency - people are far more adept at noticing a changing framerate. if you keep bouncing around between 40-50fps just lock it at 30 and it'll seem far smoother and buy you some more time.

I think part of the reason I favour old games over new ones some of the time is *exactly this* - it's pretty much the norm these days to get to the end of the really nice walkcycle someone has spent days modelling...

Give up, read the description and just code what you think the game does? I learned to code that way In fact there could be a fun little competition in that....

The general rule I follow is this: *The code does what it does *The comments tell you what you *wanted* the code to do. Those two things aren't always the same so: LDX something DEX STX something looks okay doesn't it? ; Increment the counter LDX something DEX STX something sets alarm bells ringing. Even if the code is theoretically obvious to another programmer it provides a layer of security and I've found and fixed plenty of bugs looking at things that way. I'm not sure how I'd have handled oldschool, back-in-the-day games porting. It's 'interesting' work when you have the source code....

I figured if I was fast enough it'd possibly get some mainstream attention too (and in one case it did, but that was a poor port of the game) - but life came along and dumped a stack of work on me (which, ironically, is games porting) maybe when this project is done (which should be soon) I can sort out my personal 'to do' list, which currently needs a second house to hold it.

Sounds good but one quick question: Where does this leave us in terms of run time to do everything else? Does it just update the music player same as always, need multiple updates per frame, need handholding throughout the entire frame, etc.?

Slightly biased here, but if it goes back together you might be better just putting it back together, getting it to someone who wants Commodore stuff and spending the cash on something Atari you actually want