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

rkoster

May I suggest starting from the source code available on my site? I released a newer version (build 15) a couple of months ago with Paul Robson's blessing... with all overlays present and better rendering. Also more front-end friendly. Haven't tried it on Pi yet though... I'll have to give it a shot.

Link not present to avoid links to roms. I haven't gotten it in github yet. :/

NowArrivingHere

@rkoster
I am now really glad that I posted this, and that you chose to respond. I had no idea that anyone was still working on MVEM. I have tried out your Build 15 on my main Windows PC and it looks great. It is definitely more user-friendly with the overlays, control listings and better view of the game screen now that the pixels are spaced out.

I found your source. If this can be compiled and run on the Pi, I will be sure to add a section to the tutorial.

NowArrivingHere

@rkoster
Okay, I have attempted to compile the current source on my Raspberry Pi3. I am running into some issues. The first one was an easy fix. I was getting errors like this one.

core11.c: In function ‘C11_LoadAndReorganise’:
core11.c:190:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
  for (int i = 0;i < 2048;i++) {
  ^
core11.c:190:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code

I was able to fix this by adding another item to CFLAGS on line 4 of the Makefile, just as the compilation note recommended.

Original:

CFLAGS  = -g -O2 -DDEBUGGABLE -D_THREAD_SAFE -I/usr/local/include/SDL2 -I/usr/X11R6/include  -I/usr/X11/include -DHAVE_OPENGL -g

New:

CFLAGS  = -std=c99 -g -O2 -DDEBUGGABLE -D_THREAD_SAFE -I/usr/local/include/SDL2 -I/usr/X11R6/include  -I/usr/X11/include -DHAVE_OPENGL -g

However, "hardware.c" is still throwing linking errors such as this one

/tmp/ccSInogM.o: In function `IF_LoadOverlay':
/home/pi/new_mvem/hardware.c:169: undefined reference to `SDL_SetHint'

Part of the issue was an include that was dependant on Windows and MINGW

#include <c:/MINGW/MINGW_DEV_LIB/INCLUDE/SDL2/SDL.h>

However, just changing it to #include <SDL.h> or #include<SDL2/SDL.h> did not seem to fix the problem. The include is referencing the correct directory, but the library is not being referenced properly. Still looking into this.

Here is a pastebin of the whole output from my most recent attempt https://pastebin.com/fiZN111j

rkoster

The older builds also used SDL2 iirc. If it worked before, what did the include look like in the older codebase? I don't think I added any new includes...

NowArrivingHere

@rkoster

Here is the original include set from "hardware.c" from build 14:

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include "hardware.h"
#include "hwinterface.h"
#include "debugsc11.h"
#include <SDL2/SDL.h>

#include "font.h"

Here is the new include set from "hardware.c" from your build 15:


#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include "hardware.h"
#include "hwinterface.h"
#include "debugsc11.h"
#include <c:/MINGW/MINGW_DEV_LIB/INCLUDE/SDL2/SDL.h>

#include "font.h"

rkoster

Right... I updated that solely to fix a path real quick and forgot to make it nice. But putting it back to how it was in build 14 isn't working? That doesn't make any sense to me, if you can compile build 14. Did you make clean?

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();
                 ^~~~~~~~~~~~~~~~~~~

NowArrivingHere

@rkoster

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 :)