"Go-Go BunnyGun", first screen grabs.

Show us what you're working on, (preferably with screenshots).
zxade
Berk
Posts: 10
Joined: Tue Feb 19, 2019 12:14 pm

Re: "Go-Go BunnyGun", first screen grabs.

Post by zxade » Wed Sep 11, 2019 8:01 am

Joefish wrote:
Tue Sep 10, 2019 11:15 am
but then I could use screen paging, not stack copying, to update the display.
I've not used screen paging on the 128K before, and wonder if I've been missing a trick. How does it work in practice? Does it make it more tricky in terms of structuring the code? Do you lose the use of addresses from $C000 for other purposes? or is there no downside other than making the code 128k only?
0 x

User avatar
Ivanzx
Site Admin
Posts: 186
Joined: Tue Nov 14, 2017 9:51 am

Re: "Go-Go BunnyGun", first screen grabs.

Post by Ivanzx » Wed Sep 11, 2019 8:11 am

How close to completion is the game?
0 x

Joefish
Manic Miner
Posts: 586
Joined: Tue Nov 14, 2017 10:26 am

Re: "Go-Go BunnyGun", first screen grabs.

Post by Joefish » Wed Sep 11, 2019 8:24 am

Ivanzx wrote:
Wed Sep 11, 2019 8:11 am
How close to completion is the game?
Good question. No idea! Difficult to find time to work on it right now.
0 x

Joefish
Manic Miner
Posts: 586
Joined: Tue Nov 14, 2017 10:26 am

Re: "Go-Go BunnyGun", first screen grabs.

Post by Joefish » Wed Sep 11, 2019 11:21 am

zxade wrote:
Wed Sep 11, 2019 8:01 am
I've not used screen paging on the 128K before, and wonder if I've been missing a trick. How does it work in practice? Does it make it more tricky in terms of structuring the code? Do you lose the use of addresses from $C000 for other purposes? or is there no downside other than making the code 128k only?
I've tried coding a scrolling demo with it. And the 50Hurts 50fps scrolling uses it too. It saves you a whole frame or more per game loop if you're using a back-screen and trying to avoid flicker.

The big drawback is you have to page the screen you're drawing on into the top of RAM (or write to the regular screen at $8000 and the back screen at $C000). This means you have slow RAM at the top of memory, so it's not good for storing graphics data or anything you need to access fast. Which means your game code and all the data it needs for the current stage pretty much has to fit in the middle 16K from $A000 to $BFFF.

Which means even if you're not swapping chunks of code around, you're going to need a dynamic data-management system so you can copy stuff like sprite data into the middle 16K - and that actually limits how much you can have going on in any one level, compared to a 48K game. You could at least stick any music and sound and data used during the interrupt/top-border functions in the slow RAM from $5B00 to $7FFF.

It's still sort-of 48K compatible, as on a 48K you could have your back screen at $C000 and just spend more time copying it down to $8000 instead of paging it. But you'll need a full-on strategy of managing or limiting other data to keep your game 48K compatible, and it'll run slower.

As I see it, the only reason for making a 48K game is to see what you can do with the limited system, in which case I'm not interested in 128K enhancements. On the other hand, if you are going to add 128K features, you might as well just forget about 48K compatibility and make a 128K game. Someone asking 'why isn't there any 128K music' is about as relevant to me as someone asking 'why didn't you write it for an iPhone'.

The only other trick you could use is to copy data from a fast RAM bank into a screen RAM bank by using an OUT to swap the banks over between reads/writes. But this is only efficient really if you're caching the copied bytes in lots of registers, e.g. a PUSH/POP copy, and then only really if you're copying a chunk of screen between the same addresses in both banks.
0 x

Post Reply