- C64 sprite master full#
- C64 sprite master code#
VSYNC=$010, and simply NOP’ing until I get to the exact VSYNC/HSYNC that I want. I tend to do this by starting at an early raster position, eg. With all of the above, I consider what the end goal is as well – a single function that’s called with a stable raster, at a certain raster position, and that will do all the work without any variable timing – we need to know exactly how many cycles each instruction takes – so we should avoid branching, any indexed loads that might cross page boundaries, etc etc. So, yeah, it’s a lot to get through… but you can do this in baby-steps with a plan like this – keeping an eye on memory as best as you can as you work through it. Adding sinus and scrolltext movement, along with the 2nd frame of animation.
C64 sprite master code#
Interleaving the blit-code into the above raster code.
Generate some test sprite data – a single frame of prebaked DYPP sprite data to make sure that the sprite multiplexing is implemented correctly. Baking out pre-calculated DYPP font data. C64 sprite master full#
Full sprite multiplexing working – updating sprite X values and sprite indices as appropriate. Simple sprite multiplexing working – updating sprite Y values as appropriate to match our sprite sinus. Side borders to be opened for the whole screen ($d016 to be changed at the appropriate HSYNC positions for every raster line). Top and bottom borders to be opened (somewhere around VSYNC=$0f8 and $0ff we will need to change $d011). With this part, there are several things that will be required:. One thing that I find helps a lot when building complex demo parts is to plan out exactly what is needed to make it happen. This can of course be a hurdle on C64 – but that’s half the fun, right? It’s not just about unrolling code and precalculating everything – it’s the balance of doing that while also sticking within the very tight memory constraints. The sinus moves in the opposite direction and at a faster speed so that it nicely rolls across the screen (if the speeds were matched, you would simply see the scroller moving through a static sinus – which would look pretty awful).īelow you can see how we’ve squeezed everything into memory – like many of my demo effects, almost every byte of the C64 is utilised. That’s too fast for small fonts – but with a 16px font, it’s totally fine. We blit whole bytes – so it gives us a scroller speed of 4px per frame. Following these 2 frames, the blit data will advance. The effect uses 2 frames of “animation” (more would be nice – but, for me at least, memory constraints prevented this). Note also that 432px can be covered horizontally with exactly 18 sprite columns. 
Although only 408px can be shown on screen at a time, we need 24px more so that we can smooth-scroll the sprites. The simple reason for doing this: the DYPP appears larger and we use half the number of blits that would otherwise be needed to draw the scroller.
One trick that I used – which is why you might notice the DYPP doesn’t quite look 100% clean – is to use double-height sprites. With 2 DYPPs, then, we have 8 sprites at top and bottom, 4 for the middle section. At the top and bottom of the DYPP, we’re using 4 sprites (red, cyan, purple and green) and within the rasterbar section we’re only using 2. The image below shows in simple terms what is used for one of the DYPPs in a single frame.
interleave sprite data (check Codebase64 here if you’re unsure). open the borders (top, bottom and sides). You probably need to know at least the very basics of C64 demo coding, such as how to:.
0 kommentar(er)
