80s Synth Pop wrote: » unlucky Mine arrive this morning too and thankfully it's all in one piece. The basic packaging was a risk with something as fragile as this.
CiDeRmAn wrote: » Giving some serious thought to converting my Asteroids cab to Retropie. I'd need to change the spinner to a compatible one for the Pie.
Inviere wrote: » Not to knock the Pi, it's a grand little gizmo, but I just can't hack anything on it after using RetroArch with the run-ahead latency reduction feature...the input lag on a Pi is a killer now for me. Funds willing of course, but if you could get a low end/basic PC in there you'd have a far better emulation experience with it, than you would a Pi
KeRbDoG wrote: » Interesting - would the input lag with the Pi be via the GPIO port or a USB adapter or is it because of RetroArch?
The Last Bandit wrote: » The actual time from when you press the button to when its detect/processed/filtered up to the emulator hasn't changed at all.
o1s1n wrote: » Any idea how it works? So I press a button on my controller, that is processed and appears on an LCD screen that has lag...apart from predicting what I'm going to press and doing it before I actually press the button, I can't really figure out how that works if the screen has lag?
Here is a more detailed explanation on runahead by its author Dwedit. How the Run-Ahead feature currently works: There are two modes of operation. Single-Instance Mode Two-Instance Mode In Single-Instance mode, when it wants to run a frame, instead it does this: Disable audio and video, run a frame, Save State Run additional frames with audio and video disabled if we want to run ahead more than one frame Enable audio and video and run the frame we want to see Load State All save states and load states are done to ram and never reach the disk. In Two-Instance mode, it does this: Primary core does Audio only, then saves state Secondary core loads state, runs frames ahead discarding audio and video, then runs a frame with video only. For performance reasons, it only resyncs the secondary core when input is dirty, otherwise it keeps running additional frames on the secondary core while the input is clean. Why bother with Two-Instance mode at all? Many of the cores do not leave audio emulation in a clean state after loading state, so you would get buzzing. Using Two-Instance mode makes the primary core not do any load states and avoids that. In Single-Instance mode, it is possible to improve performance further by running ahead without loading state while input is clean, but I am not currently doing that. I'd imagine there'd be issues if calling the "run a frame" function left you in a state further along than a single frame. I'm also not doing any speculative inputs at all.
The Last Bandit wrote: » Its basically magic.
80s Synth Pop wrote: » I must try that "run ahead" system out. Never used it when it first came out as the mame devs said it was an ugly hackhttp://www.mameworld.info/ubbthreads/showflat.php?Cat=&Number=378841&page=&view=&sb=5&o=&vc=1 Interested now to see how it runs.
Skerries wrote: » let us know how this goes as I don't fancy trying to drill out this for my extra buttons
Shapey Fiend wrote: » I always think it's odd when people theme arcade machines around non-arcade games.
Jerichoholic wrote: » One of the lads from Arcade1up was on We Talk Games. He strongly hinted at a cabinet with a wheel and pedals for racing games coming soon.http://feeds.feedburner.com/WeTalkGames