Are you by any chance running the x11 target in Xv mode? Could be a broken
overlay support in your video drivers.
Le 11 Janvier 2004 2221, Robert Alan Byer a écrit :
> -BEGIN PGP SIGNED MESSAGE-
>
>
> Anyone have any ideas as to what could cause colors to be WAYY off in
> XMAME/XMESS? (or
-BEGIN PGP SIGNED MESSAGE-
Anyone have any ideas as to what could cause colors to be WAYY off in
XMAME/XMESS? (or where to start looking?)
I don't think it's the X on my PC, it displays XMAME/XMESS properly under
Solaris, but not under my OpenVMS port. I thought is was compiler
optim
regular mame
Date: Sun, 11 Jan 2004 18:24:34 -0600
Content-Type: text/plain; charset="iso-8859-1"
I built my xmame off of a clean patched version of the windows mame
source up to 078u2 and as far as I can tell they share info.c (the
windows mame and xmame info.c in 0.77 are identical in a diff min
> I'm told that this doesn't occur in the regular
> windows mame 0,78u2 build. My question is - why?
I believe it's because the call to cpuintrf_init() is already in the windows
mame code.
smf
___
Xmame mailing list
[EMAIL PROTECTED]
http://toybox.tw
Preface: IANAP(rogrammer)
Just a curiousity question - I put together a build of xmame 0.78u2
and was able to build it fine. Later I found that -listinfo was
causing a segfault, and I traced it back to info.c in src/. It just
needed a couple cpuintrf_init() calls in the right places and that
mad
On 01/10, Alastair Robinson wrote:
> Anyway, I'm finding that on a 1GHz machine with GCC 3.2 and full
> optimisations, it's taking me about ten minutes to recompile x11_window.c and
> re-link xmame every time I make a change to blit.h.
If at link step, the "ld" process stay minutes without access
hmm, it's more complicated than I thought to pull the relevant code out. if
you get stuck then download the dos mame source from mame.net ( it's only a
few hundred k ). some of this is from src\msdos\video.c & some from
src\msdos\blit.c
If I had time I might tidy this up a bit :-)
UINT32 blit_loo
