User consultation: - Update "wait message" - art and/or functionality

[kaisersozeh]

A wait animation functionally shows the user that the software has started running, processes have not frozen. In the current solution, the memory available to produce whole frame animations has not provided an satisfactory result for contemporary large screen TVs

-Short term - reduce image 25% - move to top right quadrant - stay within borders of 4:3 screen, appears as lateral distortion of 75% on a 4:3 - correct in 16:9 -Open a user submitted animation competition - open entries to a vote - commit to using it.

Solutions offered in the user consultation might include:- A (variety of) small(er), monochromatic/low colour animation(s) in the top-right of the screen, accompanying larger, central, static image(s) Context information about what wiiflow is doing - in a user readable format of higher graphical quality than white text on a black field A time since process started graphic - bar fill, clock etc. A percentage of processes completed graphic- bar fill clock etc. An arbitrary indicator that moves across the screen, left to right A WiiFlow user Tip taken from the help file, or selected from a tips file Possibly interspersed with a variety of humorous or pithy quips or quotes.

[einsteinx2]

Actually I don't buy the memory issue. I think we definitely have more to work with. I know when the interface fully loads I had at least 8MB left, maybe more I can't remember. And that was with all cover textures loaded and displayed.

Maybe it was a problem in the past, but we should experiment with high res animations. It's just a set of png files that get animated in code rather than a video, so they can be easily swapped out. And we can make sure to use tools like pngcrush to reduce memory usage.

[kaisersozeh]

People familiar with the code seem to really expound the memory issues generally - I defer to greater knowledge - More frames of greater resolution with reducedpixel size sounds genuinely exciting - the animation has always let the interface down - it should either be as breathtaking as the rest of it - or as subtle as possible

[einsteinx2]

It's very possible that the memory usage is higher during the loading process and then a bunch of memory is freed at the end. I'll have to log memory during boot.

However before this warrants time, it would be great to have a high resolution loading animation to try and use. I'm no artist so that's not really something I can do. I really like the current one, I just wish it was higher color and resolution.

@kaisersozeh do you know anyone that could recreate it in high quality? Or create a new one that looks really nice? Also does it change when switching themes or is it baked in? I haven't checked.

[kaisersozeh]

It's baked in - pngs in the resources\theme_pngs - 8 frames@200x100 pixels. The limit in the documentation I've found is 13kb IN TOTAL - the jpg's used until recently met this specification - The png's in use now are somewhat higher quality, larger filesize, but still 8 frames of 200x100 I'm guessing, but I'd say the pngs Fledge is using are the best he has, there are a few other animations knocking about but they're designed to the same spec. I'd be happy to do something bigger, more frames, based heavily or loosely on the current artwork, or something entirely different What kind of memory allocation are we talking about? @einsteinx2 Pixels are distorted on a 16:9 ratio screen and I think a better result might be had by reducing the display size

[einsteinx2]

"The limit in the documentation I've found is 13kb IN TOTAL"

This makes no sense to me... There's waaaaay more ram available than that... I need to better understand why this restriction is in place.

"What kind of memory allocation are we talking about? @einsteinx2"

I meant that once the interface completely loads, if you turn on the option to show free memory, there's about 8MB left. So clearly there should be more than enough RAM for a high quality animation. However, it's possible that while the interface is actually loading, the free RAM is much lower.

However, given that the limitation is supposedly 13 KB, there's no way it would be that close to 0 free RAM. Just doesn't make any sense to me. We should be able to use a MB easy for the animation.

[kaisersozeh]

I'll redo the Qiiflow one as a working example - the screen has a very large pixel, and it's distorted 4:3 to 16:9 - that needs to be accounted for in the art unless there's a code fix. It's in gui\video.cpp slightly out dated info https://gbatemp.net/threads/changing-wiiflow-boot-animation.330880/page-2

[einsteinx2]

It's probably do-able to detect the aspect ratio, but I'll have to check.

[kaisersozeh]

There's a few references to 640 x 480 in source/gui/video.cpp - so that's baked in, not a variable - i'm not sure if there's a single parameter defining EITHER 4;3 OR 16;9 .
Could these numbers be changed, increased significantly - that's a large pixel size on a flat screen?

[einsteinx2]

The Wii can never output higher than 480P, though it can do widescreen. Not sure how it handles widescreen though

[kaisersozeh]

@einsteinx2 I'm a bit fuzzy on the implications of this - we don't need a full screen - is it possible to, for example, display a 640x480 image in some portion of the screen-"windowed"- and still have every pixel of the image present?

[einsteinx2]

Should be, yeah

[kaisersozeh]

Cool. Just reduce the depiction of the image until the pixel size becomes bearable. Presumably this will allow for a corrective distortion 4:3 to 16:9 - is this possible via an edit to video.cpp - or are we going a little deeper?

[einsteinx2]

To be honest, I haven't looked at the code yet so I have no idea how it currently works exactly, especially with standard vs widescreen. For a first test, maybe try creating images with the same aspect ratio just larger. For example, if the images as you said are 200x100, I assume it's just centering it. You could try making some at 400x200 or 800x400 and see how they look.

Also, just a thought, but assuming it is just centering the 200x100px images inside the screen (hence it works fine on standard or widescreen), then I think the main reason for the low quality is the low color depth and dithering. So maybe try making the same 200x100px size first but just use much higher quality, larger PNG files. Then if that works, try larger sizes. There may need to be code changes to accomodate different sizes, I don't know yet, so trying out higher quality 200x100 images seems like a good first test.

[kaisersozeh]

I don't quite understand what you mean by a higher quality 200x100 image - that's the total number of discrete pixels - we can change the size of the pixels but 200x100 is always 200x100. I'm not quite compiling yet - had to lark about with OS installs all day - hopefully will be geared up by the end of play tomorrow.

[kaisersozeh]

lost a couple of days to installing windows. @einsteinx2 - had a chance to look at the code pertaining to this? I brought it up on wiiflow lite too

[einsteinx2]

Sorry have 0 time for anything Wii related at the moment, have a ton of work. Won't be able to do anything til next week.

But what I meant about higher quality 200x100 is that it appears that the quality issue is not so much the resolution, since it seems to be centered in the screen, but the color depth and dithering. For example the images look very compressed (gradients aren't smooth, total colors seems low, looks kind of fuzzy). I think those same 200x100 images could be muuuuch sharper if they were larger in file size. That's what I'm talking about. To me they look like someone made high quality images and then crushed down the file sizes in every way possible, making them look crappy. I wish we had the originals to compare.

[kaisersozeh]

From Fledge - any use to you? when the wii is set to widescreen both usb loader gx and wiiflow read the wiis config file to see its set on and then all they do is multiply the width of an image by .80 or .75 to squish the width so when your tv stretches it it doesn't display stretched or they use a gu scaling option to change the scale X size when drawing the image for display.

[einsteinx2]

Interesting approach. Makes sense. Looks like essentially everything is created for fullscreen and then if widescreen is used, which would stretch everything out, the software just squishes it by the same amount so it ends up looking correct.

The takeaway is that you can just design things for fullscreen and not worry about widescreen it seems like.

[kaisersozeh]

Kick arse idea for transition animation between sourceflow and console coverflow - When a 'flow opens, the covers emerge from an origin point at the center of the screen - leaving the 'flow, the covers converge on the same point. Instead-

• Upon selecting a source, the covers in the sourceflow converge on a point "further away" and below the edge of the screen.
• The boot animation shows an array of abstract covers enter from the bottom of the screen, curve inwards to the center,
• The animation loops around the center - checking if the source has loaded before commencing the next loop
• when the source has loaded, the covers then expand outwards again as they reach towards the top of the screen, disappearing as they cross the edge.
• The selected source, now loaded, emerges from an origin point further away and above the screen - the covers swooping in, downwards, and taking position in the coverflow.

On transitioning back - the animation could be inversed horizontally and/or reflected vertically or the frames played in the opposite direction - and this can be randomised as long as the direction matches the origin point of the disappearing coverflow - 8 (slightly) different animations for the memory of one. Could even have a selection of loops around the center to randomly select from. If the animation uses transparencies - it may be possible to use the background png currently in use - hugely improving the illusion - otherwise it may be preferable to fade that to black as the coverflow disappears. Problems

• According to fledge, the animation is fixed to a 100x200 box running horizontally across the screen
• this wouldn't be any use for the loading animation, so we'd need two animations...

But it would ROCK though, right?

35