Any improvement on XDK deployment?

[omega1227]

So, about 6 months ago I decided I wanted to export my game to android. I went through the manual process... but I could never get it to work. Then I found the XDK method and this worked to get a playable version on my nexus 6p. However, it suffered from (well-documented) lag issues and it became wholly unplayable.


So, I was just wondering if there's been any progress made on how to fix the issue? Or has there come about a new, easier manual method? (I know it's probably easy for some, but I followed the steps I found to a T and it still didn't work...and I don't know enough to troubleshoot). 


Thanks!

 

[Andar]

Before any fix can even be considered, you'll need to find the cause of the lag.


There never will be any fix if the cause is that you're overloading a mobile's capacity - because that sort of lag will not be caused by the engine, but by your project being unable to work on the limited capacities of a mobile. For example, if you're using parallax mapping that is a no-go on any mobile deployment, and the only way to solve that is to buy a mobile that has double the processing power and four times the RAM of the best mobile currently available.


(OK, some people might get parallax maps usable if they're staying at minimum map size and be extremely inventive about reducing picture sizes, but in general parallax mapping is a very bad idea for mobile deployment).


And there are a lot of other techniques that will always create lag on mobiles simply due to mobiles having less processing power than full computers.


What can be optimized in the engine has been (especially the change of the pixi version in 1.3.0), if it still lags after updating your project to that version, then it is because your project (and not the deployment) has the problem.

 

[omega1227]

I see what you're saying, but it goes against what I've been told. I was told that the XDK method was simply the inferior way of deployment because it always suffered from bad FPS. When I was posting about my woes way back, I was told to try the manual method because it circumvented the problems that the XDK method was plagued with. Is this not the case? I have never used parallax mapping or anything fancy in my game. I used quite a bit of plugins, but I was told these wouldn't really affect anything.


I haven't touched RPG Maker MV in 6 months. What is this pixi version? What was changed with the 1.3 update?


EDIT: Nevermind. I googled the patch notes. Looks like this may have actually fixed the issue... I guess I'll give the XDK deployment another go and see what happens.

 

[Andar]

the one fact does not exclude the other - I don't know which method of deployment is better and which not - but even using the perfect deployment will not cause your mobile processor to run faster than it can.


And parallax maps are only one possible cause - a single badly written parallel process event can cause lag on even the most powerfull desktop PC. OK, it needs to be very badly written if you got a current top-line computer, but even that is possible with the wrong combination of loops and parallel processes.


So if you have any suboptimal parallel processes in your game, that will cause lag on mobiles no matter what you do. and no update to the engine can change that.


The problem here is that lag is both additive and subjective - which means that instead of one badly written parallel process, the same effect could also be caused by several halfway good PPs or by two dozen relatively good parallels, and that something that doesn't show lag on one computer can freeze the game on a different (less powerfull) computer or mobile.


If you still got lag with the newest updates correctly applied, then you need to find the cause of the lag before anything can be done. For example while the memory leaks in the engine have been fixed, there are still a lot of plugins out there that have their own memory leaks, and no amount of core updates can solve those problems if you're using one of those plugins.

 

[JLowther]

I was about to create a thread about this exact subject but I figured I may as well post it here...


I've been extensively testing RMMV's deployed games on iOS devices, especially iPad 2 and 3.


RMMV won't run above 40-45 FPS on iPad 2 and 3 with a project that's completely fresh and has only the 4 characters walking around the default intro map. No common events, no additional assets, no plugins, nada. I can safely say that there are no changes a person can make to their project in RMMV that will somehow bring the performance up above the 40-45 FPS range (I emphasize the iPads 2 and 3 because they're still the most widespread tablet devices out there at this time, meaning they have the most marketshare).


This unfortunately throws off every piece of timing in the game, as many of RMMV's internal workings (such as the "wait" command) count frames with the assumption that there will be 60 of them per second.


But this may not even be an issue with RMMV itself but with how Cordova handles it, so I'm not even sure where to look here. There are some plugins out there that attempt to decouple framerate from in-game logic, but I've had no success with any of them when it comes to making things less muddy on the iPad (and I've seen far more graphically-intensive apps run fine on these devices). Worse still is the fact that the framerate difference means even plugins that try to wait for a SE to finish before continuing are wildly off, time wise.


I get the feeling that a lot of this could be fixed if RMMV could somehow acknowledge its current framerate, but maybe that's not even the real issue.


Who could we possibly talk to about optimization, here?


EDIT: Here's an interesting tidbit: even when using a plugin to cap framerate at 30 FPS, the wait command still functions on a PC as though it were running at 60FPS as there's no time stretch happening. The same cannot be said for an iPad2, however.


I suppose this means that framerate clamps are only capping the graphical framerate, not the internal logic's framerate.