How to handle View and texture for huge in height "scroll down/up" only game

[sysko]

Hello

I'm (re)creating a "piano-hero" game named linthesia  (https://github.com/allan-simon/linthesia the screenshot at the end may help you to understand better my problem)

basically I have a big texture which is the texture on which I draw all the notes to be played. then I put it in a view, and I move the view down with time so that it gives the impression that notes are "coming down"

it all works perfectly for short song

BUT for long song (well > 1 minutes which actually a lot of songs ...) I exceed the maximum size of a texture
with this error message:

Failed to create texture, its internal size is too high (700x21312, maximum is 8192x8192)

My basic idea on how to fix it is explained here  https://github.com/allan-simon/linthesia/issues/60
more or less:
 
1.  create 2 texture each one the size of the "view"
2.  display first texture , then second texture
3.  when first texture is no more visible,  clean it and draw on it the notes as it was the "3rd"  screen
4. repeat

I see the big picture on how to do it, but I got these questions:

1. can I have the case in which the view is bigger than the maximum size of a texture ? (I guess no, but I prefer to be sure)
2. my solution certainly does not work if the size of the view change over time (if I allow people to resize the window, of course I can workaround the problem by not allowing resize or keeping the view at the same size), or is it CPU/GPU cheap to recalculate the full "screen by screen" splitting on resize ?

I guess it's a "already-solved" problem, so if people have links to piece of code I can reuse, that will be of a great help, as it's the only major bug in my game before releasing a 1.0

Edit: now that I think about it, for my game maybe it would be easier to not use a view at all and just redraw the updated view everytime but i guess view are already made to handle "huge world"  , and certainly redrawing everytime is not very efficient in term of CPU/GPU

Thanks

[eXpl0it3r]

As you may have noticed there are multiple approaches to a solution and it really all comes down to what fits best into your code base without noticeable performance issues.
The two texture solution sounds to fit nicely into your current system.

1. can I have the case in which the view is bigger than the maximum size of a texture ? (I guess no, but I prefer to be sure)

The maximum size a texture can be is solely dependent on your GPU. There's unfortunately no guarantee for a minimum "maximum size", but every dedicated GPU from the past few years should be able to handle a texture of the screen size (again no guarantee).

2. my solution certainly does not work if the size of the view change over time (if I allow people to resize the window, of course I can workaround the problem by not allowing resize or keeping the view at the same size), or is it CPU/GPU cheap to recalculate the full "screen by screen" splitting on resize ?

You could simply recreate a bigger texture and rerender the notes, or you could scale the current texture to the new size. The second method can introduce some graphics "artifacts" due to scaling, but it wouldn't require the rerendering.
I don't know how your system works, but if possible go with the first option. Keep in mind that when people resize windows, it's normal that it can take a few seconds to adjust and you usually don't keep resizing the window every other second.