Build Your Own Arcade Controls Forum
Software Support => GroovyMAME => Topic started by: Foxhole on January 31, 2016, 03:36:54 pm
-
Hi, i seem to be having a problem with the frame delay feature.
Whenever i set the frame delay above 5 i get some static tearing on the upper side of the screen.
It's a crt screen with crt emudriver 1.2b and super resolutions, win7 x64.
The video mode is ddraw, could that possibly be the problem?
As far as i know this problem only happens with LCDs and high resolutions.
On my main pc with the lcd i get that screen tearing no matter which frame delay i choose.
On my main pc i tried playing around with the vsync offset setting, didn't do much help but change the location of the tearing.
On the crt emudriver pc i didn't play around with the offset since from what i understand that shouldn't happen in the first place.
I should also mention that i am currently using gm asio, but it also happens with the regular groovymame.
#
# CORE CONFIGURATION OPTIONS
#
readconfig 1
writeconfig 0
#
# CORE SEARCH PATH OPTIONS
#
rompath ..\..\roms\mame
hashpath hash
samplepath samples
artpath artwork
ctrlrpath ctrlr
inipath .;ini
fontpath .
cheatpath cheat
crosshairpath crosshair
#
# CORE OUTPUT DIRECTORY OPTIONS
#
cfg_directory cfg
nvram_directory nvram
input_directory inp
state_directory sta
snapshot_directory snap
diff_directory diff
comment_directory comments
#
# CORE OUTPUT DIRECTORY OPTIONS
#
hiscore_directory hi
#
# CORE STATE/PLAYBACK OPTIONS
#
state
autosave 0
playback
record
mngwrite
aviwrite
wavwrite
snapname %g/%i
snapsize auto
snapview internal
snapbilinear 1
statename %g
burnin 0
#
# CORE PERFORMANCE OPTIONS
#
autoframeskip 0
frameskip 0
seconds_to_run 0
throttle 1
syncrefresh 0
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 1
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.65
effect none
#
# CORE VECTOR OPTIONS
#
antialias 1
beam 1.0
flicker 0
#
# CORE SOUND OPTIONS
#
samplerate 48000
samples 1
volume 0
#
# CORE INPUT OPTIONS
#
coin_lockout 1
ctrlr
mouse 0
joystick 1
lightgun 0
multikeyboard 0
multimouse 0
steadykey 0
ui_active 0
offscreen_reload 0
joystick_map auto
joystick_deadzone 0.3
joystick_saturation 0.85
natural 0
joystick_contradictory 0
coin_impulse 0
#
# CORE INPUT AUTOMATIC ENABLE OPTIONS
#
paddle_device keyboard
adstick_device keyboard
pedal_device keyboard
dial_device keyboard
trackball_device keyboard
lightgun_device keyboard
positional_device keyboard
mouse_device mouse
#
# CORE DEBUGGING OPTIONS
#
verbose 0
log 0
oslog 0
debug 0
update_in_pause 0
debugscript
#
# CORE MISC OPTIONS
#
drc 1
drc_use_c 0
drc_log_uml 0
drc_log_native 0
bios
cheat 1
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
console 0
#
# CORE MKChamp OPTIONS
#
disable_hiscore_patch 0
disable_nagscreen_patch 0
disable_loading_patch 0
#
# CORE SWITCHRES OPTIONS
#
modeline_generation 1
monitor custom
orientation horizontal
connector auto
interlace 1
doublescan 1
cleanstretch 2
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 15200-15700, 49.95-62.00, 2.500, 4.634, 6.780, 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
asio_log 0
asio_device 0
asio_cal_freq 0.0
#
# OSD FONT OPTIONS
#
uifontprovider auto
#
# OSD DEBUGGING OPTIONS
#
debugger auto
watchdog 0
#
# OSD PERFORMANCE OPTIONS
#
multithreading 1
numprocessors auto
bench 0
#
# OSD VIDEO OPTIONS
#
video ddraw
numscreens 1
window 0
maximize 1
keepaspect 0
unevenstretch 0
waitvsync 0
#
# OSD PER-WINDOW VIDEO OPTIONS
#
screen auto
aspect auto
resolution 2560x0
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
#
# OSD FULL SCREEN OPTIONS
#
switchres 1
#
# OSD SOUND OPTIONS
#
sound auto
audio_latency 1.0
#
# WINDOWS DEBUGGING OPTIONS
#
debugger_font "Lucida Console"
debugger_font_size 9
#
# WINDOWS PERFORMANCE OPTIONS
#
priority 1
profile 0
#
# WINDOWS VIDEO OPTIONS
#
prescale 1
menu 0
#
# DIRECTDRAW-SPECIFIC OPTIONS
#
hwstretch 0
#
# DIRECT3D-SPECIFIC OPTIONS
#
filter 0
#
# DIRECT3D POST-PROCESSING OPTIONS
#
hlsl_enable 0
hlslpath hlsl
hlsl_prescale_x 0
hlsl_prescale_y 0
hlsl_preset -1
hlsl_write
hlsl_snap_width 2048
hlsl_snap_height 1536
shadow_mask_alpha 0.0
shadow_mask_texture aperture.png
shadow_mask_x_count 320
shadow_mask_y_count 240
shadow_mask_usize 0.09375
shadow_mask_vsize 0.109375
curvature 0.03
pincushion 0.03
scanline_alpha 1.0
scanline_size 1.0
scanline_height 1.0
scanline_bright_scale 1.0
scanline_bright_offset 0.0
scanline_jitter 0.0
defocus 0.0,0.0
converge_x 0.3,0.0,-0.3
converge_y 0.0,0.3,-0.3
radial_converge_x 0.0,0.0,0.0
radial_converge_y 0.0,0.0,0.0
red_ratio 1.0,0.0,0.0
grn_ratio 0.0,1.0,0.0
blu_ratio 0.0,0.0,1.0
saturation 1.4
offset 0.0,0.0,0.0
scale 0.95,0.95,0.95
power 0.8,0.8,0.8
floor 0.05,0.05,0.05
phosphor_life 0.4,0.4,0.4
#
# NTSC POST-PROCESSING OPTIONS
#
yiq_enable 0
yiq_cc 3.59754545
yiq_a 0.5
yiq_b 0.5
yiq_o 1.570796325
yiq_p 1.0
yiq_n 1.0
yiq_y 6.0
yiq_i 1.2
yiq_q 0.6
yiq_scan_time 52.6
yiq_phase_count 2
#
# VECTOR POST-PROCESSING OPTIONS
#
vector_length_scale 0.8
vector_length_ratio 500.0
#
# BLOOM POST-PROCESSING OPTIONS
#
vector_bloom_scale 0.3
raster_bloom_scale 0.225
bloom_lvl0_weight 1.0
bloom_lvl1_weight 0.21
bloom_lvl2_weight 0.19
bloom_lvl3_weight 0.17
bloom_lvl4_weight 0.15
bloom_lvl5_weight 0.14
bloom_lvl6_weight 0.13
bloom_lvl7_weight 0.12
bloom_lvl8_weight 0.11
bloom_lvl9_weight 0.10
bloom_lvl10_weight 0.09
#
# FULL SCREEN OPTIONS
#
triplebuffer 0
full_screen_brightness 1.0
full_screen_contrast 1.0
full_screen_gamma 1.0
#
# INPUT DEVICE OPTIONS
#
dual_lightgun 0
-
First of all, frame_delay should be used as a per-game setting. The ASIO build has a benchmark that can help you deduce what frame_delay setting your PC is capable of running the game with. It should not be used as a static setting, since the drivers vary very much in speed.
What game are you running? Or does it tear with all games you've tested?
-
First of all, frame_delay should be used as a per-game setting. The ASIO build has a benchmark that can help you deduce what frame_delay setting your PC is capable of running the game with. It should not be used as a static setting, since the drivers vary very much in speed.
What game are you running? Or does it tear with all games you've tested?
Basically i set the frame delay to 7 for the most part since my pc can run most games with that setting, while the games that are more demanding get a specific frame delay setting in a separate ini, is that a problem? Everything runs 100% speed that way.
It tears with every game that i tested, unfortunately.
I care mostly about the crt emudriver pc (Emulation pc) and not my main pc.
On my emulation pc i do set the frame delay game by game since it's a slower pc than my main one.
-
Hi Foxhole,
A super resolution is indeed a high resolution. You said you're on CRT Emudriver 1.2b, I understand you must be using a card from the HD 4000 family. Your card is probably struggling with the scaling required. This only gets exposed when frame delay is enabled, because this feature requires the whole gpu processing to happen in a fraction of the frame period. I know what you're thinking: wasn't super resolutions the way to go with Windows 7? Yes, it is. But frame delay is an experimental feature, and general assumptions surrounding MAME don't fully apply here. One such assumption is gpu power doesn't matter with MAME. It turns out it does matter with frame delay enabled, because the faster the gpu processing is done, the most reliably frame delay will work. I've noticed how my cheap HD 6450 card behaves better on this regard than any previous HD 4000 card I've tested.
Anyway, you should not be using DirectDraw unless you have a very good reason. DirectDraw is known to be slower.
-
Basically i set the frame delay to 7 for the most part since my pc can run most games with that setting, while the games that are more demanding get a specific frame delay setting in a separate ini, is that a problem?
Everything runs 100% speed that way.
The problem is that if the PC is not capable of running the game with the specified frame_delay, tearing will be unavoidable. But I've only tested this with d3d, I don't know how it works with ddraw.
It tears with every game that i tested, unfortunately.
I care mostly about the crt emudriver pc (Emulation pc) and not my main pc.
On my emulation pc i do set the frame delay game by game since it's a slower pc than my main one.
Ok, thanks for reporting, then please try using d3d (not d3d9ex, regular d3d seems to work better with CRT Emudriver 1.2b). Also vsync_offset will only affect d3d/d3d9ex.
Edit: Calamity was faster. :)
-
In order to know the source of the problem, create a normal resolution to run a sample game, say 320x240, and apply frame delay with it.
-
In order to know the source of the problem, create a normal resolution to run a sample game, say 320x240, and apply frame delay with it.
I'll try that.
I should also try changing the video mode, but i'm kinda confused now.
If i set the video mode to d3d i have to set the frame delay to 1, right? to fix the flip queue.
Wouldn't that be slower than ddraw with frame delay of 0?
So what should be the best option for me?
Video card: HD 4350
-
If i set the video mode to d3d i have to set the frame delay to 1, right? to fix the flip queue.
You use the same values for any API. The frame queue is bypassed by any value greater than 0.
-
What i mean is, d3d is faster than ddraw, but if i don't use a frame delay of at least 1 i'm going to get input lag due to the flip queue.
So what i'm trying to understand is, what is faster, d3d with a frame delay of 1 or ddraw with a frame delay of 0?
-
What i mean is, d3d is faster than ddraw, but if i don't use a frame delay of at least 1 i'm going to get input lag due to the flip queue.
So what i'm trying to understand is, what is faster, d3d with a frame delay of 1 or ddraw with a frame delay of 0?
With frame_delay set to 1 you're always going to sacrifice 1/10 of frame time of processing power due to throttling, which would otherwise be used for emulation, it probably won't matter for most games.
@Calamity
Does your multithreading implementation square off other performance differences related to ddraw/d3d?
-
So what i'm trying to understand is, what is faster, d3d with a frame delay of 1 or ddraw with a frame delay of 0?
Speed and latency are different categories. D3D is always faster, but has more input latency if you don't use frame_delay. D3D9ex without frame_delay is as fast as D3D and has as low latency as DirectDraw.
-
@Calamity
Does your multithreading implementation square off other performance differences related to ddraw/d3d?
As long as syncrefresh is used, the video part behaves the same as when single threaded. It's the input processing what may see a marginal benefit.
-
So i tried several combinations.
Super resolution + D3D/9ex + Frame delay 6 or 7 = Static tearing
Normal resolution + D3D/9ex + frame delay 6 or 7 = No tearing
Normal resolution + DDraw + frame delay 6 or 7 = No tearing
So yes, the card isn't fast enough for the super resolution, i guess. :\
Any recommendations for a better card?
Also tested ddraw vs d3d/9ex, and d3d indeed was faster.
Is there even a point using d3d and not d3d9ex?
-
So yes, the card isn't fast enough for the super resolution, i guess. :\
Any recommendations for a better card?
Also tested ddraw vs d3d/9ex, and d3d indeed was faster.
Is there even a point using d3d and not d3d9ex?
I seem to recall d3d providing better ASIO performance with high frame delay values on 1.2b, but this may be machine specific. If there's no difference on your machine there's no reason not to use ex.
Have you tried to get rid of the tearing with vsync offset?
Edit: Never mind, this would be equivalent of lowering the frame delay value.
-
I will try that later on.
EDIT: Then i shall not try that. :P
-
Does the tearing position move between fd6/fd7 and super resolutions? Does it tear with fd1? If it moves and/or does not tear with fd1, would you mind doing a quick benchmark with the games you're testing, namely to run each of them with -bench 180, and report what the 'Frame delay/percentage:' line near the end of the log reports? The thing is, you may be hitting the present code _very_ late. This would indicate that you're using a frame_delay setting which is a bit too high, and this needs to be ruled out. Are you getting 'missed retrace' entries in the log (needs to be run with -v)?
Are you using the same games to test, Bad Dudes/Ninja Masters/Comix Zone/SFA?
On my GM rig the maximum fd setting I can use with SFA is 7, Comix Zone 6 and Ninja Masters 8. How fast is your emulation PC?
I will try that later on.
EDIT: Then i shall not try that. :P
Yeah sorry about that. :)
-
Does the tearing position move between fd6/fd7 and super resolutions?
I'll need to test again to give you an answer about that.
Does it tear with fd1? If it moves and/or does not tear with fd1, would you mind doing a quick benchmark with the games you're testing, namely to run each of them with -bench 180, and report what the 'Frame delay/percentage:' line near the end of the log reports?
It does not tear with fd1, i'll try the bench and let you know.
-
On my GM rig the maximum fd setting I can use with SFA is 7, Comix Zone 6 and Ninja Masters 8. How fast is your emulation PC?
The emulation pc with the d2x is actually isn't that fast. It's a quad core q8200 oc'ed to 2.9Ghz.
The one with the audigy 4, with the kx drivers, is in fact the faster one, I5-4570 3.2Ghz, and that's the one with the crackles, lol.
I tested the game cybattler with fd6 and 7, and it doesn't look like the tearing position moves, but on fd7 it's more visible.
I also used bench on the game. I've included 3 logs, the bench, fd6 and fd7.
-
As for my pc with the lcd, If i can remove the tearing using the vsync offset setting, do i really need to lower the frame delay?
Setting vsync_offset to 110 seems to remove the tearing for most games i've tried, but according to this i also need to lower the frame delay:
Notice that you'll need to lower your frame_delay value proportionally to the amount of lines you set in -vsync_offset.
Is it really necessary to lower the frame_delay even though i can remove the tearing without doing so?