Scrolling input display, continued

The recent debut of MAME-rr has renewed some interest in my scrolling input viewer. (And by some interest I guess I mean my interest.) It's a Lua script that shows a Training Mode-style readout of the keys being pressed by the player.

http://code.google.com/p/fbarr/downloads/list

Getting it to work with MAME was not hard. I also added support for Lua hotkeys and made it so when you load a state, the display returns to how it was when the state was saved.

Framedump mode doesn't work with MAME-rr at the moment because gui.gdscreenshot() isn't implemented, but that can be fixed eventually. Regular F12 screenshots work fine though. And with the new option to include Lua drawings in captures, framedump mode doesn't even need to be used with FBA-rr 0.05.01.

One problem with the last version was that the square icons overlaid on the wide CPS-1/CPS-2/CPS-3 screen become distorted and skinny when the video is scaled to 4:3. I thought about preparing a separate, wider set of icons for use with these games but then had a better idea: Just use one set of icons and have them dynamically rescaled to match the screen shape.

The existing 16x16 icons looked pretty bad when stretched wider, so I started over with 32x32 icons. I cribbed the punch and kick symbols from strategywiki and added color as needed. The arrows and start button were not hard to make again from scratch.

When scaling mode is activated, it checks the screen dimensions and computes a new width for the icons:

scaled_width = icon_size * emu.screenwidth()/emu.screenheight() / (4/3)

This effect can be toggled with a hotkey. It usually looks better to leave them square for still shots, while for videos you'll want to prestretch them. For screenshots you might also want the icons bigger, and for that I added a resize hotkey in v004. It's all up to the user.

Native res with unstretched icons

Native res with prestretched icons

After rescaling to 4:3

I also merged the icons into a single image file for a less cluttered installation. It was these two design changes, image scaling and a single source file, in conjunction with some annoyances in the Lua gd library, that caused me a some trouble.

You cannot directly use a small piece of the large source image, because there doesn't seem to be any way to change the size of an image or only use part of it. (I tried setClip. It didn't work.) Instead you have to create a new image object with the desired size. To create an image from scratch you can use gd.create or gd.createTrueColor. But the resulting rectangles always have an opaque background. When you superimpose the icons, the corners that are supposed to be transparent show up opaque, and there's no way to force transparency. (I tried colorTransparent. It didn't work.)

Another way to create an image is to copy an existing file with gd.createFromPng. If the source file is transparent, the gd image will be also. This is the purpose of the seemingly useless blank png file included in the package. The script starts with that, then copies the appropriate section of the source image file onto it with gd.copyResampled.

Here is where the scaling became problematic. The base (blank) image cannot be smaller than the copied section, or else the excess will be cut off. This results in icons missing their right sides. On the other hand, the base image cannot be larger than the copied section, or else the uncovered part will show up opaquely, even though it's supposed to be transparent. I could provide multiple blanks of various sizes, but since I don't know (or I'm not supposed to know) how much scaling will be required, I wouldn't know what sizes to include.

My solution was to use a single base image but make it excessively wide, and to add a transparent buffer area to the right of the icons in the source image. When the icons are copied to the blank template, a portion of this blank buffer is also copied to completely cover up the base image. The amount of buffer needed depends inversely on the degree of stretching. (This is why the icons are stacked vertically with space on the right.)

Comments

[error1]

the original sf4 icons I ripped for you where 21x22, you resized them to 16x16 right?
http://img31.imageshack.us/img31/356/compersion.png
I think the old ones look much better, at lest when scaled down. It makes sense to me that scaling something up would look better then scaling something down.
Maybe the best would be to make some really clean 16x16 icons from scratch

[dammit]

The reason it looks funny is because the ones on the left are stretched and in a bigger size. If you set them the same size and turn off stretching they look about the same:
http://a.imageshack.us/img821/5804/sfanewcomp.png

Scaling up is definitely sketchier than scaling down because you have to interpolate information that isn't there. You can shrink 2x to 1x and get something just as good as if you started with 1x. The opposite is not true.

However, I did a hasty job of coloring and testing the new icons. (I blame GIMP.) It might be good to redo them in a way that looks a little better when shrunk.

[error1]

when you scale up all you need to to is make the pixels bigger, so you can make an image 100x bigger without any quality loss, just really big pixels.
here I did a re-size of your original 16x16 and 32x32 to all the different sizes
you can see that increasing the size to 20x20 doesn't look very good, but above that it looks the same, but there is a large quality loss decreasing the size just a little
http://img814.imageshack.us/img814/5723/resizeing.png

[dammit]

That's kind of subjective. I'd prefer to minimize the pixelation myself.

I'll just include both sizes in the next version so the user can switch by changing a line.