[uae] Re: My "Arcade e-uae"
- From: Fabien Meghazi <agr@xxxxxxxxxxxx>
- To: uae@xxxxxxxxxxxxx
- Date: Thu, 12 Nov 2009 09:38:55 +0100
Mark,
Please, tell me more about your monitor. Can you tell me the make and model ?
PS: have you tried opengl w/vsync instead of directfb for flicker/tear
less emulation ? For my mame cab I used framebuffered advmame but
since sdlmame with vsync I can run under X with an emulation as smooth
as advmame in framebuffer.
I don't know much about directfb but I tought it was a framebuffered
gfx environment that could provide
sdl api and that it was a "replacement" for X. Seems I'm wrong.
Anyway, I'm interested having more information about your setup.
Before the CRT screens disappears from the planet earth, I'd like to
ensure that I'll have some spare screens so I'll be able to fully
enjoy good looking amiga demos when I'll be at the retirement house.
So far, I found a big CRT screen for 1€ on ebay but it seems to only
use standard vga resolution :
http://www.amigrave.com/upload/posts/moniteur_sony/P1000812-01.JPG
On Wed, Nov 11, 2009 at 12:09, Mark Lenders <kokoko3k@xxxxxxxxx> wrote:
> My "Arcade Uae"
> ------------------------------
> ---------------------
> Some time ago i finally got my e-uae running like a real amiga
> in an arcade cabinet.
> "like a real amiga" means to me that i have a good old CRT screen
> which runs at 768x576@50hz
> and that e-uae delivers "ultra smooth/tear free" pictures to it.
>
> The patches here are for e-uae 0.8.29; and are intended to be used
> with a Xorg free system;
>
> For perfect smoothness, i use:
> SDL
> DirectFb (export SDL_VIDEODRIVER=directfb)
> OSS Sound (export SDL_AUDIODRIVER=dsp)
> fbset to make a near 50Hz framebuffer resolution.
>
> Please, ignore patches to keybuf.c if you don't intend to have a
> Mame like layout for e-uae.
> As i really don't know how to program C/C++ you may find the code dirty,
> sorry for that.
>
>
> ----------------------------
> cfgfile.c, include/options.h:
> ----------------------------
> Added gfx_vsynctime_hack:
> A signed integer which tunes vblank time emulation.
> If you have a monitor which has a vertical frequency not
> exactly multiple of the emulated one, even if you force vsync,
> you'll notice some imperfections when a game scrolls.
> Play with gfx_vsynctime_hack speedup or slowdown emulation
> and find a value which will match your monitor refresh rate
> with the emulated one.
> During emulation, additional console messages are printed, like:
> Koko: vsynctime before hack #number
> Koko: vsynctime after fix #number
> Please note that audio pitch is not preserved.
>
> Added gfx_vsynctime_hack_step:
> To easilly find the best gfx_vsynctime_hack value,
> it is possible to tune it runtime via hotkeys.
> gfx_vsynctime_hack_step is an integer step an hotkey press will
> add or subtract from the current "gfx_vsynctime_hack".
> Current values are written to standard output; so that the user
> can write them back in the configuration file once he found the best
> value.
>
> Added gfx_assumebpp_hack:
> This is for people using sdl+svgalib as output driver.
> i found that sometimes sdl fails to reports the correct screen bitdepth
> to the underlying svgalib driver;
> use gfx_assumebpp_hack integer to force it:(8,15,16,24,32)
> If you don't use xorg, i strongly suggest you to switch to sdl+directfb
> for perfect vsync emulation.
>
> ----------------------------
> gfx-sdl/sdlgfx.c
> ----------------------------
> forced vsync=1
>
> Just some debutg messages which could help you find why thew screen is
> tearing
> in sdl mode (fullscreen,is_hwsurface)
>
> Force screen bitdepth according to user prefs.
>
> ----------------------------
> main.c
> ----------------------------
> As we added gfx_assumebpp_hack, here we moved graphic initialization
> after command line parsing function.
> There is also a little hack which change the value of vsynctime_hack
> from 0 to -1 (you won't notice that).
> It's a dirty thing, but i'm not really a c programmer, and that solved
> a bug when changing gfx_vsynctime_hack runtime from positive to negative
> values (if someone can correct it, it is welcome!)
>
>
>
> ----------------------------
> custom.c
> ----------------------------
> put vsynctime correction to stdout
>
>
> ----------------------------
> inputdevice.c,inputevents.c,include/keyboard.h,gfx-sdl/sdlkeys.c
> ----------------------------
> Added hotkeys function:
> AKS_INCVSYNCTIME: Increase vsynctime by defined step
> AKS_DECVSYNCTIME: decrease vsynctime by defined step
> ...Also write relative messages to stdout.
>
>
> ----------------------------
> keybuf.c
> ----------------------------
> Modified keymapping to mame like mapping to use e-uae
> in a standard-jamma cabinet:
> I use e-uae in an arcade cabinet (which runs also mame),
> so this is very useful for me:
> right control -> control (Player 1 FIRE1)
> right shift -> left alt (Player 2 FIRE2)
> R -> (Player 2 UP)
> D -> (Player 2 LEFT)
> G -> (Player 2 RIGHT)
> F -> (Player 2 DOWN)
> A -> (Player 2 FIRE1)
> S -> (Player 2 FIRE2)
>
> ----------------------------
> sd-alsa/sound.c
> ----------------------------
> Nothing really useful, just some printf.
>
>
> You can download the patches here:
> http://wpage.unina.it/aorefice/a-uae-patches.tar.gz
--
Fabien Meghazi
Website: http://www.amigrave.com
Email: agr@xxxxxxxxxxxx
IM: amigrave@xxxxxxxxx
Other related posts:
