Wii Build: Test reports


I’m using 0.5.1 Wii (not a nightly) and The Looking Glass is mostly playable now :slight_smile:

There’s one place where a crash always happens, something about being unable to create image and then it shows the image’s dimensions and closes EasyRPG. This only happens on Wii, not PC.

I have seen this “can’t create image” error happen in at least one more game but Looking Glass is the only one where the error was repeatable.

Here’s the save, just go up to trigger it:
Save03.lsd (9.4 KB)

I noticed that when the location switches and that message comes up, the new area is pink. Which is really weird because both the area you’re leaving and the area you’re going to are supposed to be blue. Maybe that’s a clue to what’s going wrong?

There’s a strange situation with Hell Diary on Wii. It has a more subtle menu cursor than most games, both in how thin it is and how it’s not that much bright. It is perfectly visible on PC though.

But on a CRT tv on Wii, that thing is practically invisible. Literally, the menu cursor can’t be seen from more than a foot away from the tv and even then it’s just barely perceptible. It’s just so thin and dark it blends with the pitch black around it.

So it’s not a bug, technically. But it makes it impossible to tell where you are on the menu.

I don’t know how this could be fixed, really. I know you guys don’t like game specific hacks (and for good reason).


Hello, thanks for the bug reports!
Unfortunately we cannot really solve the problem in The Looking Glass currently.
The Wii has roughly 80MB available for homebrew applications. We do not really try to keep our memory footprint low, because PCs have enough of RAM available nowadays. For example we keep images and sound effects in a cache for faster access. You can see here the memory used when using your savegame on my PC.

71.11^                                                                 #      
     |                                                       @@::::::::#      
     |                                                       @ :: :::::#      
     |                                                       @ :: :::::#      
     |                                                       @ :: :::::#      
     |                                                       @ :: :::::#      
     |                                                       @ :: :::::#      
     |                                                       @ :: :::::#      
     |                                                       @ :: :::::#      
     |                                                      @@ :: :::::#      
     |                                                 :::::@@ :: :::::#      
     |                                                 :::: @@ :: :::::#      
     |                                                 :::: @@ :: :::::#      
     |                                                @:::: @@ :: :::::#      
     |                                                @:::: @@ :: :::::#      
     |                                                @:::: @@ :: :::::#      
     |                          @                  :::@:::: @@ :: :::::#      
     |           ::::::@@@@:@:@@@::@:::::::::::::::: :@:::: @@ :: :::::#::::::
     |   ::::::::: : ::@ @ :@:@ @: @: :: :: ::::: :: :@:::: @@ :: :::::#::::::
     |   : : ::::: : ::@ @ :@:@ @: @: :: :: ::::: :: :@:::: @@ :: :::::#::::::
   0 +----------------------------------------------------------------------->Gi
     0                                                                   7.721
         ↑            ↑ starting game  ↑                 ↑          ↑   ↑
         +- initializing Player        +- loading scene  |          |   |
                                      loading first map -+          |   |
                                            teleport to second map -+   |
                                                  reset to title scene -+

After teleporting to the map (going up) in your savegame, we consume 71 MB, plus 7 MB executable, plus a bit of OS resources. Which means, we are out of memory on the Wii.

About the barely visible cursor in Hell Diary: This needs a test on hardware to see if it is really different than on PC. However, this might be a quirk due to using different color/brightness settings on the CRT.
As you said, we will not implement such game specific hacks, because the cursor was intended to be barely visible in the first place.
In the meanwhile, I have changed the menu color to be brighter in this file: menu.zip (1,3 KB), just replace System/system4.png with it.


I didn’t know Wii homebrew was limited to 80mb for ram. I mean it’s no secret Wii is kind of underpowered but wow that’s low. I’m surprised (but glad) this hasn’t been a problem in more games.

That makes a huge difference. Now the menu cursor is very visible. Thanks for the fix :slight_smile:

Now that I know how to get around the problem if I ever see it again, should I still report if I see any more games with such a hard to see cursor on tv? Or is that information kind of useless to you guys as it doesn’t really seem to be an engine bug, but a tv quirk?


Good news: I found a way to reduce memory usage. It won’t land in the Player before August (Vacation time and too risky to add without testing) but here are two screenshots for comparing the memory usage before and after. The first one is the one carstene1ns pasted, just a bit more graphical :D.



As you can see for “before” the heap for map loading increased by 23 MB and by 34 MB and for the “after” increased by 2 MB and 7 MB. I achived this by not creating images for the sprites (events) that are out-of-bounds of the viewport. Disadvantage: This will cause micro-stutters when the sprite appears on the screen but I think this is an acceptable trade-off… vs. not playable :smiley:

Ignore the absolute memory usage in the graph, not comparable because Windows manages memory different. But as you can see in the table 50 MB are saved. :slight_smile:


Wow that’s a massive improvement. Yeah and micro stutters would be a small price for no game ever running into that problem again.

The only thing I’m wondering, would that mean all games would get micro stutter? Or would there be some kind of option to turn on/off the not-on-screen sprite loading per game (so games that don’t need it aren’t affected)?


Well I don’t know if it would even have noticable stutter because e.g. when an event switches to a new page and a by-now not used CharSet is loaded the same already happens. (for the case where the new eventpage sprite is off-screen this would even improve the performance because the load is skipped).

When a CharSet goes off-screen and no other event has that CharSet on-screen (The graphics are shared with a reference count, so one CharSet file only requires memory once) the CharSet is still not destroyed but kept in our Cache. The actual destruction happens when it is unused for 5 seconds.

I prepared a Wii build for you for testing:
wii-test.zip (2.9 MB)

Tell me if you notice any performance problems in games that worked before without running out-of-memory.


Tried that build out. I’m afraid to say that there’s something very, very wrong with that build. Several in-game graphics (mostly events it seems) get seriously messed up and repeated, dunno how to describe it, I’ll let the pics do the job (pics are from End Roll and Ib respectively, but this phenomenon occurs no matter which game it is):

The truth is that it’s pretty much random choice when it comes to graphics displaying incorrectly, but there are scenes where it’s surely a mess. In any case, there’s something that clearly went wrong.
If you expected this and you just wonder about the performance though, the truth is that I couldn’t really see a very big improvement in overall performance. Guess I ignored it a bit due to all the randomness on the screen, but although I think that several games now reach 60 fps where they previously couldn’t (wild guess, dont’t take it seriously), most of things that I remember causing performance issues are still there, like saving, battle animations, some transitions and brief changes on the screen plus event interaction over it (dialogues when screen is black for some reason, some scenes involving screen tones, etc.)

nvm the PC version issue I mentioned here if you happened to read it, I tried the current continuous build and it’s fixed


This isn’t a performance improvement (and when only a very minor side-effect). It is about saving memory :slight_smile:

I messed up the test build. This one should look correct: wii-test.zip (2.9 MB)


What should I exactly notice compared to previous versions?


Clearly things aren’t going as you planned them…

The whole sprite sheet is drawn on the screen per object, actually magnifying the previous issue… may I ask what is going on?


Uhm, I will take a break before trying this again :frowning:

Almost no performance difference but that games that reported “Couldnt create Image” errors before should work now.

Edit. This time I tested properly…

wii-test.zip (2.9 MB)


Tested a little. I’m glad to inform that this issue seems not to happen anymore. I’m mostly testing with Wadanohara and the Great Blue Sea as this was one of those games that had the “Couldn’t create image” crashes frequently. I will keep on testing sometime later as I don’t really have too much time left right now. Will try to get the game done completely as well.
Gotta mention though that while it didn’t occur in the tests I did with the latest build, it actually occured with the first broken build aside from all the madness… better not to let the guard down