blending of wood and/or gold texture on some resolutions(mobile,
tablets, etc) draws line which can be distracting. The backdrop is now
full size of PSP resolution (480x272, 2x res can be loaded like 960x544)
- attempt at reducing loading times on the PSP: I merged a few graphics files together, removed some unused calls from the initialization functions, and moved some other ones to have a more lazy approach. The PSP version remains fairly slow in some parts (especially loading, but also entering the shop, or starting a new game), so I will try to reduce file access as much as possible in the days to come. Not a release blocker IMO though, but I4d sure love if it were faster.
- uppercased "Track1.mp3" to be in line with the actual filename. Most likely this had been broken forever on case-sensitive OSes
- I removed costly calls from the textscroller. I believe it wasn't very useful in its previous state. Now it's only "advertising" for unlockable stuff, which I think is ok (and allows to refresh it every time the menu is loaded)
- As a counterpart, added a "% complete" progress bar in the menu, something I wanted to add a while ago.
- rewrote some code dealing with text formatting for a card when rendering in text mode. I could swear my code has been reverted. If somebody has good reason to believe we should re-process the string formatting on every frame, please let me now. I believe my change can help rendering speed of text mode a lot.
- counters change to vector instead of array
This helps a lot in the deck selection menus (duel and deck editor).
That, added to my previous fix, fixes issue 693 for me.
In general, we should try to avoid 512x512 32bits textures on the PSP. That happens with a 480x272 png image. One solution is to convert the file to a jpeg, and load it in 551 mode whenever possible. Another solution is what I did: use a 450x255 image instead. The best is of course to cumulate both, which divides the size in Ram by 4 on the PSP.
I'm ok with distributing lower res graphics on the psp, and higher res on other platforms, if that helps. Main culprits are 480x272 images (when there's too many of them)
* changed how the avatar images are assigned since how they were before was incorrect. They are now assigned upon instantiation of the meta file. Not when the stats are calculated.
* Added new image for "Evil Twin". This is a horizontally flipped image of the original player avatar with a red background. Please feel free to edit the image.
* removed display of avatar image on menu items in deck selection that are not deck related. (ie "Cancel", "Back to Main Menu", etc) "New Deck" also does not have an image since no deck really exists yet so no avatar.
Issue: 622
I also tweaked slightly the psp icons to center the symbols, as they were too much to the right. (Be sure to copy the updated graphics/iconspsp.png to your Res folder.)
- Added AI Decks unlock system. Please update your graphics folder, and crossing fingers that Ilya B. is still around as I don't have the correct fonts.
* Add multilingual support for utf-8.
* Use japanese as a test case (removing the old tentative support).
* A number of shortcomings affect this code.
+ Bugs :
- This splits algorithms used to determine the length of a string
and to render it in two: either the string starts with an ascii
char and the monobyte, variable-space algorithm is used, or it
does not and a multibyte but fixed-space algorithm is used.
This shortcoming also exists in the code to support chinese.
- From the above comes the biggest limitation: any string that
starts with an ascii character but include non-ascii characters
will not be rendered correctly.
- This does not and cannot support chars outside the BMP. This
probably won't matter, ever.
+ Todos, fixmes, wishlist :
- Single-width characters with diacritics are reported as
double-space chars. It doesn't matter too much at the moment, but
should be fixed in the future.
- Font support currently only includes japanese.
+ Performance and compatibility notes :
- Chinese code has not been switched to utf-8, to maintain backward
compatibility. We should switch it at some point in the future,
but ponder the right way to do it first.
- Retaining the support for chinese with a non-international
charset hurts performance (by making some methods uselessly
virtual).
* Still, this generally works and is extensible (it can be used to
implement korean, traditional chinese, etc, without any more code).
Implementing languages with diacritics needs an improvement of the
bool doubleWidthChar() method.
