Here is a list of todos and ideas for further improvement of the WME engine:
1. The new patches contributed by yours truly could probably benefit from some optimization, performance-wise.
In particular,
- bilinear blitting is very naive, plus it’s all float, so it has large margins for optimization simply by replacing it with a well-known optimized algorithm.
- Multirect could probably benefit from some fine tuning;
- It’s a matter of finding the best balance between the additional cost of multirect and the cost of going through tickets and blitting.
On the other hand
- ui_tiled shouldn’t really require any further efforts unless some weird bug pops up.
- blending could have some margin for improvement, but it’s basically pretty much fixed as it is.
2. The debugger is a bit of a hack as it is.
It is by far my least-favorite piece of code in there.
The thing is, we don’t really have a compiler giving us debug symbols; instead what the compiler does (and always does, even in released games) is adding a special II_DBG_LINE instruction that keeps a special register up-to-date with the last line traversed.
What we do is watch for those instructions and infer everything from there, including keeping a history of the watched variables and inspecting them to see if they’ve changed.
Among other things, the original debugger does not have a watch feature, as it’s very awkward to do.
What one should do then is hack the compiler in order to have symbols and easily improve on the debugger.
Another interesting side effect of hacking the compiler would be the ability to inject code.
If nothing else, it would help to have the compiler bundle the source file with the code and/or adding a checksum, to avoid copying source files by hand (please note that ATM we have NO way of knowing if the source file matches bytecode or if it’s something completely different, at least some support for generating checksums should be useful and easily added. I’ve found myself wondering what the hell was going on more than once, only to find that my sources were outdated)
Apart from that, I guess there is room for some further polishing/refactoring anyway (it’s become slightly uglier than I’d like over time).
In particular, it would help to improve the command line and let it accept e.g. hex values.
3. Fonts. We tend to have ugly fallback fonts. Find why and fix it. Would we perhaps be interested in selectively applying bilinear on bitmapped fonts only?
- Also, results from profiling show three areas of interest performance wise:
- FMVs are sometimes slower and uglier than they should be.
Software scaling ain’t terribly efficient. - The particle engine can benefit from some optimization, perhaps akin to what’s been done with ui_tiled image to lessen the load on the ticket system.
It is heavy and it plays an integral role in the speed of J.u.l.i.a. - Fonts, again, are sometimes at least as heavy as their ui_tiled backgrounds.
Perhaps caching text as well, as has been done for the backgrounds, to reduce load?
Apart from this, there are a few TODO’s lingering all over the code which can be taken care of with a quick fix, most of them pre-existing, some of them new, just grep it.