Big tilemap vertical scroll with CPCTelera

Started by amkam, 17:44, 14 March 23

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


Hi everyone! I'm quite new into CPC programming (just did BASIC stuff when I was a kid) and recently, to scratch an itch, I started drafting this diagonally scrolling game concept based on CPCtelera's tilemap hardware scroll example. Targeting the raw 464 hardware and the tilemap is "big": 120x120 tiles.

The pristine CPCtelera's example scrolls horizontally and I made it also scroll vertically by the usual trick of adding 40 bytes to the video memory offset. That works until the video offset overflows and starts at a misaligned position (offset + 40 > 0xFF). I was thinking on ways to overcome or solve this issue without resorting to software scrolling (double buffering), and losing either lots precious FPS or memory space.

So before running into more dead ends because of not knowing for better solutions and deeper knowledge of CPC hard, I'm asking if someone has overcome this limitation somehow, and has a shareable example of the solution. Or any other idea on how to tackle this problem (even changing the perspective as a whole). Not looking for cpctelera based solutions only, although those would be ideal.


PD: I was thinking on perhaps using the video page offset too to allow fitting the whole tilemap, but got into unknown crashes before being able to figure out the math adjustments.


The trick is to draw into the now off-screen part of the video memory before scrolling it into view. There is almost always not nearly enough video memory to hold the entire level as a screen (and the way the display addresses wrap essentially precludes it anyway) so you're always going to be generating the display partially on the fly 


Quote from: andycadley on 20:50, 14 March 23The trick is to draw into the now off-screen part of the video memory before scrolling it into view.
Apologies for updating an old post but, I'm curious how one can draw off-screen without potentially the off-screen start address not being already on the screen somewhere. Let me give you an example - If we assume the screen starts at C000, I know that scrolling by one character line down will give the new screen start address of C7B0. Now if I plot to that start address before scrolling down, I've noticed that address is already within the visible screen memory map. If I poke &C7B0,255 without scrolling the pixel(s) are plotted somewhere at the bottom of the screen making them already visible to the user. I've been messing about with the hardware scrolling using CALL &BC05 for a number of weeks and haven't really sussed out anything. Admittedly, I am also using the SP to blit the row data for speed which is probably not helping. I think the best I managed to get working was using the CALL &BC4D but, that is quite slow compared to off-setting the screen manually.


The address of the first byte of the next character row on a standard sized screen is &C7D0 - which is off screen by default. However you're still partly correct, as address &C000 will form part of that line too and that is obviously on screen by default.

So how to do it? Well it's only a problem because of the default screen size. Reduce the height by 1 character row for example and you clearly will end up with at least one character row of "off-screen" video memory before it starts wrapping addresses. And now you can easily draw to that section before scrolling it onto the screen. Obviously you can play around with different width/height combinations depending on what suits your game best.

Powered by SMFPacks Menu Editor Mod