Roku Developer Program

[NewManLiving]

Or simply do you have more than two rows ???

[coredump]

Yes, I have multiple rows.

Here is how I am drawing the images:

Function DrawPosters(screen, a_coordinates)
 	for each coordinate in a_coordinates
     	screen.DrawScaledObject( coordinate.x, coordinate.y, 0.75, 0.75, coordinate.image )
 	end for
End Function

So, essentially the cropping is just the bitmap being drawn partially off the screen.

[NewManLiving]

Well that clears than one up. Now the big question - Are you able to load all of your posters without running out of memory ( not the same on all devices ). Or do you plan on retrieving as you go along. This is a REALLY BIG IF.

[coredump]

That is the big question. Currently, the plan is to grab them all at once with the texture manager but may need to change my strategy if a "lot" of movies come into inventory. I am currently developing / testing on a roku3 but as you have pointed out, each one is different

[NewManLiving]

Got to leave will get back.

[NewManLiving]

What you are trying to accomplish is quite an undertaking. Now if you were to restrict yourself to ROKU 3 then you would have less of a problem and more freedom to use the standard method of offsetting bitmap coordinates. However, due to the processor/disk intensive nature of the texturemanager as well as the need to update your screen constantly as bitmaps arrive, the lower-end boxes do not perform well and the response Is more jarring rather than smooth, if you allow the user to scroll while bitmaps are coming in. In my experience ( and I have tried using just regions and bitmaps ), Use of the Compositor, sprites and regions has several advantages. First, the compositor is responsible for drawing all sprites. So one call to compositor.DrawAll takes care of all drawing. Otherwise you would be in a constant loop iterating through each row to refresh the screen with the incoming bitmaps. Second, region offsetting is preferable to changing coordinates of the rows of bitmaps. Only the new row is drawn in and the other rows that are in the display are "scrolled off" by movement of the region alone. This allows you to keep the coordinates of most of the bitmaps intact and therefore your texture receiver can pop in the textures as they arrive. otherwise you would have to let the texture receiver know that all the coordinates have changed, because the user just scrolled. This becomes a big problem with easing since you are in a coordinate-changing loop. Bitmaps arrive very quickly putting you into an instant whirlpool. Composite drawing and region easing is far more optimal

A while ago I posted an example of a grid that does not use the texture manager. I have since improved on the grid itself choosing to use a display stack to wrap around instead of indexing. This is very optimal since there is only a few rows that can be displayed at one time on the screen with your standard poster sizes ( 2-3 ). So pushing and popping indexes is very fast and there is no indexing or math involved. It also is a more natural fit for easing regions. I have also added a cachemanager object which incorporates the texturemanager

While I do not mind sharing the new grid, It is useless if you cannot understand how it works, or have a bias against composite, sprites and regions as some developers seem to have. Thus I have not put the new grid out on the forum. My suggestion is to run the old grid and study my style and logic. Although I have refined many things the core is the same. If you can work at understanding it and see it as beneficial for yourself then I many consider releasing the new grid, It really is nice and performs very well at least on what I am able to test it on (3, new stick, and 2xd ) I plan on getting a 1 box (amazon) to see how it performs. The link to the old samlple grid is below


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

[coredump]

ok, thanks I will look into the "old" code and figure it out.

[TheEndless]

"NewManLiving" wrote:
or have a bias against composite, sprites and regions as some developers seem to have

Whaaaat? 😉

[NewManLiving]

Now I was not referring to y 😄 u my friend. It was you who influenced
Me to use both screen and compositor which I now do. But I recall that my "passion" for
The compositor as you once called it did initially meet with some resistance.

After all ( as far as I can tell, you would know more) There are appears to
Be only a handful of 2d developers on this Forum. And I believe that most
Use coordinate offsetting as far as anything similar to a
Grid is concerned.

[RokuMarkn]

I think whether you use the compositor functions is mainly a matter of personal preference. Personally I've written a dozen or so significant apps using the 2D API but I've never used the compositor. This is mainly just because drawing without the compositor is more similar to what I've done on other platforms. I haven't done any measurements but I'd be surprised if there was a significant performance difference, except perhaps for a few things like collision detection.

--Mark