Hey digging into the new tutorials and noted on video 2_AddingAssets, at 6:20 you export and test, with screen data loaded and you viola see a screen. unfortunately if someone is first time digging in, in order, their expectations will fall short as they will get a grey screen when emulating the first time. i imagine you want to hit a wow factor as someone first time beginner able to create and show actual emulated NES graphics in under 30 min. but between takes from video 1 and 2 you set the HUD (to get assets/background to show), set the start screen and placed player (to get the right screen to load), and animated the character, set a palette, and set it's object details of player/persistent (to get the player to actually show up). i know it's earlier in the tutorial to get this to happen, but showing the emulation successful is gonna cause a pile of folks whining it's not working right haha. may want to show that as a "i'll explain these later, for now just hit these quick to start testing screens." also wanted to mention the pace and explanations are great. going over again is helping become more familiar with the tool. only gripe so far is 3 videos in i've only touched code once ..and it was commenting stuff out haha!

Particular to this tutorial also not sure how empty it’s supposed to be, but dumbMovementRight and dumbMovementLeft are already loaded. Wasn’t sure if you meant to include those or have us write em in. Easy enough Routine to start with for sure!

cool went through the update and yeah now folks should be pretty excited to within their first session have a sprite appear through an emulator. on video 4_ChangingObjectStates, (all those scripts are still written in there haha) i was wondering the difference in changing the player state between coding in a input derived ChangeObjectState vs. an object details/actions/end action/GoToFirst (or previous). the difference in gameplay seems delayed for the object details route. both seem to work, but i'm guessing the input route is just faster to update?

Hm - as for the player state. Any input code is absolutely happening with immediacy, as the inputs are handled every frame. The timers are also running every frame though, and if a timer runs out facilitating a change, that should ALSO be immediate. It's just hard to quantify exactly when the timer is changing, I guess? But no, it should also be instantaneous, unless you have crazy amounts of things happening per frame (but then you'd also get NES slowdown effect).