New game: VIC-Splatform, now with MUSIC!

[carlsson]

Maybe you can move onto multi-colour mode and use four pixels wide graphics?

PS: In my book, optimizing for size (or speed) while not breaking functionality, is always an improvement.

[MacbthPSW]

Maybe you can move onto multi-colour mode and use four pixels wide graphics?

I did think of that, but in addition to the guy looking worse (less round, anyway), the scrolling would have to move two pixels at a time, looking a lot worse at slow speeds.

PS: In my book, optimizing for size (or speed) while not breaking functionality, is always an improvement.

Good point.

[carlsson]

Frankly, the slowest scrolling speed appears fast enough for me to not determine if you were scrolling one or two pixels at a time.

By the way, I observed that you copy the whole 4K character set into RAM so it is available with custom characters? You spoke about whether it is possible to make Splatform for +3K or even unexpanded VIC. You probably are aware that with custom characters at $1C00, you can access the first half of the standard character set (i.e. letters and numbers) with reverse graphics, at least in an "unexpanded" configuration. I don't know if this relevation would save some space and make it more likely to fit into 3.5K alltogether.

The magic scrolling appears to be based upon whichever graphic shapes are stored at $1BF0 and onwards. I suppose you could store those graphics as custom graphics without the need to have the whole character set represented?

[MacbthPSW]

Frankly, the slowest scrolling speed appears fast enough for me to not determine if you were scrolling one or two pixels at a time.

I think you'd notice it. I'm using fractional horizontal scrolling speeds, and losing out on half of the resolution would cause a noticeable jitter.

This is something I've argued about with the A8 guys. They can only scroll in whole pixel increments, so in their 4 colour mode (160 pixel resolution) they have only half the scrolling resolution of the C64 in it's equivalent mode (160 "pixels", but still 320 pixel scrolling resolution).

To see it at work, boot up Last V8 on both the C64 and A8, and drive at slow speeds. It makes a really big difference, imo.

By the way, I observed that you copy the whole 4K character set into RAM so it is available with custom characters?

Hmm, I thought I only copied 1k?

You spoke about whether it is possible to make Splatform for +3K or even unexpanded VIC. You probably are aware that with custom characters at $1C00, you can access the first half of the standard character set (i.e. letters and numbers) with reverse graphics, at least in an "unexpanded" configuration. I don't know if this relevation would save some space and make it more likely to fit into 3.5K alltogether.

Yes, I kind of accidentally discovered this. However, some of my optimizations to speed up the screen "render" require characters numbers >= 128 as they use the high bit as a signal that a platform is ending (or starting, already can't remember).

The main thing causing the RAM shortage is that I pre-render the level to memory (256 characters long, by 20 tall = 5120 bytes).

One way around this is to use an algorithm like Thomas devised for his 2600 port to generate the platforms on the fly, but frankly, I find his level layouts to be *too* random, with not a hint of design. I've grown attached to the particular levels as they stand; each one has at least one recognizable bit I really like.

So the other idea is to generate and compress these same levels, and then decompress just the screen's worth during rendering. I was planning on doing this until I saw how much raster time I was eating with the current screen draw; the extra work simulating the scrolling took a lot more raster time than I expected.

So, it might be do-able if I struggled over it like I did over the original 2k Minima, but with that extra time I'd rather work on Splatform 2 (C64) which I've already started on

The magic scrolling appears to be based upon whichever graphic shapes are stored at $1BF0 and onwards. I suppose you could store those graphics as custom graphics without the need to have the whole character set represented?

Yes, that's definitely do-able.

I only spent as much time optimizing as I really needed to, and it was mostly speed optimizing rather than memory usage. After the pain involved with some of my minigames, it's kind of nice to just let it go and bloat up to 8k or whatever

Thanks for the comments!

[carlsson]

My fault, it is only 1K. I was thinking four pages of 256 bytes = 4K. It was many years ago I took classes in elementary math.

I didn't see the pre-rendered levels coming. That explains why you need a good bit of RAM.

[eslapion]

TO MacbthPSW:
Hey this game seems really nice!

Do you think you could make a cart version so we could include it in the multicart ?

I know very little of programming but it sounds feasible... does it ?

[carlsson]

Is it feasible to use the level generating algorithm a little at a time, so you render e.g. 24x20 = 480 bytes at a time? That is assuming the screen width is 22 columns and you want at least one column in each direction outside the visible area. Would it be just as bad as depacking an already generated level? From what I understand, you need to use either approach to make the game runnable either in unexpanded or cartridge form (unless it is a RAM cartridge :-).

[carlsson]

I disassembled [..] TinySID [..] 256 bytes.

Ah, now I've managed to assemble it back again! It sounds simpler than it is. Steve uses a lot of zero page in his music routine, it appears like the setup routine transfers all music data into zero page upon startup?

I'll try to understand which part does what and replace the SID references to VIC references. Since the music chip is simpler, the routine should become even shorter...

[MacbthPSW]

I didn't see the pre-rendered levels coming. That explains why you need a good bit of RAM.

Yeah. Thomas was really disappointed when I sent him my source code back when and he saw how many easy short-cuts I took Amazing that he managed to do the game in 1k of ROM and 128 bytes of RAM. IMO, he's the best 65xx coder around.

Do you think you could make a cart version so we could include it in the multicart ?

I know very little of programming but it sounds feasible... does it ?

A cart version would be really cool, but because my RAM usage is so high in this game (around 6k not including zp or screen memory) it isn't currently possible. See my comments above about why I probably won't go to all the effort to try using less RAM. Though carlsson's comments/suggestions still have me thinking about it

Is it feasible to use the level generating algorithm a little at a time, so you render e.g. 24x20 = 480 bytes at a time? That is assuming the screen width is 22 columns and you want at least one column in each direction outside the visible area. Would it be just as bad as depacking an already generated level?

Because of how the level generating algorithm works (really, just alternating random lengths of blank chars and then platforms wrapping around each row, so any given platform's position is dependant on all those that came before it) it would surely be slower than the compressed format I had envisioned which would be row-based.

Hmmm, your suggestion makes me think that maybe compressing a screen worth at a time would be a solution. I'd need to have 2 screen's worth out of 12 uncompressed at any given time. Well, I'll think about it more.

Ah, now I've managed to assemble it back again! It sounds simpler than it is. Steve uses a lot of zero page in his music routine, it appears like the setup routine transfers all music data into zero page upon startup?

I'll try to understand which part does what and replace the SID references to VIC references. Since the music chip is simpler, the routine should become even shorter...

Cool, that'd be great if you get it going...

[carlsson]

By the way, yesterday evening I happened to be listening to the Splatform soundtrack non-stop for three hours! After listening to it for one hour, I didn't realize I was listening to it anymore. I took off my headphones and went to the toilet. When I came back to the computer, I thought I heard voices, someone singing. I slowly picked up the headphones to verify that it was the Splatform tune still playing!

[carlsson]

First attempt of converting the music, didn't work so well:

http://www.anders.sfks.se/mp3/splatform ... ttempt.mp3

Back to the drawing board...

Edit: One LDY later...

http://www.anders.sfks.se/mp3/splatform ... ttempt.mp3

It is far from good, but at least part of the tune can be recognized. I don't know why it got stuck after a while.

[carlsson]

Ok. I don't quite understand how Steve's music routine works, but it works! You wrote that Thomas is an awesome 6502 coder, but I must say that Steve appears to have quite a few tricks up his sleeve as well. (But then again, don't we all?)

http://www.cbm.sfks.se/files/splatform- ... ersion.a65 (source)
http://www.cbm.sfks.se/files/splatform- ... ersion.prg (exe, 213 bytes)

The routine is based on the one he submitted to TinySID compo. I don't know how the routine originally used in Splatform 64 differed, but maybe it used less of zeropage?

I assembled it to $1C00 (7168) but of course it is fully relocatable. I inserted some busy loop instead of an IRQ handler, but Robin will be able to work from there.

The music values were chosen from VICE emulation, in PAL mode. You might want to tweak those, but the original music is quite detuned, so maybe it doesn't matter...

By the way, if you ever would consider making a Plus/4 version of Splatform, this routine would be rather simple to adopt as well, since it only uses two voices at a time (and one of the voices on the TED chip is switchable between square wave and noise).

Good luck!

[Jeff-20]

...I took off my headphones and went to the toilet. When I came back to the computer, I thought I heard voices...

"Anders, flush the damn toilet!"

[MacbthPSW]

Anders: very cool, I'll try to integrate it soon and let you know how I do.

[MacbthPSW]

The routine is based on the one he submitted to TinySID compo. I don't know how the routine originally used in Splatform 64 differed, but maybe it used less of zeropage?

Yes, this one was quite a bit less friendly to use due to the much larger zero page usage. It took me three seperate sessions (not particularly long, but very trying) to get it completely working

It shouldn't have taken me so long, but I was slow to pick up on Steve's BIT trick, using opcode $2c to skip over two bytes worth of code. When I tried to move all the zp stuff to non-zp, of course that trick couldn't work anymore, because the following instruction was 3 bytes long now!

Anyway, thanks for the effort Anders, I think it sounds really good.

I also updated the title screen to properly reflect the credits, and also made the status info between levels and lives somewhat less cryptic.

If nobody finds any bugs, then this'll be the final release.

Download it here: http://psw.ca/prg/vicsplat-beta.prg