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
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
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
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
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
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
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
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
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
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
The xil issue is fixed in the gxmame CVS.
Nicos
___
Xmame mailing list
[EMAIL PROTECTED]
http://toybox.twisted.org.uk/mailman/listinfo/xmame
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':
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
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
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
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
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
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 for your help,
NP:)
--
Nicos Panayides [EMAIL PROTECTED]
___
Xmame mailing list
[EMAIL PROTECTED]
http://toybox.twisted.org.uk/mailman/listinfo/xmame
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,
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
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
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
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
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
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
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
27 matches
Mail list logo
