[Tutorial] Installing MVEM (Milton-Bradley Microvision emulation) on RPi 3

NowArrivingHere

Yeah, I added a make clean, used it, and then tried to compile again. Same errors. Looking over the compiler output, I did find this warning that did not show up during the Build 14 compilation. Not sure if it is relevant. I already included this in the Pastebin from earlier.

hardware.c: In function ‘IF_Initialise’:
hardware.c:85:17: warning: implicit declaration of function ‘IF_ToggleFullscreen’ [-Wimplicit-function-declaration]
     if (f == 1) IF_ToggleFullscreen();
                 ^~~~~~~~~~~~~~~~~~~
hardware.c: At top level:
hardware.c:155:6: warning: conflicting types for ‘IF_ToggleFullscreen’
 void IF_ToggleFullscreen(SDL_Window* Window) {
      ^~~~~~~~~~~~~~~~~~~
hardware.c:85:17: note: previous implicit declaration of ‘IF_ToggleFullscreen’ was here
     if (f == 1) IF_ToggleFullscreen();
                 ^~~~~~~~~~~~~~~~~~~

I did find this.

It discusses MinGW and errors with SDL libraries. Not sure if relevant
https://stackoverflow.com/questions/34848279/g-windows-linker-undefined-reference-to-with-sdl2#34861276

rkoster

Yeah, I wasn't good about the warnings, I admit. Once it was working, I stopped there. :) Those shouldn't affect it compiling (it compiles with those same warnings here, I just checked) unless you've got the compiler set to be strict about it. Adding a declaration to the header file would fix IF_ToggleFullscreen, but iirc adding it made it barf for other reasons... so I lived with the warning. You can definitely fix the warning in IF_Initialise by changing that line to if (f == 1) IF_ToggleFullscreen(window); -- it's just missing the arg.

None of this addresses the actual issue though, which is that your environment isn't finding SDL.h. That's what the linking errors look like to me. Did you try giving it an absolute path?

mitu

@nowarrivinghere The Makefile is missing the linking libraries, just uncomment the line with the LIBS in the Makefile and edit it so it's like:

LIBS    = -lSDL2

then try running make again.

NowArrivingHere

@mitu @rkoster

Wow. I don't know how I missed that, but there it is. I can confirm that it compiles now. However, there appears to be an issue with the *_snap.bmp files used for the controller layout. The keyhints.bmp, knob.bmp and the various game screen overlay .bmp files are showing up correctly on screen, but the various *_snap.bmp files are not showing up. Note that I am testing with 1280x720x1, as this is my TV setup. I'm thinking this may be an error on my end. Going to continue investigating when my Pi is through with updates.

rkoster

IIRC, they're huge -- 1175x3074. You might want to just try resizing them, they may be too large for the Pi.

NowArrivingHere

@rkoster

Okay, here's the current status. I have run the _snap.bmp collection through GIMP to downsize them.
Original dimension: 1175x3074
New Dimension: 587x1537
Original size: 14,110 KB
New size: 2,648 KB

Now, all of the games can be made to work in Build 15 in Retropie. However, there are two things I want to note.

First, GIMP interpreted the clear area around the _snap.bmp images as white space, so these images now have a white border around them. I haven't found a way online to fix this.

Second, while the image resizing solved a real problem with the images not displaying properly, there is a separate issue that I believe is either a RetroPie, Emulation Station, or SDL issue. I have seen something similar before when running an external version of SDLmame. If I boot my Raspberry Pi into Emulation Station and pick any Microvision game, it will load. However, the only .bmp that will load is the overlay for the screen. The knob, key hints and controller layout will be missing. This is true for all games. However, if I exit Emulation Station, load any single game in MVEM directly, exit MVEM, reopen Emulation Station and try to pick a Microvision game again, all of the bitmap files will load properly for all games.

Now, I should confirm that the issue with downsizing the *_snap.bmp files was a separate problem, as those 14MB files would not load in RetroPie even if I had previously loaded MVEM on its own. In fact, those wouldn't even load in MVEM when MVEM was run on its own.

Again, I don't think this is a problem with your code. I think this is just a compatibility issue with RetroPie and external SDL-based emulation in general. It is weird that the overlay for the game screen is the only one that loads correctly after directly booting into Emulation Station. This makes me wonder if its a separate image size issue. Both keyhints.bmp and the downsized _snap.bmp images are larger than the game screens. However, the knob is only 255KB and fails to load while the screens themselves are 1,356KB and load properly.

This reminds me of a problem I had loading an external version of SDLmame in which if I booted directly to Emulation Station and tried to load a game it would crash. However, if I exited Emulation Station, loaded SDLmame and exited, I would be able to reload emulation station and select the game without crashing.

I'm going to try to get a section of the tutorial for Build 15 available soon, as well as some pictures of what this looks like on my TV.

NowArrivingHere

Build 14 (Bomber)

Build 15 (Bomber)

Image Loading Error Build 15 (Block Buster)
0_1504346441331_image_loading_issue_block_buster_build_15.jpg

rkoster

It could very easily be total memory. If the knob is last to load and the video memory is all used up by prior loading, it could fail too. And I am pretty sure the knob is last, and the overlay is first. Try downsizing all images? Even with a 1080 screen, you can probably go down to 540 pixels on the vertical.

NowArrivingHere

@rkoster
Unfortunately, I can't really test that right now. I still have that problem where downsized images replace the transparent parts with white. However, the screen overlays appear to depend on transparent sections to show the actual game area. GIMP fails because it can't retrieve an Alpha channel from your .bmp images, and Paint fails because it is Paint. I don't have proper Photoshop, and my attempts to google ways to downsize these images while maintaining transparency are drawing a blank.

rkoster

I just uploaded snapreduced.zip to http://www.raphkoster.com/gaming/microvision/snapreduced.zip

This has all the snaps and the keyhints resized to 720px tall, with alpha preserved. Give those a try... if it's not enough, I can do it again, with a smaller size still, and also the overlays (though they are only like 540px tall).

rkoster

Oh, and FYI, GIMP can in fact do BMP with alpha. It needs to be set up as a channel called Alpha, and saved in one of the BMP formats that allows it. These ones are using R8.

All these images should have it, but by default, the alpha channel is usually not visible. In Photoshop at least you have to open the image, go to Channels, make it visible, then save.

NowArrivingHere

@rkoster

Okay, I just tried your reduced snaps. It still isn't loading properly. If this is caused by the combined size of all the images being loaded together, it might be a good idea to downsize the actual screen overlays. These are 1.4MB each and are now the largest images loaded when a game is booted, as the snaps are 774KB apiece, the keyhints.bmp is 774KB, and the knob.bmp is 255KB

Also, I'm going to add a screenshot of one of your images loaded into GIMP. I'm not an expert in GIMP, but I am looking at the Channels panel, and I only see a Red, Green, and Blue. I know the images must have an alpha channel due to the transparency, but my GIMP is not recognizing it as such and certaintly not exporting it as such. It must be some sort of import error on my end.

rkoster

I will reduce everything to 512 then. Some video chips automatically go to powers of 2 for texture sizes, this should ensure that it stays at 512x512. These others would have gone to 1024x1024. I'll do both overlays and snaps. Give me about half an hour :)

rkoster

OK, try snap512.zip. I took extra time and fixed the rounded corners which weren't alpha before (hard to see, but it was bugging me!).

If this doesn't do it, I really don't know what else to suggest. 3 512x512 textures plus the knob at 256 is not very much, and stuff will definitely get blurry if I have to go to 256 for the larger items.

NowArrivingHere

@rkoster

Okay, here is the situation. It still doesn't work, but don't bother reducing the image size anymore. It will not help. I recommend you just go with either the snap512.zip or snapreduced.zip for any Raspberry Pi distributions. The original ~14MB _snap.bmp caused a different issue on the Raspberry Pi where even standalone MVEM would not load the images. As far as the issue with having to quit emulation station, run MVEM standalone, and reload emulation station to have the images show up in RetroPie, I think I have conclusively shown that we cannot fix it. It is either a bug in SDL or a bug in how EmulationStation/RetroPie handles SDL-based external emulators.

I decided to run a test by replacing the Baseball.bmp, Baseball_snap.bmp, knob.bmp, and keyhints.bmp with solid color bitmap images of the same dimensions as the snap512.zip .bmp files. Here are the file size comparisons

Baseball.bmp
Old: 1,011 KB
New: 129 KB

Baseball_snap.bmp
Old: 393 KB
New: 51 KB

knob.bmp
Old: 255 KB
New: 32 KB

keyhints.bmp
Old: 393 KB
New: 51 KB

It had the same problem as before with needing to quit ES, run MVEM, and reload ES to make everything show up

And just to be extra thorough, I took my solid color bitmaps and halved their dimensions to the 256 dimensions

Baseball.bmp
Old: 1,011 KB
New: 33 KB

Baseball_snap.bmp
Old: 393 KB
New: 14 KB

knob.bmp
Old: 255 KB
New: 9 KB

keyhints.bmp
Old: 393 KB
New: 14 KB

It had the same problem again.

So I think we can safely say that this is not a problem that we can fix. After all, when running MVEM outside of RetroPie, the problem does not occur. It might not even be an issue to people using other front-ends. Having to quit ES, run MVEM once separately, and reload ES to allow MVEM to load properly inside RetroPie is inconvenient, but it isn't the end of the world. I am interested to hear from other users who install this emulator on their RetroPie setups as to whether this happens to them as well. It may be that there is some sort of missing SDL setting that is applied to emulators featured in the RetroPie script that MVEM Build 15 either can't use or isn't using.

Thank you for working with me on this for so long. I still consider Build 15 an improvement over running Build 14 in RetroPie, in spite of this issue. Hopefully, at some point, the image loading issue can be resolved, but that may require MVEM Build 15 being added to the official RetroPie script.

rkoster

Thanks for running the experiments!

I'll see if I can make some time to make a nicer distribution with the Makefile set up for Pi, with just the binary, just the assets, etc, in separate zips, that way we can link it here.