c:\mame_folder>groovymame.exe -ccc:\mame_folder>groovymame.exe romname -v >romname.txt- Upload romname.txt as an attachment to your post. Please don't paste it inside the edit box as it makes things unreadable.c:\mame_source>patch -p0 -E --binary <hi_171.diff
c:\mame_source>patch -p0 -E --binary <0171_groovymame_015m.diff
c:\mame_source>make
modeline "320x240_60 15.91KHz 60.05Hz" 6.62 320 344 376 416 240 244 247 265 -hsync -vsyncgroovymame.exe orunners -numscreens 2groovymame.exe 1942 -numscreens 2 -view1 marqueePowerStrip timing parameters:
1366x768=1366,36,48,42,768,3,5,6,69840,518
Generic timing details for 1366x768:
HFP=36 HSW=48 HBP=42 kHz=47 VFP=3 VSW=5 VBP=6 Hz=60
VESA detailed timing:
PClk=69,84 H.Active=1366 H.Blank=126 H.Offset=20 HSW=48 V.Active=768 V.Blank=14 V.Offset=3 VSW=5
Linux modeline parameters:
"1366x768" 69,840 1366 1402 1450 1492 768 771 776 782 -hsync -vsyncpowerstrip 1
ps_timing 1366,36,48,42,768,3,5,6,69840,518
multithreading is off by default now?
Also, i keep getting pop-ups saying switchres cannot find a video mode to suit my specs..
Thanks for this awesome update, Calamity!
I have a question about how black frame insertion works. Is it always just doubling the refresh rate of whichever game is running, or is it just locked at 120hz? If it's locked at 120hz, it'd be choppy with most games, right?
If I'm playing Pacman, does it run at 121.2hz? If I'm playing Mortal Kombat, does it run at 109.4hz?
It seems like you'd actually need a 144hz LCD to be able to double the refresh rate of any game since a lot of games ran at more than 60hz.
- Second : Xp64 with crt_emu 6.5 using x1900xt on a vertical monitor (ms929)
On this setup i can't use frame delay. If i change from 0 to any values, the game is too speedy.
Thanks for this awesome update, Calamity!
I have a question about how black frame insertion works. Is it always just doubling the refresh rate of whichever game is running, or is it just locked at 120hz? If it's locked at 120hz, it'd be choppy with most games, right?
If I'm playing Pacman, does it run at 121.2hz? If I'm playing Mortal Kombat, does it run at 109.4hz?
It seems like you'd actually need a 144hz LCD to be able to double the refresh rate of any game since a lot of games ran at more than 60hz.
Black frame insertion halves the current refresh rate whatever it is. If you force black frame insertion on a fixed 60 Hz display, a 60 Hz game will run at 50% of speed. If you have a 120 Hz capable LCD, you will select this refresh, either in the desktop properties or in GM setup, then apply black frame insertion and everthing should run smoothly at 60 Hz. Obviously games that didn't run at 60 Hz natively will run at the wrong speed, as with any other LCD, but perfectly smooth. Black frame insertion requires the most strict v-sync so there's no room for triple buffering here.
On the other hand, when using a CRT, GroovyMAME will precalculate the exact double refresh rate beforehand, whenever possible, so when black frame insertion is applied the resulting refresh is equal the native. It is possible to achieve arbitrary refresh rates for LCD monitors too, in combination with Powerstrip, but you need to find a model that's both 120 Hz and variable refresh rate capable, and a video card that's supported by Powerstrip (unlikely combination of things).
Hi bulbousbeard,
I was saying "120 Hz" for short, what I meant is double refresh rates. I share your enthusiasm about G-sync, and when these monitors are actually available, we'll see what can be done, although you don't really need GroovyMAME for that, as long as video timing will be throttled by the CPU clock that means regular MAME will be good. Of course, for G-sync you'll need a totally different implementation of black frame insertion, one that is based on the CPU clock rather than the GPU clock (what we now do in GroovyMAME). You will need to divide the frame period by 2 just based on the CPU clock, in order to insert the black frame just in time, and this needs to be really accurate ::), otherwise you'll get a flashy picture like a silent film from the 1920's. I'm a bit sceptic about this technology, hopefully we'll see it working soon.
Calamity,
I'm extending an offer to supply you with the first Gsync monitor that's available if you're interested in adding support for it. Let me know, and I will have one sent to you.
I'm a bit sceptical about this technology personally..Hi bulbousbeard,
I was saying "120 Hz" for short, what I meant is double refresh rates. I share your enthusiasm about G-sync, and when these monitors are actually available, we'll see what can be done, although you don't really need GroovyMAME for that, as long as video timing will be throttled by the CPU clock that means regular MAME will be good. Of course, for G-sync you'll need a totally different implementation of black frame insertion, one that is based on the CPU clock rather than the GPU clock (what we now do in GroovyMAME). You will need to divide the frame period by 2 just based on the CPU clock, in order to insert the black frame just in time, and this needs to be really accurate ::), otherwise you'll get a flashy picture like a silent film from the 1920's. I'm a bit sceptic about this technology, hopefully we'll see it working soon.
Calamity,
I'm extending an offer to supply you with the first Gsync monitor that's available if you're interested in adding support for it. Let me know, and I will have one sent to you.
- Second : Xp64 with crt_emu 6.5 using x1900xt on a vertical monitor (ms929)
On this setup i can't use frame delay. If i change from 0 to any values, the game is too speedy.
Try switching to -video ddraw.
Calamity,
I'm extending an offer to supply you with the first Gsync monitor that's available if you're interested in adding support for it. Let me know, and I will have one sent to you.
- Second : Xp64 with crt_emu 6.5 using x1900xt on a vertical monitor (ms929)
I tryed with ddraw but didn't get better result. Do you think it could be related with the fact it's a vertical setup ?
That's by far the most generous offer I've received and I'd feel bad about you alone funding this so if some users joined you I'd definitely would commit to implementing this.
Calamity,
I'm extending an offer to supply you with the first Gsync monitor that's available if you're interested in adding support for it. Let me know, and I will have one sent to you.
Hi bulbousbeard,
That's by far the most generous offer I've received and I'd feel bad about you alone funding this so if some users joined you I'd definitely would commit to implementing this.
multithreading is off by default now?
Yes, I'll write about this later.
- Second : Xp64 with crt_emu 6.5 using x1900xt on a vertical monitor (ms929)
I tryed with ddraw but didn't get better result. Do you think it could be related with the fact it's a vertical setup ?
Hi Dalba,
I'd suggest that you install CRT Emudriver 9.3 for that card. The 6.5 x64 is just provided to support 7xxx and 9xxx cards, it's based on a unofficial release IIRC. It could be these drivers are not providing a good v-sync support for your card. Also check if hardware acceleration is enabled (run dxdiag), otherwise it would point to a bad driver installation.
Thanks for your help, it now works with Emudriver 9.3, but i had to change XP64 to XP32. For an odd reason, Xp64 didn't like much modelines generated by vmmaker with emudriver 9.3 64bits. Each time i was rebooting after modelines being generated by vmmaker, i got BSOD before windows login.
Direct3D: Error 88760868 during device present call
Direct3D: resetting device
Thanks a lot Calamity, will the sdl gm also benefit from the improvements?
Just noticed the Powerstrip feature is not working in this newer version, due to lack of proper testing from my part. I'll upload a fix ASAP.
Anyone getting sh-3 to work? I tried compiling as noted above after applying the sh-3 diff and it errors out.
Curious if anyone has actually managed to get this working.
Thanks,
Jim
Has anyone compiled this with the cave driver allready?
Hi cools,
Set "writeconfig 1" in ume.ini
It's disabled by default in recent versions.
make: *** No rules to make target «obj/groovysdl64/osd/sdl/dview.o», needed for «obj/groovysdl64/libosd.a». Stop.Tried with this. It creates inis, but it only seems to save the cfgs if you actually quit out rather than select a new game. It also seems to ignore the cfgs when loading.
Something is most definitely up with it.
Tried with GroovyMAME and GroovyUME. MAME64 standard behaves sensibly.
This command line worked for me: make TARGET=mame PYTHON=python2 OPTIMIZE=2I bet the problem was the default optimization ("OPTIMIZE=3", which means "-O3").
Tried with this. It creates inis, but it only seems to save the cfgs if you actually quit out rather than select a new game. It also seems to ignore the cfgs when loading.
Something is most definitely up with it.
Tried with GroovyMAME and GroovyUME. MAME64 standard behaves sensibly.
HERE WE GO! (hopefully)
You uncommented "NO_USE_QTDEBUG = 1" into "src/osd/sdl/sdl.mak" and this makes my system go crazy.
Now I have re-commented "NO_USE_QTDEBUG = 1" and trying to recompile.
PS: is there any reason you did that?
Confirmed: leaving "NO_USE_QTDEBUG = 1" commented, everything is ok.
Now the question: will you update the patch, or I keep it only locally?
did you try the current patch with the PYTHON=python2 option?Not yet, trying it now.
Tried with this. It creates inis, but it only seems to save the cfgs if you actually quit out rather than select a new game. It also seems to ignore the cfgs when loading.
Something is most definitely up with it.
Tried with GroovyMAME and GroovyUME. MAME64 standard behaves sensibly.
Ok, I've uploaded new binaries. Hopefully the .cfg files should work properly again. Please check.
Yep, they work flawlessly now :) Thanks!
make: *** No rules to make target «obj/groovysdl64/osd/sdl/dview.o», needed for «obj/groovysdl64/libosd.a». Stop.15625-15800,49.50-60.50,2.000,4.700,8.000,0.064,0.160,1.056,0,0,192,288,448,576Parsing mame.ini
Parsing mame.ini
Parsing mame.ini
Parsing mame.ini
Optional device 'sub3' not found
Optional device 'samples' not found
Optional device 'sub3' not found
Optional device 'samples' not found
Optional device 'sub3' not found
Optional device 'samples' not found
Optional device 'sub3' not found
Optional device 'samples' not found
Optional device 'sub3' not found
Optional device 'samples' not found
Optional device 'sub3' not found
Optional device 'samples' not found
Optional device 'sub3' not found
Optional device 'samples' not found
SwitchRes: missing parameter in user modeline
1
SwitchRes: Monitor range 15625.00-15800.00,49.50-60.50,2.000,4.700,8.000,0.064,0.160,1.056,0,0,192,288,448,576
SwitchRes: Monitor: custom Orientation: vertical Modeline generation: enabled
SwitchRes: Found output connector 'VGA-0'
SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015:[galaga] Calculating best video mode for 224x288@60.606060 orientation: rotated
SwitchRes: ( 1)x( 1)_(60=0.0000Hz)
rng(0): 400 x 288_51.299p 15.800 [integ] scale(1, 1, 1) diff(0.00, 0.00, -9.3074) ratio(1.786, 1.000)
SwitchRes: [galaga] (1) vertical (224x288@60.61)->(400x288@51.30)
rng(0): 400 x 288_51.299p 15.800 [integ] scale(1, 1, 1) diff(0.00, 0.00, -9.3074) ratio(1.786, 1.000)
SwitchRes: Modeline "400x288_60 15.80KHz 51.30Hz" 8.22 400 416 456 520 288 289 292 308 -hsync -vsync
SwitchRes: Running 'xrandr --newmode "400x288_51.30" 8.22 400 416 456 520 288 289 292 308 -hsync -vsync'
SwitchRes: Running 'xrandr --addmode VGA-0 "400x288_51.30"'
SwitchRes: Setting option -rotate
SwitchRes: Setting option -noror
SwitchRes: Setting option -noautoror
SwitchRes: Setting option -norol
SwitchRes: Setting option -noautorol
SwitchRes: Setting option -noblack_frame_insertion
SwitchRes: Setting option -multithreading
SwitchRes: Setting option -nosyncrefresh
SwitchRes: Setting option -nowaitvsync
SwitchRes: Setting option -keepaspect
SwitchRes: Setting option -nounevenstretch
SwitchRes: Setting option -nofilter
SwitchRes: Setting option -prescale 1
Build version: 0.151 (Nov 29 2013)
Build architecure: SDLMAME_ARCH=
Build defines 1: SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1
Build defines 1: LSB_FIRST=1 PTR64=1 DISTRO=generic SYNC_IMPLEMENTATION=tc
SDL/OpenGL defines: SDL_COMPILEDVERSION=1215 USE_OPENGL=1 USE_DISPATCH_GL=1
Compiler defines A: __GNUC__=4 __GNUC_MINOR__=8 __GNUC_PATCHLEVEL__=2 __VERSION__="4.8.2"
Compiler defines B: __amd64__=1 __x86_64__=1 __unix__=1
Compiler defines C: __USE_FORTIFY_LEVEL=0
SDL Device Driver : x11
SDL Monitor Dimensions: 768 x 576
Enter sdlwindow_init
Using SDL single-window OpenGL driver (SDL 1.2)
Leave sdlwindow_init
Loaded opengl shared library: <default>
OpenGL: X.Org
OpenGL: Gallium 0.4 on AMD RS780
OpenGL: 2.1 Mesa 9.1.7
OpenGL: texture rectangle supported
OpenGL: non-power-of-2 textures supported (new method)
OpenGL: vertex buffer supported
OpenGL: pixel buffers supported
OpenGL: framebuffer object supported
OpenGL: GLSL supported, but disabled
OpenGL: max texture size 8192 x 8192
Keyboard: Start initialization
Input: Adding Kbd #0: System keyboard
Keyboard: Registered System keyboard
Keyboard: End initialization
Mouse: Start initialization
Input: Adding Mouse #0: System mouse
Mouse: Registered System mouse
Mouse: End initialization
Joystick: Start initialization
Joystick: End initialization
Audio: Start initialization
Audio: Driver is alsa
Audio: frequency: 48000, channels: 2, samples: 1024
sdl_create_buffers: creating stream buffer of 114688 bytes
Audio: End initialization
output: unable to open output notifier file /tmp/sdlmame_out
Region ':maincpu' created
Region ':sub' created
Region ':sub2' created
Region ':gfx1' created
Region ':gfx2' created
Region ':proms' created
Region ':namco' created
Region ':51xx:mcu' created
Region ':54xx:mcu' created
Searching font Liberation Sans in -fontpath
Matching font: /usr/share/fonts/TTF/LiberationSans-Regular.ttf
Starting Galaga (Namco rev. B) ':'
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
(missing dependencies; rescheduling)
Starting Z80 ':maincpu'
Starting Z80 ':sub'
Starting Z80 ':sub2'
Starting Namco 51xx ':51xx'
Starting MB8843 ':51xx:mcu'
Starting Namco 54xx ':54xx'
Starting MB8844 ':54xx:mcu'
Starting Namco 06xx ':06xx'
Starting Video Screen ':screen'
Starting Speaker ':mono'
(missing dependencies; rescheduling)
Starting Namco ':namco'
Starting DISCRETE ':discrete'
Starting Galaga (Namco rev. B) ':'
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
(missing dependencies; rescheduling)
Starting Speaker ':mono'
Starting Galaga (Namco rev. B) ':'
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
OpenGL: VBO supported
OpenGL: PBO supported
OpenGL: FBO supported
OpenGL: using vid filter: 0
GL texture: copy 1, shader 0, dynamic 1, 288x224 288x224 [PALETTE16, Equal: 0, Palette: 1,
scale 1x1, border 0, pitch 384,288/8192], colors: 576, bytes/pix 4
GL texture: copy 1, shader 0, dynamic 1, 288x224 288x224 [PALETTE16, Equal: 0, Palette: 1,
scale 1x1, border 0, pitch 384,288/8192], colors: 576, bytes/pix 4
GL texture: copy 1, shader 0, dynamic 1, 288x224 288x224 [PALETTE16, Equal: 0, Palette: 1,
scale 1x1, border 0, pitch 384,288/8192], colors: 576, bytes/pix 4
GL texture: copy 1, shader 0, dynamic 1, 288x224 288x224 [PALETTE16, Equal: 0, Palette: 1,
scale 1x1, border 0, pitch 384,288/8192], colors: 576, bytes/pix 4
Parsing mame.ini
Parsing mame.ini
Parsing nbahangt.ini
Parsing mame.ini
Parsing mame.ini
Parsing nbahangt.ini
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional device 'adpcm' not found
Optional device 'cvsd' not found
SwitchRes: missing parameter in user modeline
1
SwitchRes: Monitor range 15625.00-15800.00,49.50-60.50,2.000,4.700,8.000,0.064,0.160,1.056,0,0,192,288,448,576
SwitchRes: Monitor: custom Orientation: horizontal Modeline generation: enabled
SwitchRes: Found output connector 'VGA-0'
SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015:[nbahangt] Calculating best video mode for 399x253@54.815170 orientation: normal
SwitchRes: ( 1)x( 1)_(60=0.0000Hz)
rng(0): 400 x 253_54.815p 15.677 [integ] scale(1, 1, 1) diff(0.00, 0.00, 0.0000) ratio(1.000, 1.000)
SwitchRes: [nbahangt] (1) horizontal (399x253@54.82)->(400x253@54.82)
rng(0): 400 x 253_54.815p 15.677 [integ] scale(1, 1, 1) diff(0.00, 0.00, 0.0000) ratio(1.000, 1.000)
SwitchRes: Modeline "400x253_60 15.68KHz 54.82Hz" 8.15 400 416 456 520 253 261 264 286 -hsync -vsync
SwitchRes: Running 'xrandr --newmode "400x253_54.82" 8.15 400 416 456 520 253 261 264 286 -hsync -vsync'
SwitchRes: Running 'xrandr --addmode VGA-0 "400x253_54.82"'
SwitchRes: Setting option -rotate
SwitchRes: Setting option -noror
SwitchRes: Setting option -autoror
SwitchRes: Setting option -norol
SwitchRes: Setting option -noautorol
SwitchRes: Setting option -noblack_frame_insertion
SwitchRes: Setting option -multithreading
SwitchRes: Setting option -syncrefresh
SwitchRes: Setting option -waitvsync
SwitchRes: Setting option -keepaspect
SwitchRes: Setting option -nounevenstretch
SwitchRes: Setting option -nofilter
SwitchRes: Setting option -prescale 1
Build version: 0.151 (Nov 29 2013)
Build architecure: SDLMAME_ARCH=
Build defines 1: SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1
Build defines 1: LSB_FIRST=1 PTR64=1 DISTRO=generic SYNC_IMPLEMENTATION=tc
SDL/OpenGL defines: SDL_COMPILEDVERSION=1215 USE_OPENGL=1 USE_DISPATCH_GL=1
Compiler defines A: __GNUC__=4 __GNUC_MINOR__=8 __GNUC_PATCHLEVEL__=2 __VERSION__="4.8.2"
Compiler defines B: __amd64__=1 __x86_64__=1 __unix__=1
Compiler defines C: __USE_FORTIFY_LEVEL=0
SDL Device Driver : x11
SDL Monitor Dimensions: 768 x 576
Enter sdlwindow_init
Using SDL single-window OpenGL driver (SDL 1.2)
Leave sdlwindow_init
Loaded opengl shared library: <default>
OpenGL: X.Org
OpenGL: Gallium 0.4 on AMD RS780
OpenGL: 2.1 Mesa 9.1.7
OpenGL: texture rectangle supported
OpenGL: non-power-of-2 textures supported (new method)
OpenGL: vertex buffer supported
OpenGL: pixel buffers supported
OpenGL: framebuffer object supported
OpenGL: GLSL supported, but disabled
OpenGL: max texture size 8192 x 8192
Keyboard: Start initialization
Input: Adding Kbd #0: System keyboard
Keyboard: Registered System keyboard
Keyboard: End initialization
Mouse: Start initialization
Input: Adding Mouse #0: System mouse
Mouse: Registered System mouse
Mouse: End initialization
Joystick: Start initialization
Joystick: End initialization
Audio: Start initialization
Audio: Driver is alsa
Audio: frequency: 48000, channels: 2, samples: 1024
sdl_create_buffers: creating stream buffer of 114688 bytes
Audio: End initialization
output: unable to open output notifier file /tmp/sdlmame_out
Region ':dcs' created
Region ':maincpu' created
Region ':gfxrom' created
Searching font Liberation Sans in -fontpath
Matching font: /usr/share/fonts/TTF/LiberationSans-Regular.ttf
Starting NBA Hangtime (rev L1.1 04/16/96) ':'
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
(missing dependencies; rescheduling)
Starting TMS34010 ':maincpu'
Starting NVRAM ':nvram'
Starting Video Screen ':screen'
Starting ADSP-2105 ':dcs'
Starting Timer ':dcs_reg_timer'
Starting Timer ':dcs_int_timer'
Starting Speaker ':mono'
(missing dependencies; rescheduling)
Starting DMA-driven DAC ':dac'
Starting NBA Hangtime (rev L1.1 04/16/96) ':'
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
(missing dependencies; rescheduling)
Starting Speaker ':mono'
Starting NBA Hangtime (rev L1.1 04/16/96) ':'
Optional device 'adpcm' not found
Optional device 'cvsd' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram2' not found
Optional shared pointer 'paletteram' not found
OpenGL: VBO supported
OpenGL: PBO supported
OpenGL: FBO supported
OpenGL: using vid filter: 0
GL texture: copy 1, shader 0, dynamic 1, 399x253 399x253 [PALETTE16, Equal: 0, Palette: 1,
scale 1x1, border 0, pitch 512,399/8192], colors: 32768, bytes/pix 4
SwitchRes: Resolution change from 399x253@54.815170 to 400x254@54.706841
GL texture: copy 1, shader 0, dynamic 1, 400x254 400x254 [PALETTE16, Equal: 0, Palette: 1,
scale 1x1, border 0, pitch 512,400/8192], colors: 32768, bytes/pix 4
GL texture: copy 1, shader 0, dynamic 1, 400x254 400x254 [PALETTE16, Equal: 0, Palette: 1,
scale 1x1, border 0, pitch 512,400/8192], colors: 32768, bytes/pix 4Has anyone compiled this with the cave driver allready?
Yes it compiles and works with the cave diff file mentioned in the post by blontic.
Trying to compile with "PYTHON=python2 OPTIMIZE=2 TARGET=mame":Code: [Select]make: *** No rules to make target «obj/groovysdl64/osd/sdl/dview.o», needed for «obj/groovysdl64/libosd.a». Stop.
Conclusion: my system need the qt-debug stuff, otherwise it goes crazy.
It could be interesting know if I'm the only one with this issue.
make NOWERROR=1 OPTIMIZE=2 PYTHON=python2You uncommented "NO_USE_QTDEBUG = 1" into "src/osd/sdl/sdl.mak" and this makes my system go crazy.
Now I have re-commented "NO_USE_QTDEBUG = 1" and trying to recompile.
Has anyone compiled this with the cave driver allready?
Yes it compiles and works with the cave diff file mentioned in the post by blontic.
Thanks! What cave diff file did you use and what order did you patch?
-Jim
Ansa, you're probably using the old mame.ini. You need to create a new one for this version. Now -modeline option is no longer a boolean, but a string, that's what GM is complaining about.You right, my bad.
Now i set "modeline" to "auto", but roms still display at reduced size.
Is there any test and/or configuration change I can do, while Ves update GroovyArcade packages?
#
# CORE STATE/PLAYBACK OPTIONS
#
state
autosave 0
playback
record
mngwrite
aviwrite
wavwrite
snapname %g/%i
snapsize auto
snapview internal
statename %g
burnin 0
#
# CORE PERFORMANCE OPTIONS
#
autoframeskip 0
frameskip 0
seconds_to_run 0
throttle 1
syncrefresh 1
sleep 0
speed 1.0
refreshspeed 0
#
# CORE ROTATION OPTIONS
#
rotate 1
ror 0
rol 0
autoror 0
autorol 0
flipx 0
flipy 0
#
# CORE ARTWORK OPTIONS
#
artwork_crop 0
use_backdrops 0
use_overlays 0
use_bezels 0
use_cpanels 0
use_marquees 0
#
# CORE SCREEN OPTIONS
#
brightness 1.0
contrast 1.0
gamma 1.0
pause_brightness 0.85
effect none
#
# CORE VECTOR OPTIONS
#
antialias 1
beam 1.0
flicker 0
#
# CORE SOUND OPTIONS
#
sound 1
samplerate 48000
samples 1
volume 0
#
# CORE INPUT OPTIONS
#
coin_lockout 1
ctrlr
mouse 1
joystick 1
lightgun 0
multikeyboard 0
multimouse 0
steadykey 0
ui_active 0
offscreen_reload 0
joystick_map auto
joystick_deadzone 0.0
joystick_saturation 0.85
natural 0
joystick_contradictory 0
coin_impulse 0
#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device mouse
adstick_device mouse
pedal_device mouse
dial_device mouse
trackball_device mouse
lightgun_device mouse
positional_device keyboard
mouse_device mouse
#
# CORE DEBUGGING OPTIONS
#
log 0
verbose 0
update_in_pause 0
debug 0
debugscript
debug_internal 0
#
# CORE MISC OPTIONS
#
drc 1
drc_use_c 0
bios
cheat 0
skip_gameinfo 1
uifont default
ramsize
confirm_quit 0
ui_mouse 0
autoboot_command
autoboot_delay 2
autoboot_script
http 0
http_port 8080
http_path web
#
# CORE MKChamp OPTIONS
#
disable_hiscore_patch 0
disable_nagscreen_patch 0
disable_loading_patch 0
#
# CORE SWITCHRES OPTIONS
#
modeline_generation 1
#monitor pal
monitor custom
orientation horizontal
connector auto
interlace 1
doublescan 1
cleanstretch 0
changeres 1
powerstrip 0
lock_system_modes 1
lock_unsupported_modes 1
refresh_dont_care 0
dotclock_min 0
sync_refresh_tolerance 2.0
frame_delay 0
black_frame_insertion 0
modeline auto
ps_timing auto
lcd_range auto
crt_range0 15625-15800,49.50-60.50,2.000,4.700,8.000,0.064,0.160,1.056,0,0,192,288,448,576
crt_range1 auto
crt_range2 auto
crt_range3 auto
crt_range4 auto
crt_range5 auto
crt_range6 auto
crt_range7 auto
crt_range8 auto
crt_range9 auto
#
# DEBUGGING OPTIONS
#
oslog 0
watchdog 0
#
# PERFORMANCE OPTIONS
#
multithreading 1
numprocessors 2
sdlvideofps 0
bench 0
#
# VIDEO OPTIONS
#
video opengl
numscreens 1
window 0
maximize 0
keepaspect 0
unevenstretch 0
centerh 1
centerv 1
waitvsync 1
scalemode none
#
# OpenGL-SPECIFIC OPTIONS
#
filter 0
prescale 1
gl_forcepow2texture 0
gl_notexturerect 0
gl_vbo 1
gl_pbo 1
gl_glsl 0
gl_glsl_filter 0
glsl_shader_mame0 none
glsl_shader_mame1 none
glsl_shader_mame2 none
glsl_shader_mame3 none
glsl_shader_mame4 none
glsl_shader_mame5 none
glsl_shader_mame6 none
glsl_shader_mame7 none
glsl_shader_mame8 none
glsl_shader_mame9 none
glsl_shader_screen0 none
glsl_shader_screen1 none
glsl_shader_screen2 none
glsl_shader_screen3 none
glsl_shader_screen4 none
glsl_shader_screen5 none
glsl_shader_screen6 none
glsl_shader_screen7 none
glsl_shader_screen8 none
glsl_shader_screen9 none
gl_glsl_vid_attr 0
#
# PER-WINDOW VIDEO OPTIONS
#
screen auto
aspect auto
resolution auto
view auto
screen0 auto
aspect0 auto
resolution0 auto
view0 auto
screen1 auto
aspect1 auto
resolution1 auto
view1 auto
screen2 auto
aspect2 auto
resolution2 auto
view2 auto
screen3 auto
aspect3 auto
resolution3 auto
view3 auto
#
# FULL SCREEN OPTIONS
#
switchres 1
useallheads 0
#
# SOUND OPTIONS
#
audio_latency 3
#
# SDL KEYBOARD MAPPING
#
keymap 0
keymap_file $HOME/keymap.dat
uimodekey auto
#
# SDL JOYSTICK MAPPING
#
joy_idx1 auto
joy_idx2 auto
joy_idx3 auto
joy_idx4 auto
joy_idx5 auto
joy_idx6 auto
joy_idx7 auto
joy_idx8 auto
sixaxis 0
#
# SDL LOWLEVEL DRIVER OPTIONS
#
videodriver auto
audiodriver auto
gl_lib auto
The only noticeable difference from the user's perspective is the -triplebuffer case. Now -triplebuffer only works with multithreading enabled, because it doesn't make sense to enable it without multithreading. As a consequence, games where -triplebuffer was being chosen by GM, now will be using -syncrefresh by default. A typical case is vertical games like Pac-man of Galaga on a standard horizontal arcade monitor. These games will run with an important slowdown, due to the low refresh rate induced by running at 288p. In order to get it back to it's normal speed, -multithreading must be enabled. This way, -triplebuffer will be selectable internally by GroovyMAME and the game speed will be independent from the screen refresh, making it possible to run this game at 100% speed.I'm not sure to understand a 100%, so if I'm playing a lot of shmup with 90° rotation, I have to use the triplebuffer/multithread instead of syncrefresh?
It turned out that I was missing a patch for sdl.
Recompiled sdl with xrandr patch and now everything works as expected.
So finally it was this patch which made the trick: 1xrand.diff ?Yes.
Direct3D: Error 88760868 during device present call
Direct3D: resetting device
This error usually means the window which holds D3D has lost the focus for some reason. I have no idea how this could be influenced by Aero. Probably this won't help, but try deleting the files from the .cfg folder.
Luckily I found what the issue was.
xsetroot -cursor /home/full/path/emptycursor /home/full/path/emptycursor
#define nn1_width 16
#define nn1_height 16
static unsigned char nn1_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
Ok Ansa, thanks for testing this. I should update the diff keeping the "NO_USE_QTDEBUG = 1" commented out.
If you have any plans of making the Linux binaries available let us know, as we still don't have them in the Google site.
The main patch can be kept as is, because (hopefully) in next mame release, they have fixed that bug.
Until then, here is an updated patch for 0.151.
Confirmed. It's a bug due to GM saving the current modeline to .cfg. If you remove the part between "" in the modeline in the .cfg file, the config is loaded right.Is this bug fixed?
Confirmed. It's a bug due to GM saving the current modeline to .cfg. If you remove the part between "" in the modeline in the .cfg file, the config is loaded right.Is this bug fixed?
Why am i getting this error message in the dos prompt after loading a rom...
SwitchRes: Failed opening System\CurrentControlSet\Control\Video\{061F8C1F-6DE8-
41E7-9C93-31C22EC5DA29}\0000 registry entry
the game seems to run fine how ever, its obviously related to switchres
You're probably running this in W7? GroovyMAME needs admin rights to access the registry, otherwise it will prompt that error. If you're using an LCD (no custom modelines) you can ignore that error.
I'm using Windows 8 (don't judge lol), so if I open up a command prompt window as administrator will I still get this message?
I have been unable to display Mortal Kombat in a 4:3 aspect ratio because integer scaling is being applied.
$ cvt 1366 768 59.185606
# 1368x768 59.08 Hz (CVT) hsync: 47.09 kHz; pclk: 84.00 MHz
Modeline "1368x768_59.19" 84.00 1368 1440 1576 1784 768 771 781 797 -hsync +vsync
$ xrandr --newmode "1368x768_59.19" 84.00 1368 1440 1576 1784 768 771 781 797 -hsync +vsync
$ xrandr
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 32767 x 32767
eDP1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 256mm x 144mm
1366x768 60.0*+
1024x768 60.0
800x600 60.3 56.2
640x480 59.9
HDMI1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
1368x768_59.19 (0xc8) 84.0MHz
h: width 1368 start 1440 end 1576 total 1784 skew 0 clock 47.1KHz
v: height 768 start 771 end 781 total 797 clock 59.1Hz
$ xrandr --addmode VIRTUAL1 1368x768_59.19
$ xrandr
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 32767 x 32767
eDP1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 256mm x 144mm
1366x768 60.0*+
1024x768 60.0
800x600 60.3 56.2
640x480 59.9
HDMI1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 connected (normal left inverted right x axis y axis)
1368x768_59.19 59.1
VIRTUAL2 disconnected (normal left inverted right x axis y axis)
$ xrandr --output VIRTUAL1 --mode 1368x768_59.19
$ xrandr
Screen 0: minimum 320 x 200, current 1368 x 768, maximum 32767 x 32767
eDP1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 256mm x 144mm
1366x768 60.0*+
1024x768 60.0
800x600 60.3 56.2
640x480 59.9
HDMI1 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 connected 1368x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1368x768_59.19 59.1*
VIRTUAL2 disconnected (normal left inverted right x axis y axis)
$ ./mame64 mk3.zip
Average speed: 109.66% (82 seconds)
$ ./mame64 mk3.zip
Average speed: 109.68% (17 seconds)
For example, "Rygar" (256x224) scales 6, 5 when I'd like it to scale 5, 5 while of course Rastan (320x240) scales 5, 5. Can I accomplish this across the board for all games?
Hi Calamity, I'd love to know if you implemented the last revisions (with all the files that belongs to it) of HLSL from the official MAME 152 build?
As far as I understand, (6,5) is the correct integer scaling for 256x224 on your screen resolution.Ah, you're right of course. Thanks for clarifying, I see it now.
In XP64 w/crt_emudriver, is it normal GM behavior to display a blurry menu? In GA menu looks as usual, i.e. like a std mame on a std monitor. This no big deal but if there's a fix...
Have you tried running it in a fresh folder (no .cfgs)?
Once all that is fixed I'll post the binaries as usual.Hope to see posted also the patch :) .
google code site does not allow to create any new downloads anymoreWhat a shame.
Ok I think I found the problem, I've uploaded the fixed files here: http://forum.arcadecontrols.com/index.php/topic,135823.msg1432055.html#msg1432055 (http://forum.arcadecontrols.com/index.php/topic,135823.msg1432055.html#msg1432055)
It seems the hiscore.c file works if I change the 'global_free' calls for 'global_free_array'.
the google code site does not allow to create any new downloads anymore, that's why I'm not uploading the diffs there, we'll need to use google drive or something else from now on.
- Now when using interlaced modes in Windows 7 -video ddraw is automatically selected, in order to avoid the refresh rate being halved.Thanks Calamity..
Thanks Calamity..
1 question... how does this option go with the switching issue in windows 7 with DDraw?
Doesn't cause the issue, due to switching from D3D to DDraw? (bypassing the switching issue)
Oh damn, I thought that had been fixed. May you pass a log please?Added log to above while you were replying :)
BTW: are you running it with admin rights?
Not sure if it's just my machine or not... but mame .153 won't run on it's own.. it gives a 'failed to initialize ddraw' error..
run it with a game (mame.exe galaga) it starts fine...
Mame .152 when run on it's own gives the old 'menu'
Just one other question regarding the change. Are we able to select ddraw in mame.ini so we can use that mode for all games or should we still have it set to d3d? Does your Win 7 fix only apply to interlaced games?
Sorry for the dumb question. :)
Just one other question regarding the change. Are we able to select ddraw in mame.ini so we can use that mode for all games or should we still have it set to d3d? Does your Win 7 fix only apply to interlaced games?
Sorry for the dumb question. :)
Yes, you can set ddraw in mame.ini and apply it to all games.
The W7 fix applies to both progressive & interlaced games. However, it only forces ddraw for interlaced games, in order to solve the half speed issue.
Seems to be ok for me...Just one other question regarding the change. Are we able to select ddraw in mame.ini so we can use that mode for all games or should we still have it set to d3d? Does your Win 7 fix only apply to interlaced games?
Sorry for the dumb question. :)
Yes, you can set ddraw in mame.ini and apply it to all games.
The W7 fix applies to both progressive & interlaced games. However, it only forces ddraw for interlaced games, in order to solve the half speed issue.
Oh ok. Thats interesting because I set it ddraw and it wont start. Get the initializing error again.
Ok heres the deal. I have set mame to run as admin. If I set d3d in ini file than all games work including interlaced. If I set ddraw in ini file then progressive games don't work but interlaced DO work.
Hi,
is there any way to disable SwitchRes?
I've put "modeline_generation" to 0 in mame.ini, but I get the "could not find a video mode" error.
Thanks
Set "switchres" to "0".
That sounds like you either didn't create mame.ini through GroovyMAME with the -cc param, or you're running this on a non-15 kHz setup? If it's the later, you need to edit the 'monitor' option with a suitable monitor type (i.e. lcd, if you're using a laptop).Hi Calamity and thanks for your answer.
Setting modeline_generation to 0 forces GroovyMAME to treat your modelines as read-only. But SwitchRes can't be disabled, because all the logic still must pass through it.
Hi Calamity and thanks for your answer.
Yes, I've created mame.ini with the -cc parameter and I'm using a 15KHz arcade monitor. I have a standard ati driver with many custom fine tuned 15khz modelines (I've Always disabled the modelines generation because I prefer manual resolution/refresh management).
With groovymame 0.149 I don't have this problem.
Done some test, sadly switchres now doesn't pick the best resolution (right res, but wrong Hz):
Switchres: [ 42] 401x 256 @ 54: DALDTMCRTBCD401x256x0x54 - Modeline "401x258_54 15.47KHz 54.48Hz" 8.03 401 420 460 519 258 261 264 284 -hsync -vsync)Switchres: [ 20] 320x 200 @ 60: DALDTMCRTBCD320x200x0x60 - Modeline "320x240_60 15.70KHz 59.91Hz" 6.53 320 329 385 416 240 242 245 262 -hsync -vsync## This is goldnaxe.ini ##
modeline "320x240_60 15.70KHz 59.91Hz" 6.53 320 329 385 416 240 242 245 262 -hsync -vsync
Did you get my PM in regards to an issue I'm having with triple buffering causing missing polygons and textures in Ridge Racer and Rave Racer and all vector games being very dark?
E:\EMULATORI\MAME>groovymame32_0153.015a.exe snowbros
SwitchRes: [snowbros] (1) horizontal (256x224@57.50)->(256x240@57.01)
Average speed: 99.16% (8 seconds)
E:\EMULATORI\MAME>groovymame32_0153.015b.exe snowbros
SwitchRes: [snowbros] (1) horizontal (256x224@57.50)->(256x240@57.01)
Average speed: 104.17% (10 seconds)
E:\EMULATORI\MAME>groovymame32_0149.014b.exe snowbros
SwitchRes: [snowbros] (1) horizontal (256x224@57.50)->(256x240@57.50)
Average speed: 99.93% (2 seconds)E:\EMULATORI\MAME>groovymame32_0153.015a.exe superman
SwitchRes: [superman] (1) horizontal (384x240@57.43)->(384x240@57.20)
Average speed: 98.71% (2 seconds)
E:\EMULATORI\MAME>groovymame32_0153.015b.exe superman
SwitchRes: [superman] (1) horizontal (384x240@57.43)->(384x240@57.20)
Average speed: 105.22% (3 seconds)
E:\EMULATORI\MAME>groovymame32_0149.014b.exe superman
SwitchRes: [superman] (1) horizontal (384x240@57.43)->(384x240@57.43)
Average speed: 100.00% (2 seconds)
- Your custom modelines will still be passed through the sanity check (hfreq, vfreq, etc.), this means that you need to use a monitor preset that is compatible with your modelines, otherwise they will be labelled as "out of range" and rejected.Is this also true with modeline generation set to 0?
When cloning your modeline list in my system, this is the preset that worked fine for me:Where have I to put this?
monitor custom
crt_range0 15700-16720, 49.50-65.00, 2.000, 4.700, 8.000, 0.064, 0.192, 1.024, 0, 0, 192, 288, 448, 576
Yep, Same result as me.Calamity, i just had another look, and the video modes chosen between the 2 versions change..
Did you get my PM in regards to an issue I'm having with triple buffering causing missing polygons and textures in Ridge Racer and Rave Racer and all vector games being very dark?
Hi sean_skroht, yes I saw your message. Although I'm not seeing it here, I'd say it's caused by the multithreading associated to triple buffering causing graphic glitches. You may try enabling -video d3d for these particular games, keeping triple buffering on (multithreading) so it will bypass the half frequency issue when using d3d. If this doesn't help, I guess there's nothing we can do about it.
Thank you for your suggestions. I was able to fix the issue by forcing -video d3d in Hyperspin paramaters for all games. Thanks for that mate.
Calamity, i just had another look, and the video modes chosen between the 2 versions change..
Maybe that's got something to do with asteroids looking so bad?
Things improved a lot, BTW there are some strange behaviours that I can't explain:
Hi Haggar,Ah, ok sry for that.
A couple of notes:
- Comparing 0.149 vs 0.153 is cheating because with 0.149 you have modeline generation enabled, so obviously the target refresh is achieved. If you enable modeline generation for 0.153 you'll get the exact same refresh... just forgot to mention this the other day :)
- It's very strange that GM runs snowbros at 104% when the it's actually picking a 57 Hz modeline. I'd suggest to repeat the test right after a fresh reboot without running any other version of GM before. I'll try to reproduce the problem here anyway.Ok, I'll try.
horizont.ini or whatever.
Is there a list somewhere of all the possible .ini files? I've been wondering for a while what the horizontal one was.
...starting with v0.153 Asteroids is reported as having refresh of 61.xx
Hi Haggar,Ah, ok sry for that.
A couple of notes:
- Comparing 0.149 vs 0.153 is cheating because with 0.149 you have modeline generation enabled, so obviously the target refresh is achieved. If you enable modeline generation for 0.153 you'll get the exact same refresh... just forgot to mention this the other day :)- It's very strange that GM runs snowbros at 104% when the it's actually picking a 57 Hz modeline. I'd suggest to repeat the test right after a fresh reboot without running any other version of GM before. I'll try to reproduce the problem here anyway.Ok, I'll try.
Thanks
E:\EMULATORI\MAME>groovymame32_0153.015b.exe butasan
SwitchRes: [butasan] (1) horizontal (256x240@54.00)->(256x240@54.00)
Average speed: 110.92% (9 seconds)
E:\EMULATORI\MAME>groovymame32_0153.015a.exe butasan
SwitchRes: [butasan] (1) horizontal (256x240@54.00)->(256x240@54.00)
Average speed: 100.01% (6 seconds)
Is there a list somewhere of all the possible .ini files? I've been wondering for a while what the horizontal one was.
You can check the code in emu_options::parse_standard_inis here: http://git.redump.net/mame/tree/src/emu/emuopts.c (http://git.redump.net/mame/tree/src/emu/emuopts.c)
- It's very strange that GM runs snowbros at 104% when the it's actually picking a 57 Hz modeline. I'd suggest to repeat the test right after a fresh reboot without running any other version of GM before. I'll try to reproduce the problem here anyway.Ok, I'll try.
Thanks
- It's very strange that GM runs snowbros at 104% when the it's actually picking a 57 Hz modeline. I'd suggest to repeat the test right after a fresh reboot without running any other version of GM before. I'll try to reproduce the problem here anyway.Ok, I'll try.
Thanks
When I run snowbros @ 60hz I get Average speed: 104.38%
So It sounds like it may be picking it, But not switching to it?
I've tried changing refresh rates through mame sliders controls. Forcing games with this issue at 60Hz they all run at 100%.
there's no brightness setting for Vector games?Calamity, i just had another look, and the video modes chosen between the 2 versions change..
Maybe that's got something to do with asteroids looking so bad?
Hi Sledge,
A different mode is picked because starting with v0.153 Asteroids is reported as having refresh of 61.xx. If you want GM to pick the old mode just let in know that the resulting frequency is acceptable:
crt_range0 15450.00-16250.00,50.00-65.00,3.910,4.700,6.850,0.190,0.191,1.018,0,0,192,288,448,576
Vector games look different probably because now DirectDraw is used insted D3D. Use the specific vector options to increase the beam width, brightness etc.
putting brightness 1.2 or 1.1 (under Core vector options) does make the screen brighter... but we just need the vector lines to be brighter rather than the whole screen?
yeah that does help a fair bit :)putting brightness 1.2 or 1.1 (under Core vector options) does make the screen brighter... but we just need the vector lines to be brighter rather than the whole screen?
Use the beam option.
http://forum.arcadecontrols.com/index.php/topic,118159.msg1254032.html#msg1254032 (http://forum.arcadecontrols.com/index.php/topic,118159.msg1254032.html#msg1254032)
One quick question before updating my romset: I've read in the past that the triple buffer option is managed automatically by GM.
I know that this option introduces massive lags to controls, is there a way to force it off and be sure that it will not be activated?
Thanks.
Can you provide a list of reccomended settings to get less lag as possible (mantaining v-sync on of course)?
Thanks.
Can you provide a list of reccomended settings to get less lag as possible (mantaining v-sync on of course)?
Check this: http://forum.arcadecontrols.com/index.php/topic,133194.msg1377633.html#msg1377633 (http://forum.arcadecontrols.com/index.php/topic,133194.msg1377633.html#msg1377633)
In the attached picture, you'll see the settings I was using.
So it's better using d3d instead of ddraw.
Is it normal that the font rendering when "orientation vertical" is set does the attached?
I've tried with multiple games and fonts, including the fallback font as pictured - all the same unusable scale.
For what I heard, cave sh3 games are very cpu-hungry, so it could be related to your hardware configuration.Yeah i just OC'd from 3.16Ghz to 3.8Ghz, and it went from a minimum of 52% to a minimum of 72% (demo play)
Is it normal that the font rendering when "orientation vertical" is set does the attached?
I've tried with multiple games and fonts, including the fallback font as pictured - all the same unusable scale.
Well that's not normal, or at least desirable. Please post a log, so I can use it to clone your system here and see why that happens.
(cleanstretch 2 also breaks vector games really well :lol )
Right, hangon - I'll take a picture, the ini, and the log of it.
Yes, I've seen very weird things with vector games lately. Have you tried it with -video ddraw?
I have a pending task regarding some aspect ratio & fonts issues, specially affecting SDL and -cleanstretch 2, which hopefully will get fixed soon, and probably looking inside this will help with with related problems like this one and the other one you posted.
Cool. Definitely some weird behaviour. Don't really want to pepper you with logs, but another one I just spotted. If I change the ini I posted to "orientation horizontal" then galaga88 and invaders appear rotated vertically on the screen but fractionally stretched (filtered).
ket is integer stretched. If I subsequently pass "-norotate" to galaga88, it appears in its natural orientation but it's running at 200%.
Have you tried the blitter delay thing?Yep.. made it perform worse.
http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Board=mamechat&Number=324467&Forum=All_Forums&Words=Tafoid&Match=Username&Searchpage=0&Limit=25&Old=allposts&Main=324445&Search=true#Post324467 (http://www.mameworld.info/ubbthreads/showflat.php?Cat=&Board=mamechat&Number=324467&Forum=All_Forums&Words=Tafoid&Match=Username&Searchpage=0&Limit=25&Old=allposts&Main=324445&Search=true#Post324467)
So, next step, how do I set the games up individually? If anyone wants to help me out with an example: I would like to use integer scaling to display Galaxian on my horizontal 1600x1200 LCD.
is there gonna to be a .154 compile of groovymame anytime soon?
Your few days are up!! ;)is there gonna to be a .154 compile of groovymame anytime soon?
Sure. 0.154 has been released today, give us a few days :)
Your few days are up!! ;)
lol
Got my .154 romset ready to go :)
Any major changes with the new version?
Seems the artwork folder was causing the issue even though I had it disabled in the .ini
Thanks. AUR packages updated
I had a few other questions/observations.
1) Punchout which is a two screen game displays both screens on one. but it looks squished,
2) Is there a way to display artwork for games like asteroids deluxe which had a background overlay while still maintain resolutions?
3) I am using d9800 as my monitor preset as there isn’t one for my bill labs model. I used the 9800 in the past as I was told they are close. I have posted specs of the monitor at the top of the thread. Not sure if we can add my monitors defaults to groovymame and add an entry for Billabs to groovymame.
4) I noticed I had vmmaker 1.3b. I tried using 1.3c . I replicated my settings from my 1.3b ini file but 1.3c doesn’t seem to work for me. It screws up most of my games like dkong for instance. I switched back to 1.3b but would like to know why. 1.3c makes dkong use 512x512 resolution.
5) I noticed in my old ini i used waitsync. Its off by default do I need to use? I noticed most games run at 99.7% speed. Any way to make them run at 100%? Any issues with games not being sync properly?
I had a few other questions/observations.
1) Punchout which is a two screen game displays both screens on one. but it looks squished,
2) Is there a way to display artwork for games like asteroids deluxe which had a background overlay while still maintain resolutions?
3) I am using d9800 as my monitor preset as there isn’t one for my bill labs model. I used the 9800 in the past as I was told they are close. I have posted specs of the monitor at the top of the thread. Not sure if we can add my monitors defaults to groovymame and add an entry for Billabs to groovymame.
4) I noticed I had vmmaker 1.3b. I tried using 1.3c . I replicated my settings from my 1.3b ini file but 1.3c doesn’t seem to work for me. It screws up most of my games like dkong for instance. I switched back to 1.3b but would like to know why. 1.3c makes dkong use 512x512 resolution.
5) I noticed in my old ini i used waitsync. Its off by default do I need to use? I noticed most games run at 99.7% speed. Any way to make them run at 100%? Any issues with games not being sync properly?
3) Can you point me to the specs, I can't find them. You could open a thread for your monitor. Basically creating specs depends on tests done on the user end that confirm that we're using the right timings.
4) You really need to use version 1.3c with newer versions of MAME. It won't read the new xml format otherwise. When you say you replicated to config did you just copy the .ini or you actually went through the new options? Pass me your .ini in another thread and I'll help you. It's working for everybody, there shouldn't be any problems.
Hi Calamity, Just looking at your new GM 0.154 diff.
Specifically relating to the change in scope to OPTION_SYNCREFRESH
Hi Calamity, Just looking at your new GM 0.154 diff.
Specifically relating to the change in scope to OPTION_SYNCREFRESH
Hi ozfalcon,
This patch has been there from the beginning and there's a very good reason to it. First just to clarify, the recent change in MAME has moved some options to the OSD_OPTION scope, but my understanding is that this has only been done to make them general for all osd implementations instead of having them defined in each of these implementations, which is a good thing. Anyway this doesn't change the fact that -syncrefresh is still defined in the osd side. And this is exactly the problem. IMHO, from a design point of view, -syncrefresh should have always been defined as a core option, just like -throttle is. This is necessary so that -syncrefresh can be accesed from the throttling function in emu\video.c, and so it can be decided whether the cpu clock should be used for waiting or we should just rely on the wait for vsync implementation instead. This is how things were indeed before v0.114, we're just restoring the previous functionality, just like it is still documented as working in the official docs. Then the actual code for vsync is implemented by the different osd modules and controlled by the -waitvsync option (had you ever wondered why there are two options -syncrefresh and -waitvsync for mostly the same thing?).
Calamity, This section has me confused. Can you explain why this line uses OSDOPTION_SYNCREFRESH ?
ie. What is the difference between OPTION_SYNCREFRESH and OSDOPTION_SYNCREFRESH here?
Calamity, This section has me confused. Can you explain why this line uses OSDOPTION_SYNCREFRESH ?
ie. What is the difference between OPTION_SYNCREFRESH and OSDOPTION_SYNCREFRESH here?
Oops, that's obviously an error, I missed that one, thanks for finding it. It should be OPTION_SYNCREFRESH, according to the logic explained above. It has always been right in the previous patches, but because MAME has changed some options in this version my patch was messed up, I'll fix this in a while.
Anyway this doesn't change the fact that -syncrefresh is still defined in the osd side. And this is exactly the problem. IMHO, from a design point of view, -syncrefresh should have always been defined as a core option, just like -throttle is.<UPDATED>
This is necessary so that -syncrefresh can be accesed from the throttling function in emu\video.c
// define machine_config_constructor here due to circular dependency
// between devices and the machine config
class machine_config;
typedef device_t * (*machine_config_constructor)(machine_config &config, device_t *owner, device_t *device);
AUR updated. https://aur.archlinux.org/packages/?SeB=m&K=cools
Hi ozfalcon,
Sorry for my late answer. Last couple of weeks have been crazy finishing stuff in order to get some holiday.
If you have a look at video.c you have this in the video_manager constructor:
m_syncrefresh(machine.options().sync_refresh())
The syncrefresh option is taken from there, then it's used internally by the class as m_syncrefresh, specifically in update_throttle is used to determine whether the function should exit immediately or not.
I'm going to fix the patches today, hopefully they'll be ready in a while.
diff -Nru old/emu/video.c src/emu/video.c
--- old/emu/video.c 2014-07-22 08:14:56.000000000 +1000
+++ src/emu/video.c 2014-08-09 22:50:15.042927000 +1000
@@ -86,6 +86,7 @@
m_overall_valid_counter(0),
m_throttled(machine.options().throttle()),
m_throttle_rate(1.0f),
+ m_syncrefresh(machine.options().sync_refresh()),
m_fastforward(false),
m_seconds_to_run(machine.options().seconds_to_run()),
m_auto_frameskip(machine.options().auto_frameskip()),
@@ -726,6 +727,9 @@
3,4,4,5,4,5,5,6, 4,5,5,6,5,6,6,7, 4,5,5,6,5,6,6,7, 5,6,6,7,6,7,7,8
};
+ // if we're only syncing to the refresh, bail now
+ osd_printf_verbose("(/emu/video.c/update_throttle) m_syncrefresh = %i \n", m_syncrefresh );
+
// outer scope so we can break out in case of a resync
while (1)
{
diff -Nru old/emu/video.h src/emu/video.h
--- old/emu/video.h 2014-07-22 08:21:56.000000000 +1000
+++ src/emu/video.h 2014-08-09 22:31:41.231600000 +1000
@@ -145,6 +145,7 @@
// configuration
bool m_throttled; // flag: TRUE if we're currently throttled
float m_throttle_rate; // target rate for throttling
+ bool m_syncrefresh; // flag: TRUE if we're currently refresh-synced
bool m_fastforward; // flag: TRUE if we're currently fast-forwarding
UINT32 m_seconds_to_run; // number of seconds to run before quitting
bool m_auto_frameskip; // flag: TRUE if we're automatically frameskipping
(The patch is really just to see the code inserted, Not actually to be compiled)$> ./mame xybots -verbose -throttle -nosyncrefresh
...
(/emu/video.c/update_throttle) m_syncrefresh = 0
Average speed: 100.00% (8 seconds)
$> ./mame xybots -verbose -throttle -syncrefresh
...
(/emu/video.c/update_throttle) m_syncrefresh = 1
Average speed: 100.00% (6 seconds)
AUR updated. https://aur.archlinux.org/packages/?SeB=m&K=cools
Whats AUR?
Sorry to be a noob, but will this be compatible with my 0.152b romset?Mostly
AUR updated. https://aur.archlinux.org/packages/?SeB=m&K=cools
Calamity, I've successfully applied the hiscore and groovymame patches to the 0.154 source. I've created mame.ini and I've configured it. I must say I'm testing this in a LCD monitor. I know it's not the perfect environment for GroovyMAME, but I'm interested in some features such as soundsync, etc. The problem I have is that I have not managed to get bilinear filtering by no means. I've tried many things with mame.ini. I've set the monitor line as lcd and I'm using d3d. With the standard MAME, there's no problem. What could I do?
Since I'm not interested in the modelines stuff, etc. could you please release a diff with the soundsync features alone? Or does the recent MAME releases already sync audio and video when the emulated game at 5? hz is forced to 60hz with syncrefresh?
I also like the idea of reduced input latency. Is it the same patch as this one?: http://www.systempixel.fr/extra/nobuffer/ (http://www.systempixel.fr/extra/nobuffer/)
I got it working.
Here's updated diff for v0.155, in case someone wants to roll his own binary. Bear in mind this is NOT tested. During this week (hopefully) I'll update the patch to include some pending fixes.
Has GM 0.155 got officially complied yet??
you MUST COMPLY !! :)Has GM 0.155 got officially complied yet??
No.
Here's updated diff for v0.155, in case someone wants to roll his own binary. Bear in mind this is NOT tested. During this week (hopefully) I'll update the patch to include some pending fixes.Any chance that includes a fix for the in-game menu not working when in vertical mode?
Any chance that includes a fix for the in-game menu not working when in vertical mode?
No worries. I ask about that particular issue because it's currently my biggest pain point in my latest setup. I'm getting ready to either try to fix it myself (which may be a really dumb idea :lol) or try to find a solid workaround. However, if it's going to be fixed in your next version, then I'll just wait.Any chance that includes a fix for the in-game menu not working when in vertical mode?
The reason for the delay on releasing this version is that I need some time to fix the existing issues (it will be Switchres 15c).
I spent a little time last night messing with the code and traced this bug down to ui_aspect() in emu/render.c. It was returning a value of 85 for me (which makes sense with the super resolution) and that was messing up all the calculations for how big to draw the box and characters. I just commented out the following lines to make it fallback to clamping the aspect ratio to 1.5, and now it works perfect for me. It's probably not the proper fix you'd want, but it works for me.No worries. I ask about that particular issue because it's currently my biggest pain point in my latest setup. I'm getting ready to either try to fix it myself (which may be a really dumb idea :lol) or try to find a solid workaround. However, if it's going to be fixed in your next version, then I'll just wait.Any chance that includes a fix for the in-game menu not working when in vertical mode?
The reason for the delay on releasing this version is that I need some time to fix the existing issues (it will be Switchres 15c).
// if we have a valid pixel aspect, apply that and return
// if (m_ui_target->pixel_aspect() != 0.0f)
// return aspect / m_ui_target->pixel_aspect();I'm having a little difficulty getting the "ps_timing" option working in GM 0.154.
Hi sean_skroht,
Unfortunately the logs in version 154 are broken so the information they show is limited. Please wait for the new version and test then. If it keeps failing at least the logs will be more informative.
Calamity: I have GM working with 240p or equivalent on my linux box. I am curious as to how to deal with interlaced resolutions (games like Popeye or Tekken 3), or with 480p or higher. I can post my CRT_specs0 line and post a pic or two if need-be.
Any release date for 0.155??
Still fighting with the Linux side...What's the problem? SDL2?
What's the problem? SDL2?
So SDL2 sucks more than SDL1 and we're back to a non portable Linux specific OSD? ;)
GroovyMAME/UME v0.155 - Switchres v0.1015c released.
- Support for rotated desktops (Windows & Linux).
- E.g. if you have your desktop rotated 90º, launch GroovyMAME like this: groovymame.exe 1942 -monitor vertical -aspect 3:4
("Magic" resolutions won't work with rotated desktops. If you're still using them we encourage you to move to "super" resolutions).
Is this a general recommendation for all GroovyMAME users to move to "super" resolutions going forward? Even those of us using XP x64?
UPDATE: H-Total of 450 is AVGA default. I did change it to 448 but it didn't do much except increase the reported h-frequency to 16859 (as you mentioned) from 16784 originally reported by switchres. Crt_range in phoenix.ini had to stay the same.
Is there any way to stop that or is it something I have to deal with because of the way Powerstrip works?
BTW it makes me happy that someone uses the PS feature, it was challenge to integrate it at the time.
Is this a general recommendation for all GroovyMAME users to move to "super" resolutions going forward? Even those of us using XP x64?
While you can keep your current setup if it's working fine for you and GM will support "magic" resolutions as long as possible, I see objective benefits in using "super" over "magic" resolutions, like perfect horizontal centering between resolutions.
For some reason, I was under the impression that super resolutions didn't work in XP.
Hi Calamity can i ask a paranoid question about super resolutions :)
because of the super wide horizontal resolution in use, do you think it would have any affect on lag/performance in any way, or is there really no extra overheads here and it's not really any different from using one of the other groovy options?
Maybe this was mentioned somewhere in the thread but I couldn't find it in the top post. I'd like to use the Groovy enhancements with MESS but you don't offer a mess compile only UME, however I can't seem to find an official release on mamedev.org for UME, only MESS.
Where should I get the official UME release to use as a base with the GroovyUME release?
I think I'm being misunderstood. I'm not looking for the source code. I'm looking for the official binary distribution, specifically all of the files OTHER than the .exeMaybe this was mentioned somewhere in the thread but I couldn't find it in the top post. I'd like to use the Groovy enhancements with MESS but you don't offer a mess compile only UME, however I can't seem to find an official release on mamedev.org for UME, only MESS.
Where should I get the official UME release to use as a base with the GroovyUME release?
Unless I'm mistaken, you just download the combined MAME/MESS source package from mamedev.org and build using: make TARGET=ume
I think I'm being misunderstood. I'm not looking for the source code. I'm looking for the official binary distribution, specifically all of the files OTHER than the .exe
GroovyMAME/UME v0.155 - Switchres v0.1015c released.
- Support for rotated desktops (Windows & Linux).
- E.g. if you have your desktop rotated 90º, launch GroovyMAME like this: groovymame.exe 1942 -monitor vertical -aspect 3:4
I'm assuming that GroovyMAME doesn't include the patch to add back support for cave shooters. That's fine but is there any known issues when compiling using both the GM diff and the cave shooter diff? I'd assume not but I'd figured I'd ask.
You shouldn't have to compile the Cave diff file into MAME as the Cave games have been supported in vanilla MAME since 0.152.oh really? I didn't realize they'd been added back in... thanks :cheers:
Calamity, you'll have your work cut out for you to keep upor he could just skip every other release, so that would mean 6 groovymame's a year.. or skip 2 of 3 releases, so that's 4 groovymame's a year.
Doing a simple patch resync (AKA: only fix hunk warnings/errors without implementing new features) in order to let us apply the old patch to newer release, shouldn't that stressful (IMHO).
Is the PS timing feature usable with 'super resolutions' ?UPDATE: H-Total of 450 is AVGA default. I did change it to 448 but it didn't do much except increase the reported h-frequency to 16859 (as you mentioned) from 16784 originally reported by switchres. Crt_range in phoenix.ini had to stay the same.
Yeah but that's the right value, the previous one was bogus.QuoteIs there any way to stop that or is it something I have to deal with because of the way Powerstrip works?
BTW it makes me happy that someone uses the PS feature, it was challenge to integrate it at the time.
Yes, apart from "monitor lcd" you need to change "aspect 16:9" or whatever aspect your LCD is.
Cool. So PowerStrip isnt really need anymore then?
One thing i have noticed and not sure if you know a fix, is say in triple screen game theres an new option now in the i game menu under video that has '3 screen Gapless' option. With HLSL disable then you do indeed get a gapless display but with HLSL enabled (and curvature and pincushion disabled) you get a very slight black line separating the screens. Do you know how to remove this when HLSL is enabled?
I've just checked latest mame git source and there are lots of changes. Both no nag/highscore and groovymame will require modifications :/
Is there a known issue with the 0.157 Win x64 binary? I notice the logs still reference SwitchRes v0.015d.
With regards to version 0.158: I won't be able to update in a week or two. Please be patient.
They've added a cross-platform rendering library called BGFX (https://github.com/bkaradzic/bgfx) to the MAME codebase.This looks like it could be good. ;D :dunno
23-vectordisplay
Rendering lines as oldschool vectors.
(https://github.com/bkaradzic/bgfx/raw/master/examples/23-vectordisplay/screenshot.png)
No hurry. I don't think there were any must-have changes in MAME 0.158 anyway.
In other news, have you looked at the MAME git repo lately? There appears to be some possibly major changes to the MAME rendering code.
They've added a cross-platform rendering library called BGFX (https://github.com/bkaradzic/bgfx) to the MAME codebase.
I'm don't know what, if anything, this means for the future of GroovyMAME, but I'm sure we'll find out come MAME 0.159
i've mame 0.155 and all the complete romset, chd files and extra
i would not to download everything for version 158 but i need groovymame and crt emuldrive: where i can find these softwares for 0.155 version?
GroovyMAME v0.159 is out.
Hi @Calamity,
I just installed GroovyArcade.
What do you need tested in Linux that I can do for you?
Hi,
I did a fresh compilation of GroovyUME 0.159 - SwitchRes v0.015f on a 64 bit groovvyarcade setup. I see a speed issue (50%) where 0.158_0.015f runs fine (100%). Options in ume.ini are identical for both.
Is someone else having the same issue?
Thanks Calamity!
I've read 0.159 windows native build now includes SDLMAME's OpenGL renderer.
Is this also enabled in GroovyMAME?
Any benefit compared to Direct3D?
You're probably the first one to test it. It was a nightmare to bypass the 50% speed issue back in 0.156 when SDL2 was introduced, it was required to use a drm call because sdl2/opengl seems to be designed to make proper vsync impossible. In this version they have moved several things around and probably my workaround is broken. It's going to be hard to keep this working until things settle down in the osd code. Last time it took me more than a week to get it working for the Linux side, this requires lots of tests each time a major change is done in mainline.
#ifndef OSD_WINDOWS
SDL_GL_SetSwapInterval(video_config.waitvsync ? 1 : 0);
#endif#ifndef OSD_WINDOWS
SDL_GL_SetSwapInterval((video_config.waitvsync && fd == 0) ? 1 : 0);
#endifSDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, (video_config.waitvsync && fd == 0) ? 1 : 0);SDL_GL_SetAttribute(SDL_GL_SWAP_CONTROL, 0);If you want to test, in /osd/sdl/drawogl.c, change:
Code: [Select]
#ifndef OSD_WINDOWS
SDL_GL_SetSwapInterval(video_config.waitvsync ? 1 : 0);
#endif
by
Code: [Select]
#ifndef OSD_WINDOWS
SDL_GL_SetSwapInterval((video_config.waitvsync && fd == 0) ? 1 : 0);
#endif
I know, I'm not blaming GroovyUME, but I do need to 'prepare' the roms for use with it. thanks anyway
GroovyMAME v0.161 is out.
(Major changes in mainline's "makefile" system in this version, I still need to check if it builds under Linux).
I have successfully compiled and executed the new binary under Linux. I will do some test the next days to see its behaviour.
Cyber Cycles is 15KHz interlaced, not 31KHz.
Emulation speed at 15kHz is 50% and 100% at 31kHz. The sound is distorted on both setups.
I'm tempted to update my groovymame from .15x to the latest .161. Can i just swap the exe files or do i have to do a complete reinstall from scratch?You should be able to just swap out the exe
GroovyMAME v0.162 is out.
As of 0.162 the MAME and MESS projects have been combined into a single emulator.
(So there's no need to release the GroovyUME binary anymore).
I am still compiling... but do you already know if ume.ini must be renamed to mame.ini?
Hi Doozer,
Thanks for the information. I'd appreciate if you could upload your 64-bit build somewhere so I can put it in the google site for download, as I'm out of time at the moment to make the Linux builds.
I have done nothing to fix the interlace issue, so the only thing I can think of if some change in mainline-sdl that has had this beneficial effect. Very good news after all.
Does SUBTARGET-arcade works with groovymame ?
make SUBTARGET=arcade
Does SUBTARGET-arcade works with groovymame ?
Hello Haynor666,
Yes, you can use this option to limit the build to arcade only drivers.Code: [Select]make SUBTARGET=arcade
Just one slightly related question though... Why is there such as difference in file size between the hiscore.diffs from this forum and the GM-hiscore.diffs that you release?
Hi calamity. I have a racing cab and would like a grooveymame version with the racer mame diffs. (http://racermame.altervista.org/download/racermame151.zip (http://racermame.altervista.org/download/racermame151.zip)). Could you provide a version? Thanks in advance.
Sent from my Nexus 5 using Tapatalk
Np. I will try contacting the author and if possible, I will try to build it myself
Sent from my Nexus 5 using Tapatalk
Np. I will try contacting the author and if possible, I will try to build it myself
Sent from my Nexus 5 using Tapatalk
Hey ArcadeBliss, can you let us know how you go with your build, please. I'd love to get Groovymame running in a driving cab with the RacerMAME diffs.
Np. I will try contacting the author and if possible, I will try to build it myself
Sent from my Nexus 5 using Tapatalk
Hey ArcadeBliss, can you let us know how you go with your build, please. I'd love to get Groovymame running in a driving cab with the RacerMAME diffs.
I was able to seperate out the RacerMame diffs from the hiscore diffs. I will set up a compile enviorment and have a go at it. this might take me a week or so. Just for reference, the tool "Beyond Compare 4" was great in allowing me to quickly visualize the patch contents. This allowed me to delete everything releated to the hiscore patch.
Looks like we don't have too much code changes this time - groovymame patch 162 still compiles with most recent git repository.
GroovyMAME v0.163 is out.
No changes in this version (just fixed the warning when about prescale when using HLSL and GLSL).
src/osd/sdl/switchres.c
< set_option_int_osd(machine, OSDOPTION_PRESCALE, min(3, min(best_mode->result.x_scale, best_mode->result.y_scale)));
---
> set_option_int_osd(machine, OSDOPTION_PRESCALE, (options.gl_glsl() || game->vector)? 1 : min(3, min(best_mode->result.x_scale, best_mode->result.y_scale)));
src/osd/windows/switchres.c
< set_option_int_osd(machine, OSDOPTION_PRESCALE, (options.d3d_hlsl_enable() || game->vector)? 0 : min(3, min(best_mode->result.x_scale, best_mode->result.y_scale)));
---
> set_option_int_osd(machine, OSDOPTION_PRESCALE, (options.d3d_hlsl_enable() || game->vector)? 1 : min(3, min(best_mode->result.x_scale, best_mode->result.y_scale)));
../../../../../src/osd/sdl/switchres.c: In function ‘bool switchres_modeline_setup(running_machine&)’:
../../../../../src/osd/sdl/switchres.c:248:72: error: ‘game’ was not declared in this scope
set_option_int_osd(machine, OSDOPTION_PRESCALE, (options.gl_glsl() || game->vector)? 1 : min(3, min(best_mode->result.x_scale, best_mode->result.y_scale)));
^
Version 0162 compiled fine but 0163 introduced an issue with the scope of the game variable.
Version 0162 compiled fine but 0163 introduced an issue with the scope of the game variable.
Oops! I couldn't test the linux build. Removing the " || game->vector" bit should fix it.
Yes, I took the same decision. Do you plan to update the diff file?
Yes, I took the same decision. Do you plan to update the diff file?
Yes. I didn't increase the version number because I felt the sort of change didn't deserve it, but maybe I should?
It would be nice in order to keep clean version history. If I can advise so.
It would be nice in order to keep clean version history. If I can advise so.
Ok that needs to rebuild the files so the proper switchres version is shown (the clifront.c file includes the switchres header).
sed -i 's/0.015g/0.015h/' groovymame
GroovyMAME v0.163 is out (Switchres v0.015h)
- Forced prescale value to 1 when using HLSL and GLSL filters. Avoids warnings and problems.
Applying Diff Patch...
patching file scripts/src/emu.lua
patching file scripts/src/osd/sdl.lua
patching file scripts/src/osd/sdl_cfg.lua
patching file scripts/src/osd/windows.lua
patching file src/emu/clifront.c
patching file src/emu/drivenum.c
patching file src/emu/drivers/empty.c
patching file src/emu/emu.h
patching file src/emu/emuopts.c
Hunk #3 succeeded at 195 (offset -1 lines).
patching file src/emu/emuopts.h
patching file src/emu/machine.c
patching file src/emu/machine.h
patching file src/emu/render.c
patching file src/emu/switchres/modeline.c
patching file src/emu/switchres/monitor.c
patching file src/emu/switchres/switchres.c
patching file src/emu/switchres/switchres.h
patching file src/emu/switchres/util.c
patching file src/emu/ui/selgame.h
patching file src/emu/ui/ui.c
Hunk #1 succeeded at 1263 (offset 19 lines).
patching file src/emu/video.c
Hunk #4 succeeded at 807 (offset 60 lines).
Hunk #6 succeeded at 1092 (offset 60 lines).
patching file src/emu/video.h
Hunk #2 succeeded at 149 (offset 3 lines).
patching file src/mame/drivers/galaxian.c
patching file src/mame/includes/galaxian.h
patching file src/osd/modules/lib/osdobj_common.c
patching file src/osd/modules/lib/osdobj_common.h
patching file src/osd/modules/osdwindow.h
patching file src/osd/modules/render/drawd3d.c
patching file src/osd/modules/render/drawdd.c
patching file src/osd/modules/render/drawogl.c
patching file src/osd/modules/sound/direct_sound.c
patching file src/osd/modules/sound/sdl_sound.c
patching file src/osd/osdepend.h
patching file src/osd/sdl/input.c
patching file src/osd/sdl/osdsdl.h
Hunk #2 FAILED at 148.
Hunk #3 succeeded at 172 (offset 3 lines).
1 out of 3 hunks FAILED -- saving rejects to file src/osd/sdl/osdsdl.h.rej
patching file src/osd/sdl/sdlmain.c
patching file src/osd/sdl/switchres.c
patching file src/osd/sdl/video.c
Hunk #2 succeeded at 662 (offset 29 lines).
patching file src/osd/sdl/window.c
Hunk #11 succeeded at 1332 (offset 62 lines).
patching file src/osd/sdl/window.h
Hunk #1 succeeded at 76 with fuzz 1 (offset 2 lines).
Hunk #3 succeeded at 127 (offset 2 lines).
patching file src/osd/windows/pstrip.c
patching file src/osd/windows/pstrip.h
patching file src/osd/windows/switchres.c
patching file src/osd/windows/video.c
Hunk #1 succeeded at 222 (offset 27 lines).
patching file src/osd/windows/window.c
Hunk #9 FAILED at 904.
1 out of 9 hunks FAILED -- saving rejects to file src/osd/windows/window.c.rej
missing header for unified diff at line 5678 of patch
can't find file to patch at input line 5678
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
| mtlog_add("winwindow_video_window_update: PostMessage end");
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
8 out of 8 hunks ignored
patching file src/osd/windows/window.h
Hunk #1 succeeded at 109 (offset 3 lines).
patching file src/osd/windows/winmain.c
patching file src/osd/windows/winmain.h
Finished!
0 Hours 0 Minutes and 1 Seconds Elapsed.
After getting a few errors with the new .163 diff which I fixed by removing the line break at either the line identified in the patch log, or the proceeding one, I'm getting the following output.
A guy who I built a version of GM.163 for tells me that he's also getting the 26 modeline issue when running VMmaker on that version. He's dropped back to an earlier one and its fine. Unfortunately I can't verify this as my CRT is away for repair. I appreciate you're busy with other things right now but if there's anything I can do to help diagnose this bug please let me know.
OK thanks for confirming that man. What about the build errors? Am I doing the right thing in just removing the line breaks for each error that get flags. It seems to build that way but unsure if I'm going to get problems with it later on as 162 built fine with the alternate diff you posted.
Build errors? Or patch errors?
You should be getting no patch errors with the --binary option.
I've totally missed the binary option, I'm using MC64, where is it please?
I'm getting patch errors, I posted the output that I'm getting using MC64 v2.0.163, and MAME 0163s a few posts back if it's any help.
C:\buildtools\src\mame0163s
λ patch -p0 -E --binary <c:\buildtools\patch\hi_0163.diff
patching file scripts/src/emu.lua
patching file src/emu/emuopts.c
patching file src/emu/emuopts.h
patching file src/emu/hiscore.c
patch: **** malformed patch at line 465: diff -Nru --binary src/emu/hiscore.h src/emu/hiscore.hAre you using the build tools from MAMEdev?
λ patch -p0 -E --binary <hi_0163.diff
patching file `scripts/src/emu.lua'
patching file `src/emu/emuopts.c'
patching file `src/emu/emuopts.h'
patching file `src/emu/hiscore.c'
patching file `src/emu/hiscore.h'
patching file `src/emu/machine.c'
patching file `src/emu/machine.h'
patching file `src/emu/mame.c'
patching file `src/emu/profiler.c'
patching file `src/emu/profiler.h'
patching file `src/emu/ui/ui.c'
λ patch -v
patch 2.5
Copyright 1988 Larry Wall
Copyright 1997 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of this program
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
written by Larry Wall with lots o' patches by Paul Eggert
Hi all. I was wondering a couple things:New video cards will not be supported for the foreseeable future due to windows limitations..
1.) Will there ever be an updated version of CRT_emudriver to be able to work with more recent video cards and windows 7 and up? (like vid cards with DX11 capabilities). I ask because some emulators require more than windows xp (which I'm currently using) to be able to run. If not, that's okay, but I'm wondering what are some of the technicalities/difficulties (besides time and money :-) ) that hinder the development.
2.) Do users compile groovymame themselves? I've always just got the builds from the download site. I ask because I was wondering if there was a way to compile a version without the popup messages from save states. For example, if one uses a save state in a game like Donkey Kong (I tested the A7800 version), where the character begins at the bottom of the screen, the savestate save and load messages obscure the bottom of the screen for 1-2 seconds hindering gameplay. Is it possible to remove the popup messages? I've seen another thread suggesting it is with normal builds of mame/mess, but I'm not sure with groovymame.Some people do, but there are also precompiled versions, but i'm not sure about the savestate popups as i never use them.
Thanks.
New video cards will not be supported for the foreseeable future due to windows limitations..
Well.. i wasn't.. but now you are lol :)New video cards will not be supported for the foreseeable future due to windows limitations..
They will. Hopefully after the summer. But let's don't anticipate things ;)
New video cards will not be supported for the foreseeable future due to windows limitations..
They will. Hopefully after the summer. But let's don't anticipate things ;)
I just can't believe how much better games play. The speed is right, the animation and scrolling is so smooth, and the input lag is almost non-existent. I don't think I can go back to emulating any other way.
This time I've post-processed the diff files to make sure they won't cause problems. Hopefully this will be the end of patch errors.
GroovyMAME v0.164 is out (Switchres v0.015h)
No new features.
This time I've post-processed the diff files to make sure they won't cause problems. Hopefully this will be the end of patch errors.
The 64bit Linux build is ready and available on the google drive.
The 64bit Linux build is ready and available on the google drive.
Thanks a lot Doozer!
GroovyMAME 0.167 is out (Switchres v0.015j).
What's new in SwitchRes v0.015j
- Direct3D9ex support [koopah, intealls] (new option: -video d3d9ex): now GroovyMAME supports Direct3D9ex, which is present in all versions of Windows starting with Vista. This allows the application to take control of the frame latency and force it to the minimum allowed by the driver, avoiding the dreaded frame queues. This is specially useful in the situations where frame_delay can't be used reliably without tearing (LCDs, high resolutions). Besides, Direct3D9ex seems to perform better for certain hardware (Nvidia, Intel), so it may be preferred to plain Direct3D9 in general.
- Frame delay (improved) [intealls, Calamity]: now frame_delay polls the video driver for absolute scanline values, totally bypassing the default vertical synchronization functions. Some of the advantages are:
- Improved stability of the vertical synchronization mechanism, that finally makes it possible to extend GroovyMAME's audio/video synchronization to the frame delay use case.
- Awareness of the raster position and notification of missed retraces.
- Allows for anticipating the vertical retrace accurately (see vsync_offset, below).
- Vsync offset [intealls] (new option: -vsync_offset): forces render to happen a certain number of lines before the vertical blank (e.g. -vsync_offset 200). At high resolutions (LCD, etc.), the time it takes the GPU to scale a frame starts being longer than the blanking period itself. This is specially true when HLSL is used. This appears as static tearing when frame_delay is used. To compensate this issue, vsync_offset forces the render code to be called a number of lines ahead of time. Ideally, using a proper value realigns the render completion with the end of the blanking period, cleanly removing all tearing, even on LCDs with frame_delay and HLSL enabled. In practice, you need a fairly fast card in order to fully remove tearing. The higher the tearing line appears on the screen initially, the faster your card is, and the more chances of completely hiding tearing through -vsync_offset. Notice that you'll need to lower your frame_delay value proportionally to the amount of lines you set in -vsync_offset.
The 64bit Linux builds are ready and available on the google drive.
Cheers
Thanks for releasing so quickly, Calamity. :applaud:
Do you have a development roadmap for future features in Groovymame that you care to share / disclose or is it all a big surprise for us?
For Windows XP users, however, Direct3D9ex is not an option, so you'll need to stick with Direct3D + frame delay in order to remove the frame queue + the last frame due to double buffering, as we did before and is explained in Recap's guide above.
Oh god, I'm afraid I've been a bit out of the loop.
So what's the ideal setup now? Isn't it WinXP + ddraw anymore? Win7 + Direct3D9ex is boss?
EDIT: and while we're at it... is multithreading now safe to use in GroovyMame?
I'll be using GM with a Radeon X300SE and a 15Khz sony BVM monitor without super resolutions or any enhancements.
Is it worth the hassle?
New video cards will not be supported for the foreseeable future due to windows limitations..
They will. Hopefully after the summer. But let's don't anticipate things ;)
This looks like a really exciting release! Well done and thank you! :)
Thanks for releasing so quickly, Calamity. :applaud:
Do you have a development roadmap for future features in Groovymame that you care to share / disclose or is it all a big surprise for us?
Basically adding support for newer ATI cards, when time permits.
It says in the main post:
"No software can control the VERTICAL size of a resolution on a CRT monitor, you need to adjust it physically (potentiometers, service menu, etc.)."
Does this mean that I have to adjust the pot for every game I start?
If your objective is to have perfect match for all games, indeed manual calibration will be required when frequency/vertical resolution changes.
groovymame32_0168.015k_linux.tar.bz2
groovymame32_0168.015k_wiimote_linux.tar.bz2
groovymame64_0168.015k_linux.tar.bz2
groovymame64_0168.015k_wiimote_linux.tar.bz2
I'm trying to update my groovymame cab from 0.151 to 0.166 and keep running into crashing issues, I must be missing something.
(No more switchres updates. The version number is perfect as is ;))
(No more switchres updates. The version number is perfect as is ;))
016 is reserved for good stuff ;)
I'm certain you mean that '016 is reserved for fabulous stuff', since the last few patches have been good, obviously. ;)
if the MAME project moves to BGFX and drops the current video apis in the middle of the process, I might be screwed. I am not actually a programmer.
Fantastic news, now we can finally put groovymame and demul (dx11) on on PC :)
New tools looks great :))
- Added support for AMD HD 5000/6000/7000 series.
GroovyMAME 0.169 (Switchres 0.015l) is out.
What's new in SwitchRes v0.015l
- Added support for AMD HD 5000/6000/7000 series. You'll need CRT Emudriver 2.0 for Windows 7/8/10 (http://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=295).
- ATI legacy cards (HD 2000/3000/4000): fixed halved refresh of interlaced modes on vsync with Direct3D. Make sure to use in combination with the new CRT Tools (VMMaker & Arcade OSD).
- Removed frogger/galaxian patch. As suggested by haynor666.
Thanks a lot for testing, haynor666. I wonder why SFIV isn't working. Maybe it requires @60 instead of @30, don't know. I'd need to use a debugger to dig in the problem, but I hate the idea of having to figure out how to find and download those things.
GroovyMAME 0.169 (Switchres 0.015l) is out.
What's new in SwitchRes v0.015l
- Added support for AMD HD 5000/6000/7000 series. You'll need CRT Emudriver 2.0 for Windows 7/8/10 (http://geedorah.com/eiusdemmodi/forum/viewtopic.php?id=295).
- ATI legacy cards (HD 2000/3000/4000): fixed halved refresh of interlaced modes on vsync with Direct3D. Make sure to use in combination with the new CRT Tools (VMMaker & Arcade OSD).
- Removed frogger/galaxian patch. As suggested by haynor666.
Hi Calamity,
A constant is missing for the Linux build in switchres.h
#define XRANDR_TIMING 0x00000010
I am operating the build remotely over a very slow satellite link. Normally, the package will be ready this afternoon. I hope the upload will terminate before 2016 ;-)
Hi Calamity,
A constant is missing for the Linux build in switchres.h
#define XRANDR_TIMING 0x00000010
I am operating the build remotely over a very slow satellite link. Normally, the package will be ready this afternoon. I hope the upload will terminate before 2016 ;-)
Thanks! I'll fix the diff once you confirm it builds fine. There's been a huge overhaul in this version, I guess there'll be more issues with the sdl build.
pacman -Syy qt5-base
The build is done.
The build is done.
Great! Thanks.
SwitchRes: v0.015l, Monitor: lcd, Orientation: horizontal, Modeline generation: disabled
SwitchRes: Using default vfreq range for LCD 59.000000-61.000000
SwitchRes: Found output connector 'DVI-I-1'
SwitchRes: Creating automatic specs for LCD based on VESA GTF
SwitchRes: Monitor range 73278.00-75762.00,59.00-61.00,0.696,1.044,1.740,0.013,0.040,0.510,0,1,1200,1200,0,0
SwitchRes: -resolution was set at command line or in .ini file as 1600x1200@60
SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015l:[pacman] Calculating best video mode for 224x288@60.606060 orientation: rotated
SwitchRes: [1600]x[1200]_[60=0.0000Hz]Having problems with 169, both the official 32 and 64 bit builds when launched run at 100% cpu and don't even seem to create a window, same result when I build it myself from source (with the missing define added).
Sorry, yes its Linux. Arch Linux specifically if that matters.
EDIT: one quick question: do I have to update the CRT Tools and create the video modes again with the new VMMaker in order to use 0.169? (I'm using Windows XP 32bit)
EDIT 2: regarding HD5000, 6000 and 7000 series: are they affected by the low dotclock issue?
EDIT: one quick question: do I have to update the CRT Tools and create the video modes again with the new VMMaker in order to use 0.169? (I'm using Windows XP 32bit)
EDIT 2: regarding HD5000, 6000 and 7000 series: are they affected by the low dotclock issue?
Does it work with mobility hd5000?
@RobertJ, You are right, the Linux builds are not usable. The odd screen behaviour must first be fixed. Nevertheless, you should see a picture on the screen. I do not know why you have a black screen.
SwitchRes: v0.015l, Monitor: custom, Orientation: horizontal, Modeline generation: enabled
SwitchRes: Monitor range 15625.00-16200.00,55.10-65.00,2.000,5.700,8.000,0.064,0.192,1.024,0,0,192,240,0,0
SwitchRes: Monitor range 15625.00-16200.00,49.50-54.25,2.000,5.700,8.000,0.064,0.192,1.024,0,0,192,256,0,0
SwitchRes: Monitor range 15625.00-16200.00,49.50-65.00,2.000,5.700,8.000,0.064,0.192,1.024,0,0,0,0,448,576
SwitchRes: Found output connector 'VGA-0'
SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015l:[cninja] Calculating best video mode for 256x240@58.000000 orientation: normal
SwitchRes: ( 1)x( 1)_(60=0.0000Hz) - locked
SwitchRes: could not find a video mode that meets your specs
This problem wasn't present before the driver update.
From the log, it is clear that groovymame is not able to switch to native game resolution based on its calculation. It runs using the X default resolution instead.
From the log, it is clear that groovymame is not able to switch to native game resolution based on its calculation. It runs using the X default resolution instead.
Ok Doozer I can see the error, I'll prepare a new patch, thanks.
Hi Calamity,
A constant is missing for the Linux build in switchres.h
#define XRANDR_TIMING 0x00000010
I am operating the build remotely over a very slow satellite link. Normally, the package will be ready this afternoon. I hope the upload will terminate before 2016 ;-)
Ok I think this is the problem, this constant needs to be redefined as:
#define XRANDR_TIMING 0x00000020
(check the new definition custom_video.h in the windows osd folder)
# pacman -S downgrade
# downgrade sdl2
<select sdl2-2.0.3-1>
[root@cab1 ~]# pacman -S downgrade
resolving dependencies...
looking for conflicting packages...
Packages (1) downgrade-5.1.4-1
Total Download Size: 0.01 MiB
Total Installed Size: 0.10 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages ...
downgrade-5.1.4-1-any 5.9 KiB 0.00B/s 00:00 [################################################################] 100%
(1/1) checking keys in keyring [################################################################] 100%
(1/1) checking package integrity [################################################################] 100%
(1/1) loading package files [################################################################] 100%
(1/1) checking for file conflicts [################################################################] 100%
(1/1) checking available disk space [################################################################] 100%
(1/1) installing downgrade [################################################################] 100%
Optional dependencies for downgrade
sudo: for installation via sudo [installed]
[root@cab1 ~]# downgrade sdl2
Available packages:
1) sdl2-2.0.4-2-x86_64.pkg.tar.xz (remote)
2) sdl2-2.0.4-1-x86_64.pkg.tar.xz (remote)
3) sdl2-2.0.3-1-x86_64.pkg.tar.xz (remote)
4) sdl2-2.0.2-2-x86_64.pkg.tar.xz (remote)
5) sdl2-2.0.2-1-x86_64.pkg.tar.xz (remote)
6) sdl2-2.0.1-3-x86_64.pkg.tar.xz (remote)
7) sdl2-2.0.1-2-x86_64.pkg.tar.xz (remote)
8) sdl2-2.0.1-1-x86_64.pkg.tar.xz (remote)
select a package by number: 3
######################################################################## 100.0%
######################################################################## 100.0%
loading packages...
warning: downgrading package sdl2 (2.0.4-1 => 2.0.3-1)
resolving dependencies...
looking for conflicting packages...
Packages (1) sdl2-2.0.3-1
Total Installed Size: 2.25 MiB
Net Upgrade Size: -0.56 MiB
:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring [################################################################] 100%
(1/1) checking package integrity [################################################################] 100%
(1/1) loading package files [################################################################] 100%
(1/1) checking for file conflicts [################################################################] 100%
(1/1) checking available disk space [################################################################] 100%
(1/1) downgrading sdl2 [################################################################] 100%
add sdl2 to IgnorePkg? [y/n] n
Thanks for digging into this Doozer. The only change that we do in GM is to poll input at a different place, just like we do in Windows. This shouldn't cause any issue, but input has proved to be extremely delicate under Linux.
When you tested 0.169 with the redefined constant (#define XRANDR_TIMING 0x00000020), did you do it remotely? Could you confirm if the fullscreen settings are applied properly on the real hardware?
EDIT: @VeS & Doozer. Regarding input, could you please test this? In the patched source tree...
Thanks for digging into this Doozer. The only change that we do in GM is to poll input at a different place, just like we do in Windows. This shouldn't cause any issue, but input has proved to be extremely delicate under Linux.
Apparently SDL2.0.4 introduces the multi keyboard handling feature. This feature is if high interest for mame and some emulator to route/filter the controls. It was initially planed for 2.1.0, I am not sure mame does use/include changes linked to it but it is my best guess at this time.
Ok, I'll compile latest GIT with previous code.
src/osd/sdl/window.cpp
OSDWORK_CALLBACK( sdl_window_info::draw_video_contents_wt ) --> uncomment sdlinput_process_events_buf();
src/osd/sdl/video.cpp
void sdl_osd_interface::poll_input(void) ----> comment sdlinput_process_events_buf();
To completely revert the effect of the patch, in addition to those changes you need to leave empty the poll_input function, then move those calls where they belong, above in the video update routine.
Is it beta 4 and fix2 versions still for people that need Taito Type X games running at 100% speed?
What exactly was changed in fix2 ?
[...]
Now working on a tutorial to configure VMMaker for HD 4xxx, step by step.
[...]
Is GM v0.151 Linux available anywhere please?
All links I've found are either dead ends or lead to the latest version.
Thanks.
Is GM v0.151 Linux available anywhere please?
All links I've found are either dead ends or lead to the latest version.
Thanks.
Nobody built that exact version for Linux, the closest you have is 0.152, here:
https://code.google.com/p/groovyarcade/downloads/list
However the diff is there, in case you want to roll your own build.
Just to clarify, it's not that I get a black screen, its that I get nothing at all, mame creates no window or viewport or whatever it creates.
I have uploaded versions named *_SDL2.0.4+_fix to the share drive. Could you kindly check if it solves your issue?
The groovymame inside the tar.bz2 doesn't appear to be an executable. :( Whenever I try and launch it bash says command not found.
I tried the diff Calamity just posted and rebuilt from scratch, and that has the same issue as before. :/ Tried various sdl2 versions, no difference.
I appreciate the time both of you are putting into this, it's a thankless task, but thank you all the same.
In any case you should see groovymame picture. Have you already tried to launch mame64 without any patch?
Just literally built a clean mame169 with just the hiscore diff patch, and that runs straight away, no 100% cpu, however it does run in completely the wrong aspect ratio for reasons I don't understand as its the same config as groovymame is using.
So the issue is somehow related to the groovymame patch. :/
So the issue is somehow related to the groovymame patch. :/
const vec2 angle = vec2(0.0,0.0);
# == to be changed to =>
const vec2 angle = vec2(0.0,0.01);
Calamity, is fix5 version ready for Windows XP ? If yes, I have to use latest tools or I can stay on old ones ?
Try forcing -lcd_range 60-60
(default lcd range is the only change I did in 169)Also, consider posting a full log.
Same issue with that either in mame.ini or on the command line. :(
SwitchRes: v0.015k, Monitor: lcd, Orientation: horizontal, Modeline generation: disabled
SwitchRes: Using default vfreq range for LCD 60.000000-60.000000
SwitchRes: Found output connector 'DVI-I-1'
SwitchRes: Creating automatic specs for LCD based on VESA GTF
SwitchRes: Monitor range 74520.00-74520.00,60.00-60.00,0.696,1.044,1.740,0.013,0.040,0.510,0,1,1200,1200,0,0
SwitchRes: -resolution was set at command line or in .ini file as 1600x1200@60
SwitchRes: Entering switchres_modeline_setup
SwitchRes: v0.015k:[pacman] Calculating best video mode for 224x288@60.606060 orientation: rotated
SwitchRes: [1600]x[1200]_(60=0.0000Hz)
rng(0): 1600 x1200_0.000p 0.000 [integ] scale(4, 4, 1) diff(0.44, 3.95, -0.6061) ratio(7.143, 4.167)
SwitchRes: [pacman] (1) vertical (224x288@60.61)->(1600x1200@0.00)
rng(0): 1600 x1200_0.000p 0.000 [integ] scale(4, 4, 1) diff(0.44, 3.95, -0.6061) ratio(7.143, 4.167)
SwitchRes: Setting option -rotate
SwitchRes: Setting option -noror
SwitchRes: Setting option -noautoror
SwitchRes: Setting option -norol
SwitchRes: Setting option -noautorol
SwitchRes: Setting option -noblack_frame_insertion
SwitchRes: Setting option -multithreading
SwitchRes: Setting option -syncrefresh
SwitchRes: Setting option -waitvsync
SwitchRes: Setting option -keepaspect
SwitchRes: Setting option -nounevenstretch
SwitchRes: Setting option -nofilter
SwitchRes: Setting option -prescale 3
Available videodrivers: x11 wayland dummy
Current Videodriver: x11
Display #0
Renderdrivers:
opengl (0x0)
opengles2 (0x0)
opengles (0x0)
software (0x0)
Available audio drivers:
pulseaudio
alsa
dsp
disk
dummy
Build version: 0.168 (Dec 20 2015)
Build architecure:
Build defines 1: SDLMAME_UNIX=1 SDLMAME_X11=1 SDLMAME_LINUX=1
Build defines 1: LSB_FIRST=1 PTR64=1 SYNC_IMPLEMENTATION=tc
SDL/OpenGL defines: SDL_COMPILEDVERSION=2003 USE_OPENGL=1
Compiler defines A: __GNUC__=5 __GNUC_MINOR__=3 __GNUC_PATCHLEVEL__=0 __VERSION__="5.3.0"
Compiler defines B: __amd64__=1 __x86_64__=1 __unix__=1
Compiler defines C: __USE_FORTIFY_LEVEL=0
Enter init_monitors
Adding monitor screen0 (1600 x 1200)
Leave init_monitors
Enter sdlwindow_init
Using SDL multi-window OpenGL driver (SDL 2.0+)
/dev/dri/card0 successfully opened
Hints:
SDL_FRAMEBUFFER_ACCELERATION (null)
SDL_RENDER_DRIVER (null)
SDL_RENDER_OPENGL_SHADERS (null)
SDL_RENDER_SCALE_QUALITY (null)
SDL_RENDER_VSYNC (null)
SDL_VIDEO_X11_XVIDMODE (null)
SDL_VIDEO_X11_XINERAMA (null)
SDL_VIDEO_X11_XRANDR (null)
SDL_GRAB_KEYBOARD (null)
SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS (null)
SDL_IOS_IDLE_TIMER_DISABLED (null)
SDL_IOS_ORIENTATIONS (null)
SDL_XINPUT_ENABLED (null)
SDL_GAMECONTROLLERCONFIG (null)
SDL_JOYSTICK_ALLOW_BACKGROUND_EVENTS (null)
SDL_ALLOW_TOPMOST (null)
SDL_TIMER_RESOLUTION (null)
SDL_RENDER_DIRECT3D_THREADSAFE (null)
SDL_VIDEO_ALLOW_SCREENSAVER (null)
SDL_ACCELEROMETER_AS_JOYSTICK (null)
SDL_MAC_CTRL_CLICK_EMULATE_RIGHT_CLICK (null)
SDL_VIDEO_WIN_D3DCOMPILER (null)
SDL_VIDEO_WINDOW_SHARE_PIXEL_FORMAT (null)
SDL_VIDEO_MAC_FULLSCREEN_SPACES (null)
SDL_MOUSE_RELATIVE_MODE_WARP (null)
SDL_HINT_RENDER_DIRECT3D11_DEBUG (null)
SDL_VIDEO_HIGHDPI_DISABLED (null)
SDL_HINT_WINRT_PRIVACY_POLICY_URL (null)
SDL_HINT_WINRT_PRIVACY_POLICY_LABEL (null)
SDL_HINT_WINRT_HANDLE_BACK_BUTTON (null)
Leave sdlwindow_init
Enter sdl_info::create
OpenGL: nouveau
OpenGL: Gallium 0.4 on NVC8
OpenGL: 3.0 Mesa 11.1.0
OpenGL: texture rectangle supported
OpenGL: non-power-of-2 textures supported (new method)
OpenGL: vertex buffer supported
OpenGL: pixel buffers supported
OpenGL: framebuffer object supported
OpenGL: GLSL supported, but disabled
OpenGL: max texture size 16384 x 16384
Leave sdl_info_ogl::create
Keyboard: Start initialization
Input: Adding Kbd #0: System keyboard
Keyboard: Registered System keyboard
Keyboard: End initialization
Mouse: Start initialization
Input: Adding Mouse #0: System mouse
Mouse: Registered System mouse
Mouse: End initialization
Joystick: Start initialization
Input: Adding Joy #0: Ultimarc IPAC 2 Ultimarc IPAC 2
Joystick: Ultimarc IPAC 2 Ultimarc IPAC 2
Joystick: ... 4 axes, 32 buttons 1 hats 0 balls
Joystick: ... Physical id 0 mapped to logical id 1
Joystick: End initialization
output: unable to open output notifier file /tmp/sdlmame_out
Audio: Start initialization
Audio: Driver is pulseaudio
Audio: frequency: 48000, channels: 2, samples: 256
sdl_create_buffers: creating stream buffer of 18432 bytes
Audio: End initialization
Region ':maincpu' created
Region ':gfx1' created
Region ':proms' created
Region ':namco' created
Starting Pac-Man (Midway) ':'
Optional shared pointer 'patched_opcodes' not found
Optional shared pointer 'rocktrv2_prot' not found
Optional shared pointer 's2650_tileram' not found
Optional shared pointer 's2650_spriteram' not found
(missing dependencies; rescheduling)
Starting Z80 ':maincpu'
Starting gfxdecode ':gfxdecode'
Starting palette ':palette'
Starting Video Screen ':screen'
Starting Speaker ':mono'
(missing dependencies; rescheduling)
Starting Namco ':namco'
Starting Pac-Man (Midway) ':'
Optional shared pointer 'patched_opcodes' not found
Optional shared pointer 'rocktrv2_prot' not found
Optional shared pointer 's2650_tileram' not found
Optional shared pointer 's2650_spriteram' not found
(missing dependencies; rescheduling)
Starting Speaker ':mono'
Starting Pac-Man (Midway) ':'
Optional shared pointer 'patched_opcodes' not found
Optional shared pointer 'rocktrv2_prot' not found
Optional shared pointer 's2650_tileram' not found
Optional shared pointer 's2650_spriteram' not found
OpenGL: VBO supported
OpenGL: PBO supported
OpenGL: FBO supported
OpenGL: using vid filter: 0
GL texture: copy 1, shader 0, dynamic 1, 864x672 864x672 [PALETTE16, Equal: 0, Palette: 1,
scale 3x3, border 0, pitch 384,864/16384], bytes/pix 4
GL texture: copy 1, shader 0, dynamic 1, 864x672 864x672 [PALETTE16, Equal: 0, Palette: 1,
scale 3x3, border 0, pitch 384,864/16384], bytes/pix 4
GL texture: copy 1, shader 0, dynamic 1, 864x672 864x672 [PALETTE16, Equal: 0, Palette: 1,
scale 3x3, border 0, pitch 384,864/16384], bytes/pix 4
Average speed: 81.70% (10 seconds)
sdl_kill: closing audio
Sound buffer: overflows=3 underflows=6
Enter sdlwindow_exit
Leave sdlwindow_exit
Joystick: Start deinitialization
Joystick: End deinitialization
SwitchRes: Restoring desktop resolution: 1600x1200
SwitchRes: Running 'xrandr --output DVI-I-1 --mode 1600x1200'
Try forcing -lcd_range 60-60
(default lcd range is the only change I did in 169)Also, consider posting a full log.
Same issue with that either in mame.ini or on the command line. :(
I did. :(
http://forum.arcadecontrols.com/index.php/topic,135823.msg1552569.html#msg1552569 (http://forum.arcadecontrols.com/index.php/topic,135823.msg1552569.html#msg1552569)
That's not a full log, just a few lines. Did you try the lcd_range thing I suggested?
No, really, that's the full log! That's as far as it gets with -v, after that the process hits 100% cpu and never gets any further.
I did try the lcd_range, it just changed the text in the Monitor Range line to match the previous working version, it still hangs in the same place.
So new build without wa + d3d9ex crashes? I cloned your modelines here this morning and it worked fine for all apis. Although mode was not updated properly to interlace as I said.
That didn't happen here, will test again on monday.
edit: It might be related with -mt
Uploaded "fix6":
- (Linux) Attempt to fix bug reported by RobertJ (untested, please check if possible).
Ok, let me know if you need anything.
MT does not seem to affect the result, attaching two logs of the latest build with/without mt without the workaround.
Edit: Also, there seems to be a forum bug related to the attachments. I *just* posted this and the download counter for these files must be corrupt (24/27). Now 38/38. I saw the issue once before in the original fix2 crash post. Who should we contact about this?
Wooooooop!!!! \o/ Thanks Calamity, fix6 now works for me!!!
What was the cause?
Edit: Only seems to work with ddraw and d3d9ex, not d3d?? D3D still selects the progressive mode.
Edit: Only seems to work with ddraw and d3d9ex, not d3d?? D3D still selects the progressive mode.
Because I accidentally edited your post I missed the part where you describe the workaround. By looking at your logs I can't see any relevant difference with/without workaround, apart from the crash obviously.
Ok, let me know if you need anything.
MT does not seem to affect the result, attaching two logs of the latest build with/without mt without the workaround.
Edit: Also, there seems to be a forum bug related to the attachments. I *just* posted this and the download counter for these files must be corrupt (24/27). Now 38/38. I saw the issue once before in the original fix2 crash post. Who should we contact about this?
Thank for the logs. I've searched for error 08760877, it's S_PRESENT_MODE_CHANGED: https://msdn.microsoft.com/es-es/library/windows/desktop/bb172554(v=vs.85).aspx
It looks like we should reset the device if that happens, but I remind you reporting another issue about resetting the device in d3d9ex.
EDIT. With VMMaker beta 5 under XP model2 emu does not work.
Exactly, this is what is strange. Also weird that it doesn't affect your machine, what GPU are you using?
Is it possible to remove/replace the native modes completely?
640x480_59.19 (0x27a) 23.530MHz -HSync +VSync
h: width 640 start 656 end 720 total 800 skew 0 clock 29.41KHz
v: height 480 start 481 end 484 total 497 clock 59.18Hz
640x480_59.185608 (0x278) 23.532MHz -HSync +VSync
h: width 640 start 656 end 720 total 800 skew 0 clock 29.42KHz
v: height 480 start 481 end 484 total 497 clock 59.19Hz
Could that be added to the groovy patch?
QuoteCould that be added to the groovy patch?
Sure, post your patch. Anyway, have you actually checked if this translates in a refresh difference? IIRC GM already accounts for the 10 kHz dotclock aligment, thus the rounding.
Having a 6 digits precision opens the door to future xrandr upgrades enabling better dotclock graphic cards to take an advantage.
GroovyMAME 0.170 (Switchres 0.015l) is out.
Hi,A guy who I built a version of GM.163 for tells me that he's also getting the 26 modeline issue when running VMmaker on that version. He's dropped back to an earlier one and its fine. Unfortunately I can't verify this as my CRT is away for repair. I appreciate you're busy with other things right now but if there's anything I can do to help diagnose this bug please let me know.
You can use an older binary to extract the xml. Just use the xml from GM 0.161, and keep using GM 0.163 for actual emulation. This is not a bug, it's VMMaker that needs to be updated for the new 0.162 xml format.
It's sad. Now I need force ratio 1:1 in D3D somehow for some games because my TV does not have regulation for horizontal size :/
Another problem might appear soon - http://mame32fx.altervista.org/forum/viewtopic.php?f=1&t=33&start=140 (http://mame32fx.altervista.org/forum/viewtopic.php?f=1&t=33&start=140)
Do You planning restoring ddraw for groovymame?
Right now I don't see any solution for halved refreshrates under windows 7 and legacy timings besides enabling positive sync.
Hopefully you guys see now why I've been pushing for W7 and D3D the last couple of years.
Thanks, anyway credit for D3D9ex is for koopah & intealls.
so you're admitting to me being correct about something?Hopefully you guys see now why I've been pushing for W7 and D3D the last couple of years.I'm glad my mate Sledge introduced it to me 4 years ago.
If I remember correctly dot clock issue is absolete with cards HD5xxx and futher.
The new HD5xxx, HD6xxx family due to ADL timings does not suffer from halved refresh rates (at least my HD5450 seems to be working fine) but interlaced picture is blurry. For the best solution was use HD4350 and set positive sync to get proper refresh rates with interlaced modes. Sadly HD5450 is far below for DEmul though more than enough for Makaron or nullDC. Also due to small problems with Taito Type X games and Deathsmiles II I'm staying for now with XP. In next year mame could only be x64 program and designed for Vista and upward - http://mame32fx.altervista.org/forum/viewtopic.php?f=1&t=33&start=140 (http://mame32fx.altervista.org/forum/viewtopic.php?f=1&t=33&start=140)
For people that uses mame only - move to windows 7 x64 if your hardware is capable and use latest Calamity driver.
So, is GM now only compatible with w7 and more recent OS?
Or does it still retain compatibility with WinXP and DDraw?
So 0.170 is officially the last release to support DDraw, correct?
From now on WinXP will have to use D3D and Win7+ will use D3D9ex.
GroovyMAME 0.171 is out.Still using d3d9ex here, I suppose as long as SwitchRes is on in the .INI we should leave the new UI's 'Display Options' menu alone, right ?
What's new in SwitchRes v0.015m
- (Windows 7+) Preliminar support for the new BGFX renderer (currently only DirectX 11). Mode setting is implemented. Dynamic resolution switching may be buggy yet. Frame delay not implemented yet.
Still using d3d9ex here, I suppose as long as SwitchRes is on in the .INI we should leave the new UI's 'Display Options' menu alone, right ?
Honestly DDraw did everything great so I can't see how BGFX might bring better solutions to us.
Thanks Calamity for this speedy update. I'm really really loving this one. Having pretty much jumped from 0.160 to 0.170/0.171, is it my imagination or does everything (ie controls) seem so much more responsive with D3D9ex with frame delay? It's a real joy to use. Thanks again.
I thought using D3D9EX was to "remove" the frame buffer
What does this mean? It means that the devs are already starting to optimize the drivers for LCDs, which in turn can falsify the result what we see on our loved CRTs. Take Atari 2600 for example and start any game with high motion in it and then pause it and examine the screen. You will explore the blending of frames, which the devs did to avoid flicker on a LCD. This frame-blending did not exist on real hardware.
Are you sure about this? Doing that at the driver level would encourage inaccurate emulation, which is against the entire philosophy of MAME. Doing that with postprocessing (HLSL etc) is another story, and it's probably also something that can be turned off.
yes, i am sure. try it for yourself, with no effects applied... its still there, that frame-blending crap. i just was to lazy, to do another screenshot.
I have same issues like you, regarding philosophy of MAME, but they consider CRT as a dead hardware, so it is nothing wrong in their eyes, to do the drivers itself and this is not the only example, i can asure you.
Ok so to be on topic are any plans to bring similiar feature ie. force integer scalling ratio no matter resolution like game 320x240 with black bars or trash on side to force work at 304x240 with 8 pixels cutted from both sides?
With ddraw this was possible but right it's not. From what I can see here on BYOAC forum there still some people that needs such option.
Let me be clear on this: I consider cropping the game frame a very lame way of configuring things. As I have explained several times, the whole modeline engine is based on the premise that the native frame rectangle MUST fit in the target resolution.
From a programming point of view, it would make the modeline generator code unnecessarily complex and prone to bugs, just like if market food scales had to be designed to deal with the special case of antimatter.
Agreed, cropping the frame is wrong. People need to give up on that approach. I'm almost certain that at some point in the past, Haze implemented a layout for certain Neo-Geo games in MAME that added a black overlay to the full native resolution to hide the garbage on the sides. Does that no longer exist? I'm perfectly fine with that solution.
[root@mame mame171]# make
GCC 5.3.0 detected
Compiling src/osd/modules/render/drawbgfx.cpp...
../../../../../src/osd/modules/render/drawbgfx.cpp: In member function ‘virtual int renderer_bgfx::create()’:
../../../../../src/osd/modules/render/drawbgfx.cpp:135:222: error: too many arguments to function ‘void bgfx::reset(uint32_t, uint32_t, uint32_t)’
indowed? BGFX_RESET_NONE : BGFX_RESET_FULLSCREEN) | (video_config.waitvsync ? BGFX_RESET_VSYNC : BGFX_RESET_NONE));
^
In file included from ../../../../../3rdparty/bgfx/include/bgfx/bgfxplatform.h:14:0,
from ../../../../../src/osd/modules/render/drawbgfx.cpp:27:
../../../../../3rdparty/bgfx/include/bgfx/bgfx.h:801:7: note: declared here
void reset(uint32_t _width, uint32_t _height, uint32_t _flags = BGFX_RESET_NONE);Stock MAME without the hi score or groovymame patches compiles fine. :(
[root@mame mame171-original]# patch -p0 -E --binary < ../0171_groovymame_015m.diff
patching file 3rdparty/bgfx/include/bgfx/bgfx.h
Hunk #1 FAILED at 798 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file 3rdparty/bgfx/include/bgfx/bgfx.h.rej
patching file 3rdparty/bgfx/include/bgfx/c99/bgfx.h
Hunk #1 FAILED at 480 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file 3rdparty/bgfx/include/bgfx/c99/bgfx.h.rej
patching file 3rdparty/bgfx/include/bgfx/c99/bgfxplatform.h
Hunk #1 FAILED at 83 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file 3rdparty/bgfx/include/bgfx/c99/bgfxplatform.h.rej
patching file 3rdparty/bgfx/src/bgfx.cpp
Hunk #1 FAILED at 2466 (different line endings).
Hunk #2 FAILED at 3779 (different line endings).
2 out of 2 hunks FAILED -- saving rejects to file 3rdparty/bgfx/src/bgfx.cpp.rej
patching file 3rdparty/bgfx/src/bgfx_p.h
Hunk #1 FAILED at 197 (different line endings).
Hunk #2 FAILED at 1327 (different line endings).
Hunk #3 FAILED at 2122 (different line endings).
3 out of 3 hunks FAILED -- saving rejects to file 3rdparty/bgfx/src/bgfx_p.h.rej
patching file 3rdparty/bgfx/src/config.h
Hunk #1 FAILED at 178 (different line endings).
1 out of 1 hunk FAILED -- saving rejects to file 3rdparty/bgfx/src/config.h.rej
patching file 3rdparty/bgfx/src/renderer_d3d11.cpp
Hunk #1 FAILED at 1102 (different line endings).
Hunk #2 FAILED at 2217 (different line endings).
Hunk #3 FAILED at 2256 (different line endings).
3 out of 3 hunks FAILED -- saving rejects to file 3rdparty/bgfx/src/renderer_d3d11.cpp.rej
patching file scripts/src/emu.lua
patching file scripts/src/osd/sdl.lua
patching file scripts/src/osd/sdl_cfg.lua
patching file scripts/src/osd/windows.lua
patching file src/emu/clifront.cpp
patching file src/emu/drivenum.cpp
patching file src/emu/drivers/empty.cpp
patching file src/emu/emu.h
patching file src/emu/emuopts.cpp
patching file src/emu/emuopts.h
patching file src/emu/machine.cpp
patching file src/emu/machine.h
patching file src/emu/render.cpp
patching file src/emu/sound.cpp
patching file src/emu/sound.h
patching file src/emu/switchres/modeline.cpp
patching file src/emu/switchres/modeline.h
patching file src/emu/switchres/monitor.cpp
patching file src/emu/switchres/monitor.h
patching file src/emu/switchres/switchres.cpp
patching file src/emu/switchres/switchres.h
patching file src/emu/switchres/switchres_proto.h
patching file src/emu/switchres/util.cpp
patching file src/emu/ui/dsplmenu.cpp
patching file src/emu/ui/ui.cpp
patching file src/emu/video.cpp
patching file src/emu/video.h
patching file src/osd/modules/lib/osdobj_common.cpp
patching file src/osd/modules/lib/osdobj_common.h
patching file src/osd/modules/osdwindow.cpp
patching file src/osd/modules/osdwindow.h
patching file src/osd/modules/render/d3d/d3d9intf.cpp
patching file src/osd/modules/render/d3d/d3dintf.h
patching file src/osd/modules/render/drawbgfx.cpp
patching file src/osd/modules/render/drawbgfx.h
patching file src/osd/modules/render/drawd3d.cpp
patching file src/osd/modules/render/drawd3d.h
patching file src/osd/modules/render/drawogl.cpp
patching file src/osd/modules/sound/direct_sound.cpp
patching file src/osd/modules/sound/sdl_sound.cpp
patching file src/osd/osdepend.h
patching file src/osd/sdl/input.cpp
patching file src/osd/sdl/osdsdl.h
patching file src/osd/sdl/sdlmain.cpp
patching file src/osd/sdl/switchres_sdl.cpp
patching file src/osd/sdl/video.cpp
patching file src/osd/sdl/window.cpp
patching file src/osd/sdl/window.h
patching file src/osd/windows/custom_video.cpp
patching file src/osd/windows/custom_video.h
patching file src/osd/windows/custom_video_adl.cpp
patching file src/osd/windows/custom_video_adl.h
patching file src/osd/windows/custom_video_ati.cpp
patching file src/osd/windows/custom_video_ati.h
patching file src/osd/windows/custom_video_ati_family.cpp
patching file src/osd/windows/custom_video_pstrip.cpp
patching file src/osd/windows/custom_video_pstrip.h
patching file src/osd/windows/switchres_windows.cpp
patching file src/osd/windows/video.cpp
patching file src/osd/windows/window.cpp
patching file src/osd/windows/window.h
patching file src/osd/windows/winmain.cpp
patching file src/osd/windows/winmain.h
Hi guys, having build problems with 171 on Arch Linux, related to bgfx. :(Code: [Select][root@mame mame171]# make
GCC 5.3.0 detected
Compiling src/osd/modules/render/drawbgfx.cpp...
../../../../../src/osd/modules/render/drawbgfx.cpp: In member function ‘virtual int renderer_bgfx::create()’:
../../../../../src/osd/modules/render/drawbgfx.cpp:135:222: error: too many arguments to function ‘void bgfx::reset(uint32_t, uint32_t, uint32_t)’
indowed? BGFX_RESET_NONE : BGFX_RESET_FULLSCREEN) | (video_config.waitvsync ? BGFX_RESET_VSYNC : BGFX_RESET_NONE));
^
In file included from ../../../../../3rdparty/bgfx/include/bgfx/bgfxplatform.h:14:0,
from ../../../../../src/osd/modules/render/drawbgfx.cpp:27:
../../../../../3rdparty/bgfx/include/bgfx/bgfx.h:801:7: note: declared here
void reset(uint32_t _width, uint32_t _height, uint32_t _flags = BGFX_RESET_NONE);
Any ideas?
unix2dos 3rdparty/bgfx/include/bgfx/bgfx.h 3rdparty/bgfx/include/bgfx/c99/bgfx.h 3rdparty/bgfx/include/bgfx/c99/bgfxplatform.h 3rdparty/bgfx/src/bgfx.cpp 3rdparty/bgfx/src/bgfx_p.h 3rdparty/bgfx/src/config.h 3rdparty/bgfx/src/renderer_d3d11.cpp
I am not sure I am writing in the right place, I have problems with the new BGFX render.
I think you will be interested to know I'm currently working in refactoring the GroovyMAME code for an eventual merge with baseline (partial or total, we don't know yet). My plan is to deconstruct the current patch in smaller blocks and be submitting them in gradual steps, so we make sure nothing gets broken in the process, and basic features can get isolated from the somewhat more experimental ones. First feature I'll be adding is integer scaling, which should be ready for 0.172. Next, I'd like to focus on the synchronization options. Of course, the last word belongs to the team with regards to which features get in and which don't.
I think you will be interested to know I'm currently working in refactoring the GroovyMAME code for an eventual merge with baseline (partial or total, we don't know yet).
My plan is to deconstruct the current patch in smaller blocks and be submitting them in gradual steps, so we make sure nothing gets broken in the process, and basic features can get isolated from the somewhat more experimental ones.
Calamity, are you prepared to give us a little history on how this came about?it seemed to develop after the recent news that directdraw was to be removed from mame...... then some people at the mameworld forums were chatting about how it was a shame that directdraw allowed for integer scaling but direct3d did not, and if it was possible to see some additions to direct3d in mame to allow eg. low res crt users the option for an unaltered image (no scaling or stretching etc) displayed using direct3d
Is Groovymame's license compatible?...
http://www.mameworld.info/ubbthreads/showflat.php?Number=351062 (http://www.mameworld.info/ubbthreads/showflat.php?Number=351062)
Calamity, are you prepared to give us a little history on how this came about?
I take it then that as certain features are incorporated into mainline MAME they'll be taken out of the GM patch naturally.
Is not Switchres coming from SailorSats Cabmame? If so, the license will be a peace of cake ;) .Is Groovymame's license compatible?...
http://www.mameworld.info/ubbthreads/showflat.php?Number=351062 (http://www.mameworld.info/ubbthreads/showflat.php?Number=351062)
As far as I see all that's required is to relicense the Switchres code with the BSD 3-Clause License.
Only problem I see is with the hiscore patch. Anyway my plan was to make GroovyMAME's patch independent from the hiscore one. This way the hiscore patch would be applied later over GroovyMAME's instead of the other way as it is now. And I wouldn't be applying it on my builds.
Is the problem with hiscore patch MAME dev related? I know, that they dont like to see the nag-screen patched, for obvious reasons. The nag-screen provide infos that a user will not see if a patch is applied. It happened often that people not knowing, that a game have problems or doesnt work correctly, maked false reports at MAME bug-center, that why they dont like no-nag-screen patches, but the hiscore stuff itself, shouldnt be so much a problem AFAIK.
For example, the hiscore patch amounts to the original hiscore.dat support in MAME. So you need to discover who authored as well as maintained that code in MAME originally,
For example, the hiscore patch amounts to the original hiscore.dat support in MAME. So you need to discover who authored as well as maintained that code in MAME originally,
That's the exact problem. I know MKChamp has been mantaining it for years, but the original source must be paleo-MAME code base itself.
https://github.com/borgar/mame-hiscores
crazyc:"It was made for unix and needs work on windows though and will only work with the maincpu address space (which includes the vast majority, but not all, of drivers). "
Didnt test it myself, so.
[/quote
And in the end here's an all-platforms-friendly version by crazyc which also fixes some games that didn't work previously:
https://github.com/cracyc/mame-hiscores
Ships with a modified hiscore.dat.
:)
I really keep meaning to get my vector patch working again, and then a reverse-patch for the old Kung Fu Master audio driver. One of those might stand a chance of getting into MAME one day, the other would not. Either way, with MAME now being hosted on github, it's extremely easy to make a fork and maintain it.
So, multithreading will be removed for 0.172
Will it break the current low-lag abilities of GM w/ d3d9ex ? (using either syncrefresh or triplebuffer and still being quicker than the same thing using 'normal' D3D I mean)
Does it allow setting factors that mean out-of-screen-limits sizes ?
Integer scaling is finally into baseline:
http://git.redump.net/mame/commit/?id=4b61493c7cd125f7fcc11f6fa1bf2240fdab29f0 (http://git.redump.net/mame/commit/?id=4b61493c7cd125f7fcc11f6fa1bf2240fdab29f0)
Among other things, now it'll be possible to set integer scale factors manually (-intscalex, -intscaley). It will also crop the frame by default if the resolution is too small to hold 1:1 pixel mapping.
Question: If the resolution is too small will we be able to adjust the view area or will it always be centered?
Yessssss! :notworthy:
I know people don't care much about .png overlays today, they are anticipating BGFX shaders support which is only natural, but it is important to note that integer scaling will make creating/using those .png's immensely easier; goodbye painful manual settings for a myriad of resolutions!
It's not such a weak solution with a bit of work, and the cpu/gpu cost is nil.
A few screenshots attached for posterity since I suspect the .png overlays support will disappear one of those days. ^^
(using GM 0.171, a 42" full-hd tv, a 21" 4:3 monitor, and a 1600x900 laptop)
(I could have made the knights and sf2hf 'oversized' 4x5 but it was too big on my 42" ^^)
(aside from progear and futari using only shades or grey, all other use almost exclusively RGB dots and strips)
I noticed in the 0.172 release notes they say that a few options from GroovyMame have now been implemented thanks to Calmity being on the official MAME team now, what actual options have been implemented and does this mean in the future there wont be the need for GroovyMAME anymore?
-Implemented integer scaling in core renderer [Calamity]
* Moved -unevenstretch option to core renderer.
-unevenstretch: fractional stretching (default)
-nounevenstretch: integer scaling
* Added new options to core renderer:
-unevenstretchx: fractional stretching on horizontal axis, integer
scaling on vertical axis
-intscalex: horizontal integer scale factor, default is 0 (auto)
-intscaley: vertical integer scale factor, default is 0 (auto)
$ dos2unix hi_0171.diff
$ dos2unix 0171_groovymame_015m.diff
$ cd mame0171s
$ for file in `grep 'diff -Nru --binary ' ../hi_0171.diff ../0171_groovymame_015m.diff | cut -d ' ' -f 4`; do dos2unix $file; done
$ patch -p0 -E < ../hi_0171.diff
$ patch -p0 -E < ../0171_groovymame_015m.diff
Just posting for future people who have agony getting these patches to apply on a unix machine (every single hunk is rejected), since I don't see any info about this in the thread:
[...]
I'm not sure if this is what the --binary option mentioned in the OP is supposed to do, but it has no effect for me.
unix2dos 3rdparty/bgfx/include/bgfx/bgfx.h 3rdparty/bgfx/include/bgfx/c99/bgfx.h 3rdparty/bgfx/include/bgfx/c99/bgfxplatform.h 3rdparty/bgfx/src/bgfx.cpp 3rdparty/bgfx/src/bgfx_p.h 3rdparty/bgfx/src/config.h 3rdparty/bgfx/src/renderer_d3d11.cpp
@Calamity How are you finding the changes to 0.172 - I noticed syncrefresh option has moved again.... :dizzy:
Just had a look, Yes no change there as you remove it from osd & put it in emu.
But it was previously available through machine options, And that is no longer the case.
I'm not sure if soundsync was ever used in grooymame but we have better replacement - syncrefresh which works great till 171.
@@ -1077,6 +1104,9 @@
osd_ticks_t tps = osd_ticks_per_second();
m_speed_percent = delta_emutime.as_double() * (double)tps / (double)delta_realtime;
+ if (m_syncrefresh && m_throttled)
+ m_speed = m_speed_percent * 1000;
+
// remember the last times
m_speed_last_realtime = realtime;
m_speed_last_emutime = emutime;
Also is the soundsync patch now working again? I had problems with it since 0.146 on my non groovymame setup.
http://forum.arcadecontrols.com/index.php?topic=122814.0 (http://forum.arcadecontrols.com/index.php?topic=122814.0)
diff -ruN ../mame/src/emu/machine.h ./src/emu/machine.h
--- ../mame/src/emu/machine.h 2012-04-22 07:07:48.000000000 +0200
+++ ./src/emu/machine.h 2012-09-05 19:42:05.000000000 +0200
@@ -310,6 +310,8 @@
debugcpu_private * debugcpu_data; // internal data from debugcpu.c
generic_machine_private *generic_machine_data; // internal data from machine/generic.c
+ double speed_percent; // most recent speed percentage
+
private:
// internal helpers
void start();
diff -ruN ../mame/src/emu/video.c ./src/emu/video.c
--- ../mame/src/emu/video.c 2012-04-12 09:35:58.000000000 +0200
+++ ./src/emu/video.c 2012-09-05 19:42:05.000000000 +0200
@@ -995,7 +995,8 @@
osd_ticks_t delta_realtime = realtime - m_speed_last_realtime;
osd_ticks_t tps = osd_ticks_per_second();
m_speed_percent = delta_emutime.as_double() * (double)tps / (double)delta_realtime;
-
+ machine().speed_percent = m_speed_percent;
+
// remember the last times
m_speed_last_realtime = realtime;
m_speed_last_emutime = emutime;
@@ -203,6 +205,13 @@
if (stream_buffer == NULL)
return;
+ // if we are active, update the sampling frequency
+ if (g_current_machine->speed_percent > 0.0f && g_current_machine->switchRes.cs.soundsync)
+ {
+ IDirectSoundBuffer_SetFrequency(stream_buffer,
+ g_current_machine->sample_rate() * g_current_machine->speed_percent);
+ }
+
Wow, this is crazy.
I'm alive, and working 60 hours per week. I'm currently just able to check BYOAC and the mailing list while on the toilet. Sorry, I should have provided some proof of life.
GM had development stalls in the past, it just wasn't so obvious because the update policy of mainline was different. A big overhaul like the ones required for the rewrites of Switchres (version 14 & 15), took me 10-15 days of full-time coding and testing each.
Unfortunately the industry I work in has no predictable holidays and has nothing to do with coding. I can only do serious coding work when my real work load is low enough. A different matter is mantaining a diff in sync with mainline that usually takes me 3-4 hours per month.
Please consider the fact that I recently released CRT Emudriver 2.0 (January 2016). This thing took me a full month of work between Windbg (reverse-engineering of Catalyst), VMMaker/Arcade OSD, GroovyMAME update and beta testing. Well, the point is that I had the whole concept ready in March 2015, but I had to wait for 9 months until I had the time to implement it. I could be implementing the same over the Crimson driver already to support bleeding edge cards but I simply can't afford taking a free month so often.
The possibility of merging GM into mainline is the best thing that could ever happen to GM, devs attitude has been totally receptive, so please be patient and let me do things right.
So all you need is to chillout. What would you do, after a 60hours week? GM is not dead, he will come back, just leave him time. All this hunt for the newest is not healthy anyway :D . There is not much interesting for GM since 0171, consider that too.
I think all anyone wanted to know was that GM wasn't dead
In the meantime, would anyone know offhand what it would take to update the 0171 diff file to make it patchable with the latest MAME source?
If it was easy, Calamity would have already done it.
Nevermind, figured it out...unified diffs.If it was easy, Calamity would have already done it.
It's not difficult. It is time consuming though, but straightforward.
Once I get done with the changes and testing, I'll either share a diff or just the whole binary.
Ok, I was wrong. I take back what I said. This commit pretty much puts my plans in a bind: https://github.com/mamedev/mame/commit/852bd80d455c46a066fa4f1e6267f679b0096231
It's looking like they're killing off d3d9 with that? I guess BGFX from now on.
H:\games\mame0175b_64>mame64 dkong -video d3d -v
Video: Monitor 00000000003c3ec8 = "\\.\DISPLAY10" (primary)
Direct3D: Using Direct3D 9