CPCTelera : Scrolling Hardware

[Arnaud]

Hi,
i'm trying to code horizontal scrolling hardware, i've read plenty doc and examples, but it's still not clear for me.

Here my problem, there's graphic glitch when scrolling with an offset of 25 (see image).
I guess it's about memory alignment but i don't see how correct it.

Here extract of the code :

Code Select Expand


u8 offset = 0;
u8 gColumn[2*200];

... Read Key, Loop, etc ...

u8* vmem = cpct_getScreenPtr(CPCT_VMEM_START, offset*2, 0);
cpct_getScreenToSprite(vmem, gColumn, 2, 200);

cpct_setVideoMemoryOffset(++offset);

vmem = cpct_getScreenPtr(CPCT_VMEM_START, 78 + offset*2, 0);
cpct_drawSprite(gColumn, vmem, 2, 200);


Thanks,
Arnaud

[Xifos]

Mmmm...
I don't know cpctelera but...

The problem may be in cpct_drawsprite, or cpct_getscreentosprite.
Could you try to put the same column to refresh the scrolling, without doing the cpct_getscreentosprite, to be sure ?
And you would need the cpct_drawsprite source to check the next_line computation (to use on a hardware scrolled screen).
Does cpctelera allow 32 char wide screen ? Hardware scrolling is easier on a 32 char screen...

[Arnaud]

Thanks @Xifos.

Finally it works, the harder was to understand the problem.

Here my explanation (if it could help someone) :

By default, the last adress of the displayable video memory is 0xFFD0 (see cpct_drawSprite doc)
When 1-Bytes video memory offset is applied, the displayed video have to apply an offset of 2-Bytes to keep the first pixels in the left-top.

With an offset of 25-Bytes, the displayed video has an offset of 50-Bytes then
0xFFD0 + 0x32 = 0x0002 -> the last pixels displayed are outside the video memory (0xC000-> 0xFFFF).

In this case, we have manually to set the video to display at 0xC002

That all  Here my working example.

Now i can return to make Asic hardware scroll by pixel 

[Arnaud]

Hi,
now i'm trying to do an infinite scrolling.

I was thinking (naively) once all my screen was scrolled (with offset of 40),
i have to reset the offset to 0 and the scrolling would be ready for another turn.

But of course not the video memory Bytes were modified by copying the columns at each offset increment.

How handle this case ?

[Xifos]

For infinite hardware scrolling you have to accept that the video ram will be a mess after scrolling it !

Exemple, on a 32 char wide screen :
after an offset of 32, the screen memory is the same as offset 0 except that it is shifted one char line up.
And after an offset of 64, it is scrolled two char lines up, and so on...
So it comes back after an offset of 1024 (if i am correct).
On a 40 char wide screen, it is the same except that even if an offset of 40 will scroll the screen vertically up, the ram will not be aligned at the bottom...

[Arnaud]

On a 40 char wide screen, it is the same except that even if an offset of 40 will scroll the screen vertically up, the ram will not be aligned at the bottom...

Hi,
here the screen after reset :
[attach=1,msg177466]

- The first charline is totally useless (Green rectangle)
- The [1..25] character lines are OK but have an offset of 1 charline (White rectangle)

To restore initial screen :
- Copy charlines [1..25] to [0..24]
- And restore charline 25 from a storing area (8*80 Bytes used)

But it takes a lot of times and the scrolling will really slow-down every 40 moves.

Is there another way to do it effectively ?

Example updated

[Axelay]

But it takes a lot of times and the scrolling will really slow-down every 40 moves.

Is there another way to do it effectively ?

Example updated

Hi



It's hard to say without knowing your requirements and conditions, but if you're desperate to avoid dealing with the screen address reset then some possible ideas:


You might have seen one of my own early games approaches to avoiding the screen address reset being on screen, in Star Sabre I reduced the number of vertical character lines to 19 and had background details separated by a blank areas every 5 screens or so, where the blank area was an opportunity to reset the screen address offset without it being visible as there were only sprite objects on screen.  But that's a pretty specific solution, and requires reducing screen height.


One other idea that comes to mind is also pretty dependant on what you're trying to do, but if you are not planning on double buffering, but could afford to use two screens, you could scroll your active screen from it's 0 to 39 offset while building to a 'hidden' second screen the graphics at the correct offset for taking over when you would need to go to offset 40, where you would reset the offset to 0 and change the screen base address to show the previously hidden screen, and repeat the process in turn, alternating between the two screens every 40 steps.  In that way you could just write 1 column of characters to the background screen each game frame, rather than the whole screen in one frame.  Or if you want a two way horizontal scroll like your code example, you would need to write 2 columns of characters each frame, using the current screens scroll offset to determine whether you need to be building the screen to be for the left or right of the currently visible screen.

[Arnaud]

Hi @Axelay,
and thanks for you detailed explanations.

It's hard to say without knowing your requirements and conditions, but if you're desperate to avoid dealing with the screen address reset

In fact, the screen address reset is a good solution for me, but i'm trying to do as fast as possible for not break my 50hz scroll. And visibly there is not easy solution.

[Axelay]

In fact, the screen address reset is a good solution for me, but i'm trying to do as fast as possible for not break my 50hz scroll. And visibly there is not easy solution.

Well, 50hz is always a good target to have in my book.