- Mar 6, 2019
- 438
- 622
I don't have a good solution for this slowdown because every time there is a "new" text to display, the tool needs to handle the text display.zths
I'd like to ask for a little help with Kirikiri games in general. The main problem right now for me, is the major lag the English TL's injection is producing...
Just try it on literally any Kiri game: see how skip works without mtool, then how it works with it. Like a good 10 times slower with the tool injecting. You will notice things are a little laggy and choppy too, when character display is set to instant, or just fast, even when not skipping.
The major problem is when there is e.g. a looping animation playing in the background, or a screen effect - getting the next line makes those choppy, very much stuttery (like it pauses for a quarter second), and it could become quite annoying.
It's not a font issue, I'm certain. Also, funny thing is, if I "Restore original text" (but mtool is still running the game), things become MUCH smoother, this behavior becomes much less noticeable (still there, though), but it will still take like 3 times as much time to skip to the same place, then it would take without mtool.
I don't think tags and the macro file has anything to do with it, even checked the translated scenario files in __MToolTrsData and there doesn't seem to be anything to suggest something like this should be happening.
Any advice?
(really, just check skipping with and without mtool in any kiri game, and you will understand what I'm talking about)
This process will often even catch text that will not be displayed, as long as the game deals with these things in some way, the tool will stepping in.
And then the bigger the game texts are, the more slower it gets.
It is involved in the display process unlike other tools which simply send the text out, it receives it, processes it and returns it to the game, during this period the game is stalled.
There is a lot of text processing going on, and I've optimized the performance as much as possible, which is the best I can do.
There may be better changes in the future, but I won't be working on it specifically for now.
Because the result may not be better in all cases, it may be worse.