Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(4 edits) (+1)

Alright, after looking a little more into it, I think I've got some useful information. Because of not managing to get a black screen "debugger" video to run after deploy (turns out video file paths are unreadable after deploy if you include the first slash: "movies/video.webm" works but not "/movies/video.webm", at least on my end [Windows 10]) for a rather embarrassing amount of time, I found a probably fancier solution.

But I believe it's quite unreliable though, since it involves directly altering the base code for a project and I don't know yet how this would or even should be implemented as external/plugin code...

So, knowing it's an issue due to the built-in video player implementation, I went through a bunch of the base code and found the following function in rpg_core.js, line 2856, component of the Graphics class:


Graphics._onTouchEnd = function (event) { 
    if (!this._videoUnlocked) {         
        this._video.play();
        this._videoUnlocked = true;     
    }
    if (this._isVideoVisible() && this._video.paused) {
        this._video.play();
    } 
};


Since it's not my code and i'm still new to JavaScript in particular, the way I understand this function is as some sort of handler for video playback on input (given Input._onTouchEnd) or minimizing/alt-tabbing during video playback.

Since video playback events were not originally intended to happen on the title scene or rather without any input at all, which probably includes player character touch, it makes sense for this issue to not be addressed, which is the first condition happening. Here's a change on the first condition I added that solved it for me (swapped some lines for comments to highlight the change): 


Graphics._onTouchEnd = function (event) { 
    if (!this._videoUnlocked && !Scene_Title) { 
        //rest of the code 
    } 
    //second condition 
};


That way, the condition should be checked for every scene, except during the title scene, which is when the pre-title splash media plays (before drawing the main menu screen), as I've come to understand while tinkering around.


This has worked for me smoothly so far, having tested with multiple playback requests queued, but not with different videos (not sure if it would differ. Blame that on my laziness, which did not want to grab, convert to webm and test with other videos at that moment). However, doing this change ought to negatively affect any other video playback in the title scene (menu navigation), in case you'd include one in your game.


Therefore, further extensive testing might be required to assure a proper solution. Haven't found anyone talking about it so I thought this might be useful, at least towards a better comprehension on future modding regarding video playback.


PS: Upon further analysis on RPGMaker MV's video playback while writing this comment, I noticed the variable _videoUnlocked is initialized as false, only changing after going through the first condition mentioned above (which requires it to be false). Which in turn made me think on how the problem actually happens by the base code, in summary:

  1. The video play function is called, which then loads the video;
  2. The function which handles video load then calls the function that updates video visibility, turning it off;
  3. Steps (1) and (2) are normal. But pre-title splash videos are not played by input, so they never go through the Graphics._onTouchEnd function, leaving the variable Graphics._videoUnlocked as false, unchanged;
  4. That means MV will understand your video as not really having played yet, leading to your next input (iirc during testing this happened no matter the inputplaying an "invisible" video only once, enough to "locking it" (setting Graphics._videoUnlocked = true) from playing again. This is also why the issue doesn't happen when you input during a playback - which will either skip or do nothing (depending on plugin settings) - it (kinda?) reads that first input as the input that plays the video, "locking it".

So another solution came to me: to set Graphics._videoUnlocked = true after loading/playing its respective video anyway. Haven't tested that yet, but it might be riskier than the other hard coded solution. If it's possible to bring the logic presented here properly and polished out of the base code to plugin development, it should be handy.

Have not had the time to try that yet, plus having very little JavaScript experience and barely any search results about solutions on this issue makes it quite the time-consuming activity. Hope this helps and finds you well!

(+1)

Thanks for digging into this.

If I understand correctly, I can fix this issue by setting that flag to true during the creation of the window that causes the video playback to start. I did a quick test on my own, but I'm not able to reproduce the sound carrying through issue on my end at all. In my simple test I have one splash video and nothing else. Hitting a key to skip it, or pressing a mouse button seems to skip it normally with no sound continuing through to the title screen. If I do it with two videos, and skip them both, I get the same - no sound playing through the title screen. 

I added a line to set that flag as true in the window that shows the videos immediately when it is created, and that doesn't seem to stop anything from working on the splash screens, and doesn't cause an issue with audio playback, but I never saw the original issue so I don't know that it fixes it either.

Window_DummyWindow.prototype.initialize = function(rect) {
Window_Base.prototype.initialize.call(this, rect);
this._frameCount = Ramza.PTS.params.waitFrames - 12
this._waiting = false
Graphics._videoUnlocked = true
};

Basically I just added the last line to that function in the MV plugin. Try that and see if it changes anything? I suspect it might also cause an issue with video playback elsewhere in game, as the flag will start true unless I also reset it later.

(4 edits)

Alright! So, thing is, the issue really isn't there when you skip, it happens when you don't: 

Let's say you have a video followed by an image: not skipping/pressing anything during the video playback makes your next input (whether be it while the image plays or later on the title screen) to play just the audio of the video played earlier (as if it's playing in the background).

In case of multiple videos, to my understanding, each is a separate instance of video handled by graphics processing, so skipping all or each one of them will not land into an issue. Not skipping, on the other hand, will result in the same as explained above, except that the repeated playback will be from the last video played (the latest video instance)


Nevertheless, about the patch: hypothetically, I thought it should work seamlessly to, indeed, set that flag as true on the plugin-side, just didn't really know where...It should work properly because not only the variable would be set once per instance(per video) but also because the plugin code is only intended for the title scene (or, rather, maybe inbetween the boot and title scenes) - not affecting the rest of the game.

I did testing with multiple splash videos; splash videos and image; splash media + events (sole movie players and play movie inbetween an event's other actions) and, well..Seems to work properly so far! I have only not tested with playing videos via title screen (menu navigation), but I decided to not bother with that, since MV does not have built-in functionalities to edit the menu screen selection flow (as far as I've known).

Since this is a solution to circumvent an issue done by the engine itself not accounting for unintended use cases... hopefully it keeps working, lol. Let me know if you'd like any recording about the problem/testing or any other problems about this that may come, best regards!