“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.
“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” 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.
“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 . 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.
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:
[upload|DZYTkJ7SiI1ZfkAurNH0Ew==]
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.
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
“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.
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.
“marcelo.cabral” wrote:
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
You can, but if you’re already using 854x480, it won’t make much difference aside from stretching it horizontally.
“marcelo.cabral” wrote:
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.
There’s no built in way to flip an entire image, but you could do it programmatically by copying the sprite to a new bitmap one row/column at a time using roRegion. I did something similar to produce a reflection effect.
How is the sound generated?
Also i wonder, given someone made a javascript version (vs 6502 asm) - wouldn’t it be “easy” to write an interpreter/(trans)compiler for that?
“EnTerr” wrote:
How is the sound generated?
Well, this was another aspect of Roku I wasn’t aware of, it only allow 2 audio streams playing at the same time, one wav with roAudioResource and another with roAudioPlayer.
So I basically added the short sound effects as wav (roAudioResource) and some other effects/songs as mp3 (roAudioPlayer).
“EnTerr” wrote:
Also i wonder, given someone made a javascript version (vs 6502 asm) - wouldn’t it be “easy” to write an interpreter/(trans)compiler for that?
That’s a good point, the original Javascript code uses Phaser HTML5 framework for games, and I created a simple Notepad++ macro that helped me to translate most of the JS->BS sintaxes, and I believe it’s feasible to create a more inteligent tool to make this conversion, would be an interesting project.
I have a roadmap planned to release the source code:
April 10th - v0.7 - Classic Mode scaled to 640x400, death on Slicer/Spikes, injury by falling plates, Crop/Mask fixes
April 30th - v0.8 - Slow Fall Potion, Screen Flip Potion, Guards Fight, Save Game
May 30th - v0.9 - (release to GitHub) Cut Scenes, Special Enemies, End of the game (Level 12-13-14), Documentation
A great coincidence (or not) is that May 30th is my birthday
I’m not sure I’'ll have time to implement all, but I will release “as-is” and hope people will help me finish it
I just published version 0.7 whoever requested the link to the private preview channel will get it automatically, I will make a new video with the changes soon.
The changeset of this release is the following:
0.7 - Classic Mode scaled, Die on Slicer/Spikes, Injury by Falling Plates and Mask/Crop fixes
Add: Classic Mode scaled 2X to be painted in 640x400
Add: Control options adapted for remote controls without the buttons: Replay, A and B
Add: Kid will die when running or falling on spikes
Add: Kid will die when crossing a slicer in the wrong time
Add: Kid will be injured from falling plate
Add: Game sound effects: spiked, death, slicer, long fall, harm
Add: Menu sound effects: menu navigation, menu select
Add: When level starts in front of an exit door, drop it!
Add: Turn the kid direction when a level starts
Add: Use “medland” action on the first level and first room before the “suspense” sound
Add: Gray border around the game area
Add: VersionInfo added to the bottom right corner of the screen
Add: Level transition by falling - not on JS - (L6-L7)
Refactor: Renamed Chopper tile to Slicer following original Apple II code naming convention
Refactor: Added a priority system to play the sound effects
Version info is too much in the corner, that edge gets chopped off when TV is in overscan mode. Somewhat cryptically (un)explained at https://sdkdocs.roku.com/display/sdkdoc … 2Safezones - but as rule of thumb be ready for up to 5% on each side of the image might be chopped off by the TV. Yes, many/most digital TVs still do that by default, long established tradition.
I notice once chosen, can’t go back to change the game mode from 1x1 to 2x2 or 3x3 but perhaps that’s intentional. The zoomed 1x1 mode - now that feels more the real thing!
“EnTerr” wrote:
Version info is too much in the corner, that edge gets chopped off when TV is in overscan mode. Somewhat cryptically (un)explained at https://sdkdocs.roku.com/display/sdkdoc … 2Safezones - but as rule of thumb be ready for up to 5% on each side of the image might be chopped off by the TV. Yes, many/most digital TVs still do that by default, long established tradition.
I notice once chosen, can’t go back to change the game mode from 1x1 to 2x2 or 3x3 but perhaps that’s intentional. The zoomed 1x1 mode - now that feels more the real thing!
I know that the version is too close to the edges, that thing is more a reference for me when developing, I don’t think I will keep that anyway.
Next release I will make it possible to hit the back button to come back to the menu.
