Roku Developer Program

[coredump]

I have been going through NewManLiving's grid example:

viewtopic.php?f=34&t=66785&start=30#p429037

and had some questions:

* Should I use the roTextureManager to load bitmaps in the function:

GetVCBitmaps(number As Integer, row As String, width As Integer, height As Integer)

or is there a better way to download and draw when the bitmap comes in, so that I do not have to wait until all of them are loaded before drawing ?

* Is it possible to draw the region in just a portion in the screen, so that I can put a menubar on the left and accommodate and overhang, if so what is the best way to do this ?

[NewManLiving]

The texturemanager provides the asynchronous services that you need. This has nothing to do with sprites, regions, or compositors. However, you should understand that asynchronous retrieval is far more complex than waiting for all your bitmaps to arrive (synchronous). You should avoid synchronous requests for your grid. This is true even for preloading. Preloading should be done by asynchronous request sets and then polling for their return. Preloading is generally done prior to your grid showing. From then on it is realtime requesting, cancelling or unloading of textures as the user nagivagtes the grid. Threre are two primary problems that need to be solved in order to do this: The textures are requested asynchronously without waiting for them to return. This means the texturequest must stay in scope until completed; You have only a single thread to work with ( no worker threads ). This means that you have to check the texture queue ( I recommend a dedicated port ) In just about everything you do from then on, especially your scrolling and easing functions. It is important to quickly process the returned requests so that the queue is emptied and state of the requests are know and kept current as the user scrolls.

To do this you need to create a system that identifies each texture. This generally means an object that contains everything you need to draw to your grid. For example ( Im just typing this in quickly wthout really checking it but the concept is:

Function NewTextureObject() As Object
   return {
                TRequest: Invalid
                Bitmap: Invalid
                GridX: Invalid
                GridY: Invalid
             }
End Function

You would create one of these objects for each texture that you need to request. While the texture object can be reused, the TRequest cannot. So you need to create a new TRequest each time you request or re-request a texture. You would keep an array of these texture objects as a member of your grid object to insure persistence

This example will exaplain more. It's an old example improvements have been made but the idea is the same
http://forums.roku.com/viewtopic.php?f=34&t=70983#p446193

This will give you a general idea of how the manager works

[coredump]

Thanks, I will definitely look into integrating that concept into my code. Your grid code currently takes up the whole screen is it possible to draw the region in just a portion in the screen, so that I can put a menubar on the left and accommodate and overhang, if so what is the best way to do this ?

[NewManLiving]

That grid is a bitmap buffer, the size is calculated by random generation to fill not more than the display size
That is a demo grid. The goal is to show how to use a virtual buffer with region offsetting to control memory
Allocation and optimize drawing. At that time I did not know too much about the texturemanager so I did not include it. Since then I have incorporated the manager into my own grid and changed some things to further optimize it. In my experience (having tried several ways) the original concept proved even more beneficial than I first realized
If you understand the grid then you can make it any size you want. Or just move the coordinates of the sprite to make room for everything else. Currently it is centered in the display. You can add an overhang, menu, selector or anything else. For this reason I suggest that you stay with compositor. once the sprites are created then compositor.drawall paints everything for you. This frees you from having to manually redraw everything each time a texture arrives. The more rich your display is the more you have to draw. This becomes a real issue when scrolling as bitmaps are rapidly arriving. It still has not been proven if their is a significant speed increase or not. I still have a gut feeling there is and plan on extracting the compositor from my channel to do my own testing. There are other factors beside drawing that need to be factored in as well such as for loops and anything else that would have to be done manually

[coredump]

How do I make your virtual grid only scroll vertically ?