SpritesMind.Net

I've released a new version of my Gen/MD emulator. Big change this time is a new UI using the Nuklear toolkit. Unlike the old UI, you can actually change almost all config options through the UI rather than editing the config file.

Of interest to developers are some improvements to the VDP debug views. They are now shown in separate windows rather than replacing the main output and there's a new one for viewing a VDP background plane (A/B/Window).

You can find the full changelog and download links here

v0.6.0 ended up being kind of buggy due to an abbreviated QA cycle. v0.6.1 fixes a number of issues and is now available here

Hello,

Thanks a lot for this release! The addition of a proper options menu is great!
There's only one little issue for me with it: checkboxes look like they mean the opposite they should, ie. a black checkbox means "enabled", which seems odd.

Very nice release thanks ! I would really like to make it my choice emulator for my dev testing but some limitations on the windows version preventing me to do so.
The UI is much better now even if there is some issues remaining, another one if from the file selection menu: you can't change drive (i.e. browse D: instead of C:, obviously i'm speaking about the windows version) while it is possible with the previous menu.

gligli wrote: ↑

Sat Jan 05, 2019 6:16 am

There's only one little issue for me with it: checkboxes look like they mean the opposite they should, ie. a black checkbox means "enabled", which seems odd.

Yeah, the default checkbox style is one of my biggest beefs with Nuklear. I'll have to see if there are any easy tweaks that can make it a bit more obvious.

Stef wrote: ↑

Mon Jan 07, 2019 9:41 am

Very nice release thanks ! I would really like to make it my choice emulator for my dev testing but some limitations on the windows version preventing me to do so.
The UI is much better now even if there is some issues remaining, another one if from the file selection menu: you can't change drive (i.e. browse D: instead of C:, obviously i'm speaking about the windows version) while it is possible with the previous menu.

Ah yes, that was an oversight in the 0.6.0 release. It should be fixed in the 0.6.1 release. Any other limitations in the way?

No, the others i was speaking were the ones mentioned just earlier (checkboxes)

oooh. Up to date Genesis emulator for 64 bit Linux. Nice!!

Installing in Linux is kind of awkward, since it is not looking in standard locations for config files. /etc/, ~ (according to README). Also, just putting these files in the indicated locations (assuming default.cfg), does not allow blastem to run, so there must be other dependencies. Error of 'Failed to load Rom DB'

Oh, I see it created a config file at ~/.config/blastem/blastem.cfg. I still get the ROM db error though.

kubilus1 wrote: ↑

Mon Jan 14, 2019 12:32 am

Installing in Linux is kind of awkward, since it is not looking in standard locations for config files. /etc/, ~ (according to README).

The location of blastem.cfg is standard for a per-user config file. It is true that my tarball is a self-contained package rather than something that's designed to be put into the standard filesystem hierarchy though. Allowing it to be built such that it assumes the standard filesystem hierarchy is on my TODO list so that it is easier to make proper distro-specific packages, but I haven't gotten to it yet.

kubilus1 wrote: ↑

Mon Jan 14, 2019 12:32 am

Error of 'Failed to load Rom DB'

rom.db must be in the same directory as the blastem executable. If you want to stick something in a directory that is already in your path, I recommend creating a symlink rather than moving the executable itself. This way you don't need to junk up one of the standard directories with things like rom.db, termhelper and gamecontrollerdb.txt. So for instance, you might do something like extract the tarball in /opt and then create a symlink from /usr/local/bin/blastem (or perhaps /usr/local/games/blastem) to /opt/blastem64-0.6.1/blastem. The alternative is to not mess with symlinks at all and just add the blastem directory to your PATH in your .bashrc (or whatever the appropriate script is for your shell).

And of course, the above all assumes that you want blastem in your path for easy launching from the command line. If you just want to launch it from your desktop environment, you can just create an appropriate .desktop file with the absolute path in the Exec entry

Sounds good, I'll give it a go later on. BTW, love the debugging modes on this. This should be very handy!

kubilus1 wrote: ↑

Wed Jan 16, 2019 7:12 pm

Sounds good, I'll give it a go later on. BTW, love the debugging modes on this. This should be very handy!

Glad you like them. I have pushed some changes to allow for building a more standard filesystem hierarchy friendly binary. If you want to try it out, grab tip from the repo and build with the following command (do a make clean first if you had previously built in the same directory) HOST_ZLIB=1 tells it to use the system's zlib rather than the bundled one, CONFIG_PATH specifies the directory where BlastEm will look for default.cfg ($HOME/.config/blastem/blastem.cfg will still be preferred if present) and DATA_PATH specifies where it will look for things like rom.db, gamecontrollerdb.txt and shaders.

I have not written an "install" target for the makefile though, so you'll be on your own when it comes to copying files to the correct target locations.

Cool. Yeah, that definitely finds the rom.db. It's probably how I built the project, but it doesn't actually show anything when I run a rom. I get a blank screen and the following error:

"Failed to open shader file default.v.glsl for reading"

kubilus1 wrote: ↑

Sat Jan 26, 2019 4:16 pm

Cool. Yeah, that definitely finds the rom.db. It's probably how I built the project, but it doesn't actually show anything when I run a rom. I get a blank screen and the following error:

"Failed to open shader file default.v.glsl for reading"

Shaders are expected to be in the "sharers" subdirectory of whatever you define DATA_PATH as. If you just toss them in loose, they will not be found.

Awesome, got it working.