MAMEWorld Forums - The Loony Bin

> > Techniques like Beam Racing, which requires a lot more effort to actually do right,
> > can take out the extra frame of lag from the PC side and match how the games would
> > run on hardware (to the nearest line, not pixel, but nobody is measuring response
> > times in pixels right now) Run-ahead is an ugly cheat. Unfortunately as people
> would
> > rather cheat it seems there is less incentive to do it properly (as doing it
> properly
> > actually will requiring rewriting every single driver to have 100% proper line
> > rendering and buffering logic emulated at the exact times the hardware does it)
>
>
> Isn't that what ZX Spectrum emulation would require in order to achieve 100%
> accuracy? If that's the case, maybe its driver could be used for testing any Beam
> Racing implementations, whenever somebody wants to attempt a rewrite of it.

Beam Racing is not related to ZX Spectrum emulation, no, it's a presentation technique that happens to require emulation that is already scanline accurate in order to implement.

For ZX Spectrum emulation you do need accurate screen timing, you actually need accurate *pixel* timing, as many effects change things during the horizontal scan, right before video data is pulled. Byuu found the same for that one SNES game which changes the palette during the horizontal scan at a very specific position in order to draw a shadow.

*without* scanline accurate rendering Beam Racing becomes difficult as the rendering / execution load across your screen is unbalanced, and once using techniques like beam racing you're effectively dealing not with 'frames per second' but 'scanlines per second' and your emulation must be able to deliver each single scanline (assuming 240 lines, 60 fps) within 1/14400th of a second as opposed each single frame within 1/60th of a second. If any one *scanline* doesn't render in time then the entire framerate drops.

The problem with a lot of systems in MAME and other emulators is that they're framesynced and assume that everything is drawn at one specific point in the frame which means the load is heavily unbalanced (effectively the last scanline takes 240x as long as every single other one) and in many cases real buffers that existed on hardware to prevent graphic corruption if spriteram etc. is updated midscreen aren't being emulated, and CPU execution times don't have to be as accurate either as long as they're relatively accurate within frame. Simply forcing 'scanline' updating to split the load evenly for an emulation that hasn't been properly developed will create a lot of glitches due to other bad assumptions in the emulation.

So yeah, Beam Racing demands accurate emulation to implement, but visually accurate emulation doesn't demand beam racing.