Paginated item list window

[Mithran]

@Engr. Shana


You are running into a few bottlenecks with that approach due mainly to the system that you are building on:


1. You are doing a full refresh every time you need to draw the screen. You do not need to rebuild the data array just to scroll, you only need to draw the relevant items from the data array.


2. You are refreshing the screen more than needed (eg., every time the cursor moves, instead of when the page changes).


3. The way the Window determines which items are to be displayed is horribly inefficient for large lists. Every window will iterate over every single item the party has on every single refresh.


4. The same with the way the item data is stored and retrieved. For example, armors iterates over an array of ids and gets the actual object and puts it in another array which is done every time it is accessed. It then sorts that array, iterating it again. This compounds with the above for some very long lookup times when dealing with large lists.


5. Window_BattleItem further iterates through every single item in the window to find one that matches the last selection, which is why it is even more pronounced in this.


Basically, we can't just consider how the window handles and draws data, we have to consider how it is handled by the system as a whole. A simple way to minimize bottlenecks due to a given costly algorithm would be to overlay a temporary cache on the accessor so the algorithm does not get run more than necessary, clearing the cache only if the underlying data is changed so it is rebuilt on next lookup. That may or may not be sufficient, since a single lookup on a single method is still as many iterations as you have items, and many of these methods iterate. A real fix would require changing how the data is managed as a whole.


On the plus side, when tested done with reasonable numbers of items, I have no notable slowdown from drawing a full page of items at a time, even without using my Text Cache script, so it is a solid proof of concept for by-page drawing.

 

[Engr. Adiktuzmiko]

I know of the problems especially since it refreshes whenever the index is changed (it was a "quick fix" for some weird things I encountered)... I just don't have time to produce a more efficient one when I made it so I focused on the crashing problem first... anyway, anybody can probably build up on it if they want to... or as you suggested, it would be better to modify how data is managed as a whole to make things faster...


I'm gonna work on 1,2 when I get time... but for the data handling part, I can't work on that right now...

 

[Tsukihime]

My instance items script stores all items in an array. The window would simply grab a reference to this array, and if they need a subset of it just use a regular sub-array methods to do it. Which is probably why the script performs a lot faster when instance items is involved.


I have another script in mind that is based on the way I store instance items, but instead it will be used with the default engine: the inventory hashes are used for counting purposes, while the actual armors/weapons/items are stored in arrays.


This is a logical way to do it because arrays preserve order. Ruby hashes preserve insertion order but that's not really useful.


I didn't know about the battle item window behavior. That's...lol kind of stupid. Even with flexibility in mind, there's no reason why anyone would need to do that.


When I looked at the class, it was overriding `include?` so I just assumed it was grabbing from the `@data` array.