Thank you and you've given me a boost too. My biggest problem is that I develop for a living, so it's pretty difficult sometimes to sit down in the evening and do more of the same. I'm going to have to give it some 'daytime' time in order to move things along.
Oh God, yes, I started to get random corruption happening at the point my sprite data grew downwards and my program grew upwards and the two met. Trying to find the right place for everything so that you have room for your sprite data is horrible. I have custom characters too. I still feel that what I've done is messy but it works.
The short term solution for memory organisation is to use the upper half of bank 0 ($2000 to $3fff) for graphics and assemble the code at $4000 onwards to avoid conflicts; that gives a character set and 96 sprite definitions on it's own, a little limiting but I've done at least one game using less before now.
One of the advantages of cross development is that we can pretty much store data and build code anywhere in the C64's memory and, if it's outside $0801 to $cfff, cross compress it before testing; one of my CSDb ICC releases last year ran from $03c0 to $07ff (so didn't use a single byte of "regular" memory) and was decompressed there by Exomizer.
Last Edit: Sept 28, 2019 11:11:18 GMT by TMR: Reworded something trivial...
I have decided that I'll push myself out of my comfort zone and see if I can master raster timings. Not something I have ever touched before.
I have seen demo's where the sprites have been effectively doubled in number by changing their position mid scan (at least I believe this is what they do).
You can change a sprite X position, colour or data pointer whilst the VIC-II is rendering but not the vertical position, any writes to that register are ignored until the current iteration has finished. If the Y register is set to a new position directly below the current one by an interrupt kicking in halfway down the sprite, that first iteration is finished and the next one begins on the scanline directly below it.
The simplest sprite mutliplexers work in "zones" with fixed-position raster splits recycling sprites in clumps; for example a raster split at the top of the screen sets up seven sprites that can only occupy the upper half of the play area and another split halfway down the screen moves everything for the lower half, giving two zones of 7 sprites (14 in total) and, in this case, one extra sprite which can move freely. This a simplified version of what Delta is doing, the player craft is the free-roaming sprite and the other seven generate both landscapes and the enemies.
More complex multiplexers sort the objects by Y position, then assign sprites 0 to 7 to the ones with the lowest values; once sprite 0 is done an interrupt kicks in to move it to the ninth value on the sorted table, sprite 1 goes to the tenth position and so on. Games like Armalyte or the Turrican series are doing things this way and there are plenty of demos as well, although it's more common to pre-sort the positions in the latter case for speed so the high sprite counts in those cases aren't necessarily realistic for games.
Forgive me Father for I have sinned. It has been three decades since I last programmed on the C64.
Not sure what has me rejuvenated, but I thought I'd give it a good shot again. Maybe it is the upcoming release of 'The C64', hoping it will inspire a new breed of games for the beloved beast. ... No doubt there will be heaps of questions along the way. Thankfully, there is a ton of information available now compared to what we had growing up. Along with other like minded kids who are now stuck in middle aged peoples bodies.
Wish me luck!
Hey, I resemble that remark!
Seriously though, I think you're right about the new "TheC64" getting new people into it - I'm one of them! It's one thing when geeks like me fire up an emulator and play their old favorites; it's a whole different ball game when a company is re-creating the system and everyone is going nuts over it! Funny thing is, I didn't have any Commodore computers growing up - I was a Nintendo nut (lol). I discovered the C64 and VIC-20 kind of by accident: I started learning to code for them (with the goal of eventually taking my new-found knowledge and learning to code for the NES), but along the way I actually became a huge fan! So I have zero nostalgia for this platform, but I totally love it! I'm sure I'm not the first, and sure I won't be the last, to fall in love with the good old C64 without having grown up with it.
But anyway, nice work on that sprite! Graphics aren't really my thing either (I'm good with ASCII/PETSCII art though ). And I'm in the same boat (sure to be heaps of questions) but I think we've come to the right place! So yeah, good luck!
Post by The Geek on Skates on Oct 6, 2019 21:42:46 GMT
You got that right! I just got one of my questions answered on here, about playing sound on the C64. There are definitely some talented coders on this forum. I still have much to learn about the C64, but getting there is half the fun.
btw, that ninja looks awesome! Keep up the good work!
Robin at 8-bit Show and Tell has just done a fantastic video about the system interrupt and raster interrupts. He explains things so well.
I don't think I've ever used the interrupt before. I've certainly avoided it recently since I've come back to 6502. But he makes it way less scary than it was in my head. What I didn't appreciate was that the system interrupt happens at 60hz on both PAL and NSTC machines. I'm about to try using that for my music driver because I think it should make that more 'stable' and should also means that my music will play at the same speed on both systems.