Roku Developer Program

[marcelo_cabral]

I missed this one:

"EnTerr" wrote:
The idea of showing 2x2 and 3x3 rooms on screen is interesting... not sure a quite buy into it, since part of the game challenge was keeping (mental or not) map of the dungeon, this makes it easier - suppose i am "originalist". Also the non-4xxx players seem rather "syrupy" in such modes.

It's true that it will give up a lot about the game on the multi-room modes, but it open up other possibilities, actually the people from the PoP Mod community (princed.org) is already saying that it open up new ideas for new custom levels.

To add support for custom levels and sprites is really easy as the game was developed, all is needed is to create the converters to the JSON format I use.

[EnTerr]

"marcelo.cabral" wrote:
This is on my backlog since the beginning, the issue is that Roku 2D API does not have a simple way to do this, I will have to scale every sprite and save on temp, other game engines has this as generic setting.

, src as Object) as Boolean
Seems pretty straightforward? I think it won't have noticeable delay doing this on-the-fly (i.e. no need to precompute). Should be easy even on the non-OpenGL players, one would think.

[marcelo_cabral]

"EnTerr" wrote:

"marcelo.cabral" wrote:
This is on my backlog since the beginning, the issue is that Roku 2D API does not have a simple way to do this, I will have to scale every sprite and save on temp, other game engines has this as generic setting.

, src as Object) as Boolean
Seems pretty straightforward? I think it won't have noticeable delay doing this on-the-fly (i.e. no need to precompute). Should be easy even on the non-OpenGL players, one would think.

The issue is because I use Sprite object and the draw is made by the Compositor.

The ideal would be to have the Compositor know the default scale once and after that everything was scaled.

[EnTerr]

"marcelo.cabral" wrote:
The issue is because I use Sprite object and the draw is made by the Compositor.

Oh i see. roCompositor/roSprite, huh... is there any reason to use them though, does it give you anything?

When i first read on them, my reaction was <shrug>. It's just a thin veneer over roScreen/roBitmap that gives you... i don't see it giving anything that i couldn't write in a few lines of code on my own. Kinda worthless IMO (somebody correct me, what am i missing?), it should have been a BRS `Library` to include instead of being baked-in.

[marcelo_cabral]

Well I never actually measured, but I assumed it was faster (or at least the same speed) and for sure is way simpler to handle this kind of game with several different animated sprites.

For instance to set those "torch" tiles animations all I need is to randomize the regions ids, add those to an array and send to the Compositor, it will handle the redrawing for me.

I basically made some tests early on the project, and the Roku seemed to handle well the amount of sprites I have. Every room has 30 tiles and each tile is a sprite (torchs are animated), the painting happens (almost) like this:



The Image from the C64 port blog I mentioned before, the difference is that I paint the tile as a whole not in parts because I have transparency (png) what an Apple II or a Commodore 64 didn't have out of the box.

[marcelo_cabral]

Who is the Roku* guy that could help us change the API to add scalex and scaley as optional parameters to the Compositor.DrawAll() method ?

[Komag]

You can do it with a bitmap/region and just scale the entire thing. I did it before but didn't like the performance hit on lower end Rokus

Here are my personal notes on it:

Screen Scaling
- Bitmap "sizer" just after creating screen in Main()
- All regions to draw to sizer instead of to screen (and when m.drAA.fight.shClCnt > 0 we do sizer.Clear() instead of screen.Clear())
- m.sy.shrink: TRUE
Then, in drawStuff() just before screen.SwapBuffers():
- IF m.sy.shrink THEN screen.DrawScaledObject(128, 72, 0.8, 0.8, m.sy.sizer) ELSE screen.DrawObject(0, 0, m.sy.sizer)
(I also added that to fallDraw() for manFall())
- switching shrink True or False also sets m.sy.edgeClear = 2, then drawStuff() sees that and does two screen.Clear()s (one for each buffer)
This reduced performance too much - I won't be using this system

[TheEndless]

"marcelo.cabral" wrote:
The issue is because I use Sprite object and the draw is made by the Compositor.

The ideal would be to have the Compositor know the default scale once and after that everything was scaled.

Any reason you can't just use a smaller roScreen size for that mode? If you used 640x480, it would automatically scale up to 1280x720 without you having to change anything other than the upper left coordinates.

[marcelo_cabral]

I'm using 854x480 but the original size of the game is 320x200, that's why it still shows small

BTW can I set 640x480 with the Roku on HD 720 mode ? never tried, assumed with the documentation that this mode would only be available on SD

[marcelo_cabral]

Another issue I had was to flip the sprites horizontally, I don't know if there is a way to do this on the API (I only see we can rotate, not flip), so the solution was to create two sets of sprites.

If I had a way to flip would save a lot of space on the package.