[Xmame] BUILD_EXPAT in Makefile
The Makefile has BUILD_EXPAT=1 uncommented. This is a (minor) problem for the debian package because policy says packages should use the original upstream tree (ie no modifications outside debian/). Currently, we patch/unpatch the Makefile during builds to uncomment the BUILD_EXPAT line. Can you comment it (like BUILD_ZLIB)? Nicos ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] ~ in paths in config file
Lawrence Gold wrote: Denilson F. de S wrote: When reading config files (like xmamerc), xmame should detect ~/ in paths and understand the path is relative to current user home directory. By the way, xmame -showconfig prints some paths starting with $HOME (like $HOME/.xmame/cfg), but $HOME isn't replaced by user home directory when parsing the config file. Any variable beginning with $ should be parsed as an environment variable. From the shell, when I type echo $HOME, I get /home/gold and I'm pretty sure xmame is correctly expanding it, though I haven't tested it for a while. I'll put support for ~ on my todo list. ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame How about wordexp? It's in glibc but I am not sure how portable it is. It supports ~ expansion as well as some fancy variable expansion stuff (arithmetic, prefix substitution etc). Nicos ___ Xmame mailing list Xmame@toybox.twisted.org.uk http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] CVS usage question
Julian Sikorski wrote: Hi. I'd like to check the newest gxmame cvs. If the normal command to get it is: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/gxmame co gxmame what should I do to get Next-Version-0.40 branch? ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/gxmame co -r Next-Version-0.40 gxmame The branch works for browsing and running your roms (even with 0.88) and that's about it for the moment. ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [OT] GXMame, Was Re: [Xmame] Time for xmame 0.88? And the usual frontend question...
On Tue, 2004-11-16 at 09:55 +0100, P. Cizaire wrote: On Mon, 15 Nov 2004 23:56:33 +0200, Nicos Panayides [EMAIL PROTECTED] wrote: On Mon, 2004-11-15 at 10:57 +0100, P. Cizaire wrote: I already merged the original patch you sent to gxmame CVS (with lots of changes). Sorry for the lots of changes, I was expecting it to be easy. Most of the changes were macro removals etc. We try to keep the code as easy as possible to follow so that more people can contribute. Some of the fixes are already there. Can you send patches relative to CVS to make our lives easier? Do you have an URL where I can download a tarball of the CVS, or something similar : I do not have a CVS client connected to the net. Thus I can emit patches for both the latest released gxmame (The one I use, the one I was thinking to be used by the people on this list), and the CVS one. I uploaded a source tarball in the Files page in the sf project pages. Note that my patches where not (at first) dedicated to gxmame development team (wich I was thinking as beeing dead) but to xmame users found here. We are still breathing :). The main branch is in a semi-frozen state because all changes I have are big so it will take time to test everything and merge them. Cheers Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [OT] GXMame, Was Re: [Xmame] Time for xmame 0.88? And the usual frontend question...
On Mon, 2004-11-15 at 10:57 +0100, P. Cizaire wrote: Some patches over my preceding patch : pci1_pci2 : bug fix : fixes bad clone tree view, filter some messages pci2_pci3 : feature : feature change about driver status and icones : driver status is now (Good, Problem, NoSound, Dead), icones changes according to this is rom is found pci3_pci4 : bug fix : better driver field, no more empty neo-geo, cps1, cps2 pci4_pci5 : compatibility fix : handle old (pre pci2_pci3) status field true=Good false=Dead Note : if you do not want the pci2_pci3, you probably can still apply pci3_pci4, but you should not apply pci4_pci5 I already merged the original patch you sent to gxmame CVS (with lots of changes). Some of the fixes are already there. Can you send patches relative to CVS to make our lives easier? Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Time for xmame 0.88? And the usual frontend question...
Just in case you care : find attached a hack I did to make gxmame directly parse mame 0.88 xml -listxml -- Regards, P. Cizaire Thank you! Could you make it into a separate function so that we can still support older versions of xmame without -listxml? The CVS version detects if xmlinfo is used and it pipes the output to xml2info. You can call your function there. Cheers, Nicos -- Geschenkt: 3 Monate GMX ProMail + 3 Top-Spielfilme auf DVD ++ Jetzt kostenlos testen http://www.gmx.net/de/go/mail ++ ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Time for xmame 0.88? And the usual frontend question...
On Mon, 2004-11-08 at 17:08 +0100, P. Cizaire wrote: On Mon, 8 Nov 2004 11:49:18 +0100 (MET), Nicos Panayides [EMAIL PROTECTED] wrote: [snip] Thank you! Could you make it into a separate function so that we can still support older versions of xmame without -listxml? The CVS version detects if xmlinfo is used and it pipes the output to xml2info. You can call your function there. Just rename the function gboolean create_game_list_file(void) to gboolean create_game_list_file_xml(void) then call this function and it should do the trick : my patch just replaces the gboolean create_game_list_file(void) by mine and increase some field max size. Ok :) I will (probably) merge this next weekend, unless someone beats me to it. Thanks, Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Time for xmame 0.88? And the usual frontend question...
On Sun, 2004-11-07 at 00:09 -0700, Lawrence Gold wrote: Hans de Goede wrote: Svgalib and svgafx are done, and don't forget that x11 now includes the old xgl and xfx targets, so we have 5 of the old targets working SDL is in progress, but I have other (reallife) priorities now so I think that will take about a week to finish. All right, I'll plan on releasing 0.88 in the next day or two. Additional display drivers can be fixed in 0.88.1 or 0.89. I may tweak the documentation a bit, but that isn't much fun, so don't expect much of a delay from that. :D Is it possible to change xgl.c so that libGL.so.1 and libGLU.so.1 are searched by default instead of libGL.so and libGLU.so? The *.so symlinks are part of the development packages (xlibmesa-gl-dev or nvidia-glx-dev and xlibmesa-glu-dev) in Debian and probably on other distributions so xmame cannot dload the libraries unless the development packages are installed. Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Unable to compile 0.87u4
This (not using stderr_file) is consistent with the other drivers residing in the sysdep dir, I think it is time to remove stderr_file, if people want to redirect stderr then the shell can do that without any problems. stdout_file is the only (easy) way, x11 frontends can communicate with the svgalib target (due to console switching). Is it possible to have -help output, rom loading messages/errors, etc before sysdep_init? If it's done that way then frontends can redirect the xmame output and parse xmame messages without needing -out for svgalib or any other display mode that redirects the output to another console. Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Problem with snowbros and King of Fighters 98,99
On Wed, 2004-09-08 at 21:26 -0400, Bruno Barrera C. wrote: I've invited some friends to test the xmame packages that I've build, and they have some troubles with them. Are you interested in working together? I've been maintaining my own set of xmame packages for a couple of years and I believe they are of much better quality than the official Debian packages. Sources/binaries at: http://anarxia.dyndns.org/debian I've searched in Google for some answers but I got nothing, anyway feel free to push me if I'm not reading some important changelog/documentation, etc. Romsets sometimes change between mame versions so it's not a problem with your packages but a change in mame that caused it. The easiest way of dealing with this is to use advancescan or another rom manager to fix those that can be fixed and download the missing roms. Good luck with the packages. Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] gxmame and -xil fixed
The xil issue is fixed in the gxmame CVS. Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] xmame/xmess-0.86
On Thu, 2004-08-26 at 19:19 +0200, Matthias Saou wrote: Lawrence Gold wrote : xmame/xmess-0.86 is out! I've had this error when building the SDL target (the x11 built fine) : [...] Linking xmame.SDL ... xmame.obj/unix.SDL/devices.o(.text+0x20c): In function `osd_input_initpre': src/unix/devices.c:532: undefined reference to `joy_SDL_init' collect2: ld returned 1 exit status make: *** [xmame.SDL] Error 1 Probably related to the changes mentioned below : - The SDL joystick driver works again. It should also be a bit faster. Matthias Define JOY_SDL=1 in the makefile. Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Frontend question
On Sat, 2004-07-17 at 11:58 +0200, Julian Sikorski wrote: Lawrence Gold wrote: You might be able to simply substitute -listxml %s | xml2info for -listinfo %s in the above code. It doesn't work. Sorry to bother you, but shadow_walker doesn't respond. I can't speak for the rest of the gxmame developers but I don't have the time right now to fix it. If you want to see this fixed ASAP, send us patches. If you are gonna use an xml library please use libxml2 which is used by gtk anyway. Give us a couple of weeks and it will be fixed (at least in CVS). Promise :) Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] Install permissions
On Wed, 2004-04-14 at 13:56, Pieter Hulshoff wrote: On Wednesday 14 April 2004 22:46, Caleb Shay wrote: On Wed, 2004-04-14 at 16:38, XulChris wrote: Remember that xmame requires root access for fullscreen mode. Also remember, that is no longer strictly true. While DGA fullscreen requires root access, SDL, XGL, and Xv fullscreen do not. Isn't DGA defined in the DRI definition of X? Can't you just define your group properly, and be able to access it that way, or does the suid bit need to be set on xmame to make it work? DGA needs access to /dev/kmem. If you allow a user to read/write kmem you might as well make him/her root. So an suid binary is more secure than the alternative. Same applies to svgalib. In a multi-user box you shouldn't use DGA or svgalib applications if you don't trust your users. Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] PATCH: Configuration files
On Wed, 2004-02-11 at 05:29, Andre Majorel wrote: So, if Lawrence also changed SYSCONFDIR from $(XMAMEROOT) to /etc/xmame, the system-wide configuration file would become /etc/xmame/xmame.cfg ? Yeah, that would be more FHS-ly correct. The only drawback I can think of is that if you install the xmame package and then install Xmame from source, the system-wide configuration file would be overwritten. The setting should be $(PREFIX)/etc/xmame not /etc/xmame. So if you install at /usr/local the configuration goes to /usr/local/etc. The packaged binary can still use /etc/xmame with no conflict. Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] PATCH: Configuration files
On Wed, 2004-02-11 at 19:01, Andre Majorel wrote: I was about to say that you can't have /usr/local/etc *and* be FHS-compliant at the same time but, as it turns out, they added it in version 2.3. http://bugs.freestandards.org/cgi-bin/bugzilla/show_bug.cgi?id=8 This is excellent news as it solves the aforementioned problem and makes configure scripts simpler but it also means that I'm going to have update all my scripts. Oh joy. Incidentally, if prefix is /opt/something, SYSCONFDIR should be /etc/$(PREFIX), not $(PREFIX)/etc (unless they *also* changed that). You can override SYSCONFDIR so there is no need to make things more complicated. $(PREFIX)/etc is what autoconf uses so it makes sense to use that. Anyway, Lawrence didn't accept/reject so it is not excellent news YET :) Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] PATCH: Configuration files
On Wed, 2004-02-11 at 21:05, Lawrence Gold wrote: Oh, it's in there -- I forgot to respond. If you don't hear back from me, it's usually safe to assume that something's been accepted, especially when it's non-controversial. :-) Ok thanks. Usually it's the other way round :) Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] PATCH: Configuration files
This trivial patch (against 0.78.1) allows the separation between data
files and system-wide configuration files in different directories.
The default settings are left unchanged but it is very easy
to make xmame fully FHS compliant (without using symlinks).
This makes packaging a lot easier.
Thanks,
Nicos
diff -urN xmame-0.78.1.orig/makefile.unix xmame-0.78.1/makefile.unix
--- xmame-0.78.1.orig/makefile.unix 2004-01-08 18:54:22.0 -0700
+++ xmame-0.78.1/makefile.unix 2004-02-10 23:00:49.0 -0700
@@ -462,7 +462,8 @@
# This is the default path for ROMs and other data files.
XMAMEROOT = $(PREFIX)/share/x$(TARGET)
-
+# This is the default path for system-wide configuration directory
+SYSCONFDIR = $(XMAMEROOT)
###
# Architecture; choose your CPU (only one!!)
diff -urN xmame-0.78.1.orig/src/unix/config.c xmame-0.78.1/src/unix/config.c
--- xmame-0.78.1.orig/src/unix/config.c 2003-12-26 16:29:16.0 -0700
+++ xmame-0.78.1/src/unix/config.c 2004-02-10 23:05:09.0 -0700
@@ -319,13 +319,13 @@
lowest priority */
if(loadconfig)
{
- snprintf(buffer, BUF_SIZE, %s/%src, XMAMEROOT, NAME);
+ snprintf(buffer, BUF_SIZE, %s/%src, SYSCONFDIR, NAME);
if(rc_load(rc, buffer, 1, 1))
return OSD_NOT_OK;
snprintf(buffer, BUF_SIZE, %s/.%s/%src, home_dir, NAME, NAME);
if(rc_load(rc, buffer, 1, 1))
return OSD_NOT_OK;
- snprintf(buffer, BUF_SIZE, %s/%s-%src, XMAMEROOT, NAME, DISPLAY_METHOD);
+ snprintf(buffer, BUF_SIZE, %s/%s-%src, SYSCONFDIR, NAME, DISPLAY_METHOD);
if(rc_load(rc, buffer, 1, 1))
return OSD_NOT_OK;
snprintf(buffer, BUF_SIZE, %s/.%s/%s-%src, home_dir, NAME, NAME,
@@ -532,7 +532,7 @@
/* now that we've got the gamename parse the game specific configfile */
if (loadconfig)
{
- snprintf(buffer, BUF_SIZE, %s/rc/%src, XMAMEROOT,
+ snprintf(buffer, BUF_SIZE, %s/rc/%src, SYSCONFDIR,
drivers[game_index]-name);
if(rc_load(rc, buffer, 1, 1))
return OSD_NOT_OK;
@@ -670,15 +670,15 @@
/* footer */
fprintf(stdout_file, \nFiles:\n\n);
fprintf(stdout_file, Config Files are parsed in the following order:\n);
- fprint_columns(stdout_file, XMAMEROOT/NAMErc,
+ fprint_columns(stdout_file, SYSCONFDIR/NAMErc,
Global configuration config file);
fprint_columns(stdout_file, ${HOME}/.NAME/NAMErc,
User configuration config file);
- fprint_columns(stdout_file, XMAMEROOT/NAME-DISPLAY_METHODrc,
+ fprint_columns(stdout_file, SYSCONFDIR/NAME-DISPLAY_METHODrc,
Global per display method config file);
fprint_columns(stdout_file, ${HOME}/.NAME/NAME-DISPLAY_METHODrc,
User per display method config file);
- fprint_columns(stdout_file, XMAMEROOT/rc/gamerc,
+ fprint_columns(stdout_file, SYSCONFDIR/rc/gamerc,
Global per game config file);
fprint_columns(stdout_file, ${HOME}/.NAME/rc/gamerc,
User per game config file);
Re: [Xmame] Not really MAME related - XFree86 config with arcade monitor
On Fri, 2004-01-30 at 00:28, Francois Liot wrote: Hello, I'm considering to buy arcade cabinet. How will I have to configure XFree for using the arcade monitor ?. Does somebody can give me standart advices ? linux (whatever distro), kernel version doesn't really matter (is there some options that should be taken and some avoided ?) Graphical card NVidia Geforce FX 5200 (I may find some other if it's really required) I think I will buy some JPAC (http://www.ultimarc.com) It wont make a big difference. TV out is not an issue if you are going to use an arcade monitor (simple hack required though). Just stay away from old S3s. 1) I have no idea of the arcade monitor type... Is it true that the standart exisiting monitor types are these ones ? 192 x 60 Hz = 13 kHz (doublescaned to 384 lines at 26 kHz) 224 x 60 Hz = 15.25 kHz 262 lines (230 active + 32 blanking) x 60 Hz = 15.72 kHz (reference mode) 240 x 60 Hz = 16.3 kHz 384 x 60 Hz = 26.0 kHz (reference mode) 480 x 60 Hz = 32 kHz (reference mode) pclock 6-90 hclock 15.25 -16.75, 24-26, 31-32. vclock 50-90 You can get the specs for an arcade monitor here: http://www.hantarex.co.uk/vdogame.htm But not all arcade monitors are made equal so yours might be a little different. 2) What must be my XFree86 config (for Monitor section) regarding this different standart types : ? HorizSync 30-85 ? VertRefresh 50-160 ? # 640x480, 60.0Hz; hfreq=31.47, vfreq=59.94 ? ModeLine 640x480 25.17 640 648 744 784 480 482 484 509 -hsync -vsync VertRefresh should be around 50-60Hz (closer to 60) and there are adjustments you can do on the monitor. Use the specs and http://xtiming.sourceforge.net/ to generate modelines for all resolutions your monitor supports. 3) I heard that some Monitors are 90 rotated, is it possible to support that on X itself ? You don't need to. The 90o rotated monitors are mounted with that rotation for vertical games. Most cabinets (at least the ones during the early 90s) have a wooden/plastic frame behind the glass that can be rotated to support both positions so this is usually not an issue. If the cabinet you are buying is not an original cabinet for a vertical game you should be fine (doesn't hurt to ask though). Thanks for your help, NP:) -- Nicos Panayides [EMAIL PROTECTED] ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] GXMame 0.34 if finally out
On Tue, 2003-12-16 at 10:39, Doug Holland wrote: Looks nice. One problem I've been having is that I can't get options for individual games to override the global defaults. How do I do this? You can thank me for this bug :) In src/io.c at line 1289: - if(g_file_test(filename, G_FILE_TEST_EXISTS)) + if(!g_file_test(filename, G_FILE_TEST_EXISTS)) Does this fix it? Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] GXMame 0.34 if finally out
On Tue, 2003-12-16 at 15:43, Doug Holland wrote: On Tue 16 Dec 2003 3:26 pm, Nicos Panayides wrote: On Tue, 2003-12-16 at 10:39, Doug Holland wrote: Looks nice. One problem I've been having is that I can't get options for individual games to override the global defaults. How do I do this? You can thank me for this bug :) In src/io.c at line 1289: - if(g_file_test(filename, G_FILE_TEST_EXISTS)) + if(!g_file_test(filename, G_FILE_TEST_EXISTS)) Does this fix it? Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame Indeed it does. I was already one step ahead of you and filed a bug report w/ the patch on sourceforge. :D Doug grrr. You beat me to it because I was sleeping :) Thanks for the bug report and the patch. Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] xmame modules take 1
Here's a patch against 0.77.1 for dynamic loaded plugins for most dsp and mixer drivers (tested: oss, alsa, SDL, esound and waveout on linux only). Requirements: automake 1.7.1+ autoconf 2.5x libtool 1.5+ How it works: - Build and install xmame as normal (but don't build any additional dsp and mixer drivers). (Notice the DYNAMIC_MODULES = 1 in makefile.unix) - Go in src/unix/sysdep: - ./autogen.sh --enable-oss --enable-alsa etc. (see generated configure --help for all options). - make install (as root). This will install the plugins in /usr/local/lib/xmame/plugins. This path is hardcoded so don't change the prefix for configure or move the plugins. start up xmame and all plugins should work as if they were build in. The dynamic plugins can be disabled by commenting out DYNAMIC_MODULES in makefile.unix and everything should work like before. Nicos dyn_modules.diff.gz Description: GNU Zip compressed data
Re: [Xmame] xmame modules take 1
On Sun, 2003-12-14 at 13:48, F.J. McCloud wrote: --- Nicos Panayides [EMAIL PROTECTED] wrote: The dynamic plugins can be disabled by commenting out DYNAMIC_MODULES in makefile.unix and everything should work like before. Meaning I don't need autoconf, automake, and libtool if I comment out DYNAMIC_MODULES? Yes, they are only used to build the dynamic modules. Thank goodness if that's the case; I was going to argue what's wrong with the older versions of those and rant about bleeding-edge dependencies and all that. I rather like that I can keep track of my own dependencies so easily in makefile.unix and just type make and not worry about, for example: SDL, nasm, etc. if I so choose. In my experience it is usually a lot easier to do that with autoconf. You simply write a script that calls configure with the right flags and you don't need to worry about chasing all flags in the makefile every new release. The reason for depending on bleeding edge stuff (some of which were released more than a year ago) is that I wanted to get something working fast. Anyway, my intention is for the generated files to be distributed with each release so that a simple ./configure make would work, so I didn't think it would be so important at this point. Nicos -- Nicos Panayides [EMAIL PROTECTED] ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] OSS mixer is dynamic!
After our recent discussion and after digging into the sources some more it turns out that most of the infrastructure was already in place since 2000! I converted the oss mixer to a dynamic module (and loaded it at runtime). The loader detects incompatible/invalid modules so versioning is definately a non-issue (in case anyone is worried). The conversion is just the addition of a macro and include for config.h so it is fairly trivial to convert all mixer and dsp plugins to dynamic modules. This is assuming that they don't use any (non-macro, non-static inline) functions from xmame. Of course, there is still a lot of work to be done to integrate it smoothly with the rest of the sources and make the installation easier. The main problem is the build process. I dropped autoconf etc in the sysdep directory and the modules are built with libtool (with an --enable switch for each one). They will only be needed to build the plugins. The autotools generated files can be distributed with the sources so it is not a big issue (the increase in size won't even be noticeable :) ). Will it be a problem to have a dependency on libtool, autoconf and automake? I am also having problems integrating it with the main makefile so that if the user selects dynamic plugins the static ones are not build. It is also possible to have both. Any suggestions? Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
Re: [Xmame] RFC: xmame modules
On Tue, 2003-12-09 at 00:48, smf wrote: However I don't believe this achieves what the original suggestion was attempting to. It won't reduce memory footprint and it won't allow you to download a new driver module. The original suggestion was about dynamic modules for everything, but as many people have pointed out it is not very beneficial for the drivers and it will also create problems when merging the mame sources for every version, so all changes should be isolated in the system dependent code. The code for the various dsp and display drivers is already separated and there is already a plugin interface in place so changes will (hopefully) not need to touch a lot of places. So, no it will not allow you to download a new driver but it will allow you to download new display and dsp drivers and it will make packagers life easier (those that want to provide as many options as possible). Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] RFC: xmame modules
xmame 0.77 is almost 20Mb in size and the majority of the code is not used when emulating a single game. The situation will only get worse as the number of supported games/machines increases. I was thinking that if drivers, hardware emulation pieces, output plugins etc, were dynamic loaded modules memory usage will be reduced and other nice side-effects will result: plugins, new drivers without recompiling the core etc. I know that this is non-trivial but I will give it a shot sometime in the near future if the xmame devs think it's a good idea and it might get merged. Any thoughts, comments? Regards, Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
[Xmame] RFC: xmame modules
Demand paging certainly reduces the memory footprint and tinyxmame is only insignificantly faster than xmame. Agreed, drivers are not good candidates for dynamic modules but I still believe that display and sound plugins are. To support all display/sound targets you currently need at least 4 packages (X/XV, SDL, svgalib, xgl etc) and link them against all sound libraries (alsa, arts, esound etc). There is simply no way around this except dynamic loading. In the case of arts, the dependencies (kdelibs namely) are too much for an optional feature. Versioning is not an issue. Binary packages have dependency information which takes care of that, and make install can issue a warning if the modules directory is not empty. Nicos ___ Xmame mailing list [EMAIL PROTECTED] http://toybox.twisted.org.uk/mailman/listinfo/xmame
