Roku Developer Program

[Komag]

I try to revisit work done a few weeks back, see if my documentation is clear to me, and if not, refigure what I've done (since it's not THAT old I can get "back into it" pretty quick), and improve my notes accordingly.

[dev42]

Thanks guys. Appreciate the help.

The following are off thread topic, but relate to the issues I'm having. Maybe I need a state machine? Or at the very least, more "finite" and less "unknown" situations?!

• State - Game Programming Patterns/Design Patterns Revisited


• Creating Custom BrightScript UIs with Image Canvas

"Rek" wrote:
Sounds like time for a refactor! 😄

In a twisted way of looking at all this, I am! 😉 Just took a long way to get... here.

"Komag" wrote:
I try to revisit work done a few weeks back, see if my documentation is clear to me, and if not, refigure what I've done (since it's not THAT old I can get "back into it" pretty quick), and improve my notes accordingly.

Awesome advice. I have a ton of "to do" notes. Better documentation would be helpful. Interestingly, I have a comment at the very top of each doEvent() func something that gives the impression that I intended to have only one function process events at any given time, but I haven't done it that way!

Also, I've never been a fan of flow-charting, but I'm thinking I *REALLY* need to get over it and sketch out what's supposed to be happening in order to have a way to compare what I think my code is doing and how I've implemented it. The same for what I'm debating with using multiple event loops with getMessagePort().
______________________________________________
update:

• Naming convention may be my NEMESIS! My current doEvent() functions *process* button presses, but in my attempt to make a new SuperMenu, I confused this with what would be called when a component was selected/executed... ~ onClick.


• Built in roku components aren't modal. *facepalm* They can be, but don't have to be! I'd still need to send in whatever functions need to be called regularly to be called in the new event loop...


• Here's a different way of saying what I was initially asking:
  

  "an anonymous genius" wrote:
  U want to know whether you should have a kind of hierarchy with the event loop where one loop takes precedence over another. Or should the main loop be mutating like a plugin for each game state. When the modal dialog comes up it changes the game state that changes the event handlers. Personally i would try to keep the event handlers for the input pluggable, like your state machine idea. To me, i think of the input hardware as constant, so that should be one thing. And then when the game changes, the behavior triggered by the input naturally changes. So that would be your state transition in your state machine. But you may want to do the opposite. ... Maybe the roku system favors the hierarchical looping. Sometimes may want to avoid fighting the framework too much.

[Rek]

Sounds like maybe you want a stack of components instead of a hierarchy. I was thinking more about a generic UI system like android's where different components on the screen can react to events (i.e. buttons, text boxes, etc.). But if you're trying to achieve something more like a pause screen in a game, it might make more sense to design your system as a stack of "GameStates".

With that approach, you would only pass events and things like physics ticks to the top-most "active" GameState. So, initially you have a single GameState in the stack (main menu), then the user presses "Start Single Player". At this point, you would create a new "SinglePlayerGameState" and push it onto the stack; making it the new "active" GameState. The MainMenuGameState would still be in the stack, but essentially idle (you may want to release resources used by idle states -- depends on your needs). Finally, if the SinglePlayerGameState receives an event that it interprets as a "pause" command, it will create a PauseGameState and push that onto the stack, making the SinglePlayerGameState idle as well. All you have to do then is pop states off the stack to go "back".

I hope all that makes some kind of sense...

[dev42]

"Rek" wrote:
Sounds like maybe you want a stack of components instead of a hierarchy.

stacks FTW. Well, at least in theory. I haven't gotten that far. In "refactoring" / "making new code" mode.

Here's what I think I understand ( yes, I re-read that 3x to make sure I had it right ), Menu's and sub-menu's will be on one Stack, but their components ( buttons etc ) will be Lists ( one per Menu ).

Since I haven't yet gotten to the "Stack" phase of all this, I'm not sure how it'll work on screen. It might be a simple situation where I treat the "SuperMenu of Awesomeness" Stack as both a Stack and a List. The reason for both would be to make sure everything is drawn that needs to be -> "for each" -> [ List ] and to send user input to the active sub-menu -> .GetTail() -> [ Stack ] ... [ ifList also has .RemoveTail() ]

As for where I'm at right now, I'm still trying to find more descriptive names for things *and* where to put functionality. For example ( WARNING: this is not for the faint of heart. Sleep deprivation played a factor in this. Continue reading at your own risk 😞 I considered making onClick() -> onClickAndExit() that would return a Boolean if the component closed the current sub-menu. Thankfully, I came to a better / clearer solution which was to simply have a Boolean flag "exitOnClick" in the component and check that instead. It added a line of code in the event loop dag-nab it! But it is much clearer. [ of course, now that I've typed all this out, I start to re-consider and think "exitAfterClick" or "closeDialogAfterClick" would be better names! ]

I also have some Q's about "global" vars or accessing variables of different objects from within a menu, but I'll save them for later.

The further I go down this rabbit hole, the more I wish I'd just use the built in SDK UI elements and bend them to my will. 😉

peace, good night now & 42

[dev42]

I've got a few more Q's in regard to adding / removing objects from the "allObjsToDrawStackList":

• Would it be OK to make allObjsToDrawStackList a global?


• or better to pass it into *all* offspring obj methods?


• and what about the parent object... like appending a sub-menu to the parent menu?

History is repeating itself... or I was a better programmer before... whatever, I'm going to create a circular reference and link to the other thread.

Please follow the rabbit ... OOP: access parent obj & Inheritance