Page 1 of 1

Pre-Built Emulator Packages

PostPosted: Thu Dec 18, 2014 10:41 am
by sairuk
This thread is for the discussion around pre-build emulator packages which a few has asked for.

I've had a think about this and propose the following. (No promises yet)

It will require reconfiguration of the entire Wah!Ki collection

Package File type: ZIP (crossplatform)
Archives will be linked via a tag system so the unse will be presented with multiple options
Archive types
-> Skins/Themes
-> Artwork
-> Music
-> Emulator

User may download and install from the emulator setup screen
--> archive will download to ~/.wahcade/tmp and extract to ~/.wahcade/systems/<inifilename>

User may browse Wah!Ki category pages from the setup screen based on categories and/or tags

Directory structure under ~/.wahcade/systems/<inifilename>
Code: Select all

A System ini file example
Code: Select all
### system.ini (wahcade) ###

emulator_title                          Atari 5200

### List Generation Settings ###
rom_path                                ~/.wahcade/systems/mess-atari-5200/roms
rom_extension                           a52
dat_file                                ~/.wahcade/systems/mess-atari-5200/meta/info.xml
nms_file                                ~/.wahcade/systems/mess-atari-5200/meta/nms.names
catver_ini_file                         ~/.wahcade/systems/mess-atari-5200/meta/catver.ini
list_generation_method                  rom_folder

### Execution Settings ###
emulator_executable                     ~/.wahcade/systems/mess-atari-5200/emulator_executable
commandline_format                      a5200 -rompath /opt/var/public/roms/atari/5200/roms -cart "[rompath]/[name].[romext]" -switchres
game_specific_config_path               ~/.wahcade/systems/mess-atari-5200/game/

### Artwork Locations ###
artwork_1_image_path                    ~/.wahcade/systems/mess-atari-5200/artwork_01_image_path
artwork_2_image_path                    ~/.wahcade/systems/mess-atari-5200/artwork_02_image_path
artwork_3_image_path                    ~/.wahcade/systems/mess-atari-5200/artwork_03_image_path
artwork_4_image_path                    ~/.wahcade/systems/mess-atari-5200/artwork_04_image_path
artwork_5_image_path                    ~/.wahcade/systems/mess-atari-5200/artwork_05_image_path
artwork_6_image_path                    ~/.wahcade/systems/mess-atari-5200/artwork_06_image_path
artwork_7_image_path                    ~/.wahcade/systems/mess-atari-5200/artwork_07_image_path
artwork_8_image_path                    ~/.wahcade/systems/mess-atari-5200/artwork_08_image_path
artwork_9_image_path                    ~/.wahcade/systems/mess-atari-5200/artwork_09_image_path
artwork_10_image_path                   ~/.wahcade/systems/mess-atari-5200/artwork_10_image_path
movie_preview_path                      ~/.wahcade/systems/mess-atari-5200/movie_preview_path
movie_artwork_no                        1

### Screen-Saver Settings ###
enable_music_in_screensaver             0
saver_type                              slideshow
movie_path                              ~/.wahcade/systems/mess-atari-5200/movie_preview_path
movie_fullscreen                        1
quit_delay                              30
wrapper_executable                      ~/.wahcade/systems/mess-atari-5200/wrapper_executable
wrapper_commandline_format              [name]
scr_file                                ~/.wahcade/systems/mess-atari-5200/scr_file

### External Application Settings ###
ipc_file_or_path                        ~/.wahcade/systems/mess-atari-5200/ipc
app_1_executable                        ~/.wahcade/systems/mess-atari-5200/app_1_executable
app_2_executable                        ~/.wahcade/systems/mess-atari-5200/app_2_executable
app_3_executable                        ~/.wahcade/systems/mess-atari-5200/app_3_executable

### Additional Settings ###
music_path                             ~/.wahcade/systems/mess-atari-5200/music
lcd_display_file_path                  ~/.wahcade/systems/mess-atari-5200/lcd

### Settings used by MAMEWAH ###
current_list                            0

Some thoughts anyway, this is not a priority something and could easliy be user driven

Re: Pre-Built Emulator Packages

PostPosted: Thu Dec 18, 2014 7:12 pm
by Zombie
This is where Distribution level packaging coming in. The idea is really good, Artwork assets for systems do need to be packaged and installed. (from /usr/share/games/wahcade) and Wahcade needs to initially launch with a working configuration, and use which to detect installed emulators like kdenlive detects things like dvgrab. What I'm saying is: We need more Artwork assets that can be included with the Wahcade Package and it needs to be absolutely the case that wahcade does not crash on its initial launch like it does now.

Re: Pre-Built Emulator Packages

PostPosted: Sat Dec 20, 2014 12:23 pm
by General_Faliure
Looks like a good idea

Re: Pre-Built Emulator Packages

PostPosted: Sat Dec 20, 2014 10:13 pm
by Zombie
Agreed CodeFenix. As time progressed, Emulators changed and advanced and gained more features and support for them improved. I had to transition from snes9x-gtk to retroarch, and gens to mednafen. Because the support for virtually everything had improved. Linux distributors provided a structure and frame work to work within. (be they RPM or Deb.)

Unfortunately, there is still a very Windows Driven mindset in WahCade that "we have to buck the Package management system and include our own pre-installed Binaries in tar balls that install in the user's Home directory and provide everything" thats pervasive because MameWah did that.

I haven't liked that in the past, and I don't like that in the present. The Emulators themselves, tested stable versions of them, should be maintained on distribution clusters. WahCade should go about finding the distribution has installed. Binary installation paths are minimally different at best (/usr/bin/mednafen vs. /usr/games/mednafen) and installation of said application normally means calling yum, aptitude, or urpmi. ini packages should install in /usr/share/wahcade/ini (I have to cp new ini files all the time)

Art Assets such as the EmuChrist skins, or CodeFenix's Customs, (Or anything else) should be a sub package that installs in /usr/share/wahcade. Currently, I use a skins out of /opt/ But they should be in /usr/share/wahcade/skins

Re: Pre-Built Emulator Packages

PostPosted: Sun Dec 21, 2014 12:55 am
by sairuk
A little bit off-topic but slightly in response to the archive approach,

From where I sit It's not actually a windows driven mindset, quite simply python is cross-platform therefore Wah!Cade should also consider this during its development. In reality I barely consider windows during any development and only occasionally test it in windows when i can be bothered installing a vm.

That being said I see little advantage to packaging systems for software like Wah!Cade where you could simply root extract an archive providing dependencies were nil/minimised and still keep the same functionality.

The dependencies of Wah!Cade are understandable from say 10yrs ago but I believe there are better options available nowdays to build it as a primarily standalone system. While i have no intent to learn C/C++ I have been considering writing my own frontend in a 'game engine' for some time now although as with actual Wah!Cade development I have other priorities currently (consider I have been interrupted 15 times! by my 5 kids writing this so far). To be entirely fair I would like to see Wah!Cade run wherever X engine runs and minimise the overhead; or at least if there is to be non-value added overhead have an infinitely customisable layout methodology based in an every growing set of standardised tools (i.e. Webcade). I've done some studies and even with the overhead Webcade actually ran within 10mb of standard Wah!Cade depending on the browser used.

I also decided to sit down and understand the basics of building a pygtk interface the other day; up until which I'd never used/understood pygtk in Wah!cade. I managed to spit out, as a result and can see now why Wah!Cade _appeared_ bloated to me originally. Arguably it may be simpler to dump Wah!Cade and start again with a Wah!Cade/MameWah import function into newer tech XML/SQLite/SQL than map the entire flow and fix holes. This may be for someone with more of a CS background than I have also.

The main components of Wah!Cade aren't that massive win_main is only ~2100 lines, I'd like to see the layout editor and setup windows available in-line these days not as a separate application, e.g. press F11 to enter edit-mode and move your layout live on the main window, F11 again saves and toggles back to run mode etc. I also like the idea of influencing the system loaded at startup from the command line someone requested a while back.

...OK make that 20 interruptions now ;) I am looking at a little plasticine snake one of my kids made and something about sitting in breakfast cereal from another ;)

Wah!Cade is still supposed to be a clone of MameWah which happens to be windows software, i don't intend to change that even if we have added some additional stuff over the years. If you want something else you are actually talking about a new frontend effectively, luckily linux lets you symlink.

Perhaps that is the driver to start a new frontend from scratch still python based(?), its one of the reasons Webcade was tested; That is to have a go at processing Wah!Cade setup files for use in a different project.

Re: Pre-Built Emulator Packages

PostPosted: Sun Dec 21, 2014 9:40 pm
by Zombie
My goal is not to make a WahCade that resembles Mala or Hyperspin, its to get WahCade to not crash.

Re: Pre-Built Emulator Packages

PostPosted: Mon Dec 22, 2014 12:46 am
by sairuk
i expect the bug/blueprint reporting on lp would be more active as that's where I've specifically requested items be reported, centralising issues on lp makes it easier/quickerr for me to review them over a lunch break than digging through forums to find issues tracebacks etc.

Same would be true for anyone I'd imagine.

Re: Pre-Built Emulator Packages

PostPosted: Mon Dec 22, 2014 2:29 am
by Zombie
Very well. I can be impartial. Here is what I am going to do: I'm going to put up a bug about the Controller swapping. Done.

Re: Pre-Built Emulator Packages

PostPosted: Mon Dec 22, 2014 10:20 pm
by sairuk
Zombie wrote:Very well. I can be impartial. Here is what I am going to do: I'm going to put up a bug about the Controller swapping. Done.

Thanks, i have assigned this bug to myself so now its on my radar. As you know js support is hit and miss atm so hopefully we can get a proper resolution. I'll need you to test it, last i recall i tried swapping stuff out on my install and it didn't fall over but will reconfirm that today.

Re: Pre-Built Emulator Packages

PostPosted: Mon Dec 22, 2014 11:29 pm
by Zombie
I added a Blueprint for better Controller support overall, including the display Controller properties in more detail.