Spectrum Computing

Much better!

Perhaps you can use the more detailed teddy bear, but swapping its position with the closest rocket girl (so it will be on her left side)?

Ivanzx wrote: ↑Mon Aug 26, 2019 8:58 pm Will the game have ingame 128K music?

No idea. My intention is to write a 48K game, but some people seem so insistent on background chiptunes that they overly criticise games that don't have it. But that would mean having someone else write a piece for me that I'm not even sure I really want in the game.

I'm adding clips of beeper tunes between levels, so I don't think then playing a chiptune afterwards would really sound right.

Einar Saukas wrote: ↑Mon Aug 26, 2019 9:33 pm Perhaps you can use the more detailed teddy bear, but swapping its position with the closest rocket girl (so it will be on her left side)?

Not really enough room, as it spills over a few pixels into a much wider area of magenta attribute squares. If I move the title over and push the other rocket across and up a square I can fit it in.

Is the bigger one better then?
It looks a bit too cluttered to me, with the title off-centre now as well.

Ah, wait, the title can come back a little closer to centre, putting the smaller rocket back where it was:

Where can I download this game from? The download on here only has the Firing Demo TAP:

https://spectrumcomputing.co.uk/index.p ... 6&id=34612

stupidget wrote: ↑Tue Aug 27, 2019 9:34 am Where can I download this game from? The download on here only has the Firing Demo TAP:

https://spectrumcomputing.co.uk/index.p ... 6&id=34612

That's because that demo is the latest public release. The game hasn't been finished yet.

PROSM wrote: ↑Tue Aug 27, 2019 9:39 am

stupidget wrote: ↑Tue Aug 27, 2019 9:34 am Where can I download this game from? The download on here only has the Firing Demo TAP:

https://spectrumcomputing.co.uk/index.p ... 6&id=34612

That's because that demo is the latest public release. The game hasn't been finished yet.

That'll explain that then, cheers

OK, opinions. Big thing or little thing, which looks better?
Is having it bigger and more detailed any better, and is it worth crowding out the title to get it all in?
I'm certainly not redrawing the title to a different size!

To me the smaller one looks a bit better here.

I think smaller is better. Bit too crowded with the large bear.

Smaller is better in my opinion too.

OK then, what do we think?

This turned out beautiful! Really like the fluffy clouds, the grass and hill looks great.

Just stuck it on ZXArt, for all the Russians to downvote...

https://zxart.ee/eng/authors/j/joefish/ ... title-v26/

I left off doing the clouds for a long time, but in the end it was pretty easy.
I just had to remember I was trying to copy the art style, not trying to draw real life. Try not to over-detail it, and just keep the lumps moderately different shapes and sizes.

It is getting better, for sure!

About the music ingame, I asked you because in your previous games you preferred also 48K music, which is also nice, and having some48k melodies inbetween the scenes or screens gives it a special speccy touch somehow!

128K music would be a problem actually. It uses POP/PUSH screen copying so it can't do a regular interrupt every frame. It uses a HALT for synchronising, but that can drop the occasional frame and it has no way to keep count, so the music would be all over the place!

Would my suggestion from the other thread work in your case? Keep interrupts running during the screen copy, then fix up any stack corruption in the interrupt routine?

You could, but it (a) slows things down and (b) I don't really need it!

I'd need to add interrupts to handle sound on a 128K machine, but then I could use screen paging, not stack copying, to update the display. And I wouldn't be worrying so much about how many sprite animations I can fit in!

Joefish wrote: ↑Tue Sep 10, 2019 12:15 pm 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?

How close to completion is the game?

Ivanzx wrote: ↑Wed Sep 11, 2019 9:11 am How close to completion is the game?

Good question. No idea! Difficult to find time to work on it right now.

zxade wrote: ↑Wed Sep 11, 2019 9:01 amI'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.

Finally done the last background graphic (bottom):



The top two can be dynamically re-coloured and re-used in other levels.

See commentary here on development of the last one:
viewtopic.php?f=9&t=3073