Page 1 of 1

Problems compiling BlastEm from the repo

Posted: Sun Oct 12, 2014 7:38 am
by Chilly Willy
I've downloaded the latest from the repo, and it fails to compile. The first problem was too few args in the render_init() call in stateview.c. It's missing the useGL arg. Putting ",0" for it allows it to compile.

Then the next error was again in stateview... it's missing the reference to headless. However, headless is in blastem.c, which is not part of the objects that make up stateview, so it won't link. You're missing something there...

Posted: Sun Oct 12, 2014 6:16 pm
by Chilly Willy
Just a followup - I added "int headless = 0;" to stateview.c and everything compiles and links. BlastEm runs fine, but won't play Sonic 3D. It just sits at a black screen. Anywho, I was playing Sonic II - my system hovers between 58 and 60 FPS, mostly in the high 59's. Very nice speed for what it's doing! Pressing ESC in the game caused a seg fault. I'll have to try to look into that.

Re: Problems compiling BlastEm from the repo

Posted: Sun Oct 12, 2014 7:32 pm
by Mask of Destiny
Chilly Willy wrote:I've downloaded the latest from the repo, and it fails to compile. The first problem was too few args in the render_init() call in stateview.c. It's missing the useGL arg. Putting ",0" for it allows it to compile.

Then the next error was again in stateview... it's missing the reference to headless. However, headless is in blastem.c, which is not part of the objects that make up stateview, so it won't link. You're missing something there...
The default target in the Makefile includes some small programs I haven't been good at maintaining. stateview is just a simple save state viewer that I've used to diagnose VDP bugs. I really need to fix it or remove it from the default target.
Chilly Willy wrote:BlastEm runs fine, but won't play Sonic 3D.
Thanks for the report about Sonic 3D blast. I need to get around to dumping the rest of my carts and get back to work on compatibility fixes.
Chilly Willy wrote:Anywho, I was playing Sonic II - my system hovers between 58 and 60 FPS, mostly in the high 59's. Very nice speed for what it's doing!
Depending on your setup, it may actually have more headroom than that would suggest. On some systems, vsync seems to get turned on even though I don't ask for it (BlastEm is really only setup to sync to audio currently). If you're using the open source drivers, setting vblank_mode=0 in the environment before launching will force vsync off. You can then give the fast-forward feature a try to see where it runs out of headroom. Hitting 4 will set the target speed to 400% and 0 will reset. default.cfg has all the default keymappings and speed targets.

Out of curiosity, what are the specs of the system you're trying this out on?
Chilly Willy wrote:Pressing ESC in the game caused a seg fault. I'll have to try to look into that.
ESC is currently mapped to exit by default (I'd prefer exit fullscreen, but I haven't written any code to switch between fullscreen and windows at runtime yet). I've seen crash on exit with certain video drivers (certain versions of Catalyst specifically). Not 100% sure if it's a bug in BlastEm or a bug in the driver. If you're not running Catalyst, that would seem to suggest it's on my end though.

Thanks for giving BlastEm a try. Be sure to give the GDB remote debugging support a try at some point. There should be some basic instructions in the README. I did a quick test when I implemented the feature, but I don't do much C development for the Genesis so it hasn't gotten much of a workout yet.

Posted: Mon Oct 13, 2014 12:20 am
by Chilly Willy
I'm running on an AMD A6-5400K with 8GB of ram. Not a scorcher by any means, but it's damn fine for the price. :D

I do have vsync set by default - the Catalyst settings will turn it on for any program unless the program specifically asks it to be off. I prefer vsync to tearing. Given how close it ran to 60 most of the time, I figured any loss was more due to vsync and how the emulator syncs than actually being slow.

Not just ESC, but any way of quitting the emu results in a seg fault. I'll try to track it down with gdb.

I noticed that stateview was just for viewing state saves, which is why I went ahead and added the headless var set to 0. I figured that was fine for the viewer. Headless looked to be a way to run the emu without video for benchmarking purposed, which is not something you do in a state viewer. :lol:

If I run into any other roms that don't work, I'll let you don't know. I won't run them all by any means, but there's certain ones I run now and then.

Posted: Mon Oct 13, 2014 12:27 am
by Chilly Willy
A quick bt in gdb shows this
[Thread 0x7fffedd5b700 (LWP 30551) exited]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff1545114 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
(gdb) bt
#0 0x00007ffff1545114 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#1 0x00007ffff1584874 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#2 0x00007ffff1582eaa in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#3 0x00007ffff157ef6a in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#4 0x00007ffff0c67721 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#5 0x00007ffff0bee350 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#6 0x00007ffff0be939e in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#7 0x00007fffefac418a in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#8 0x00007ffff08e0cc8 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#9 0x00007ffff090b797 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#10 0x00007ffff08f4a8c in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#11 0x00007ffff08f4bb6 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#12 0x00007ffff15512fb in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#13 0x00007ffff13c4b89 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#14 0x00007fffefa7a692 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#15 0x00007fffffffcb10 in ?? ()
#16 0x00007ffff15a45d1 in ?? () from /usr/lib/fglrx/dri/fglrx_dri.so
#17 0x00007fffffffcb10 in ?? ()
#18 0x00007ffff7dea758 in _dl_fini () at dl-fini.c:257
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Definitely something to do with Catalyst.

Posted: Mon Oct 13, 2014 12:41 am
by Chilly Willy
Maybe something to do with this?

http://sourceforge.net/p/freeglut/bugs/206/

Posted: Mon Oct 13, 2014 1:13 am
by Mask of Destiny
Chilly Willy wrote:I'm running on an AMD A6-5400K with 8GB of ram. Not a scorcher by any means, but it's damn fine for the price. :D

I do have vsync set by default - the Catalyst settings will turn it on for any program unless the program specifically asks it to be off. I prefer vsync to tearing. Given how close it ran to 60 most of the time, I figured any loss was more due to vsync and how the emulator syncs than actually being slow.
An AMD A6-5400K should be plenty for BlastEm. I do a lot of the development for it on my AMD E-350 based laptop which is far wimpier.

Getting BlastEm to play nicer with vsync is on my todo list.
Chilly Willy wrote:Maybe something to do with this?
Yeah, that's probably it. There was something about them fixing a crash on exit bug in the driver release notes and I don't seem to have the problem anymore on 14.4 (which appears to report itself as 14.10 for some reason?).

Posted: Mon Oct 13, 2014 3:53 am
by Chilly Willy
I'm running Ubuntu 14.04 (using XFCE instead of Gnome), and the ATI driver is 13.35. I should check if there's a newer driver. Unfortunately, the proprietary drivers aren't part of the repo, so updates don't happen automatically.

And yes, the A6-5400K is a nice bargain-price processor. You get a decent CPU with a half-decent GPU built in. The main thing I recommend is make sure to have both ram slots populated to allow the APU to dual-fetch from ram. That almost eliminates the affects of unified ram. Running with just one ram dimm is really slow when trying to do 3D at the same time. Games like Fallout 3 and Skyrim really bog down, but are quite nice with two dimms.