trap15 wrote:No, they're saying precisely the opposite. There's no way all of these emulators are even nearly cycle accurate. Most likely, they're just emulated in software on an embedded ARM platform. Which is what X-in-1 MAME bootleggers have been doing for the past... 10 years now?
That's where I don't understand the point of these things versus a pc. Beside the console "look and feel", maybe the input lag. And of course this naive feeling of achieving something intelligent when a game works after blowing into the cartridge
The word 'input lag' has brought up a few time in this thread, is it really that much of a bug bear?. I myself Have never (that I can remember) been playing a game on emulator and died, got hit, crashed etc because I thought that I pressed an imput and the emulator didn't responses in time.
What in this instance is the main factor of input lag on pc emulation?, the emulator itself, CPU, USB, controller, gpu, display??. I would have bought with the coming age of emulators, I mean how long they been around for now 18+ years for the PC platform?, and the advancement in PC tech that input lag would of been something in infentcy of emulators and would have be ironed out by now!?
lettuce wrote: I mean how long they been around for now 18+ years for the PC platform?, and the advancement in PC tech that input lag would of been something in infentcy of emulators and would have be ironed out by now!?
I could wear I've read somebody write that emulation is actually much harder than rocket science. Rockets just let you send things on trajectories and blow shit up. John Carmack blows shit up for relaxation, instead of futzing about with obscure emulation issues that make your hair go gray prematurely.
Thanks for that link, there were a few good tidbits in it I didn't see in the article on his site. Kind of funny how he fails to see that yes, preserving the (written for broken emulation) community productions from the early SNES emulation scene is a valuable goal in of itself...his argument only holds if you subscribe to the same kind of specious "only officially released things count for emulation" view. Personally I think the best approach would be somewhat like (but not as messy as) the approach attempted (but also not really achieved) by some DOOM ports, where you have flags to enable or disable various behaviors. But probably the most straightforward way is, as he suggests, the future-proof one of only spending time on making accurate the target system (in most cases, the original SNES; in others, the various bad implementations of it) and not caring about other scenarios. There's also a lot to be said for allowing certain values to be tweaked (i.e. overclocking of various components) which can and in fact are achieved on the original system.
And now for some words of wisdom from the Retrogaming Roundtable, preserved for ALL TIME
720p video output. Analog RGB signals, even when converted into digital progressive scan, can produce a maximum 240p. 720p is an HD resolution that simply not possible with the original hardware of any of the systems supported.
Savestates, button remapping, speed settings, audio interpolation, built in cheats, etc. These are all standard emulation options only a computer offers.
Future firmware updates. Firmware means an OS, means computer.
"Our aim is 100% compatibility". The only way to achieve that through clone hardware is through emulation, which means a computer.
Ed Oscuro wrote:Kind of funny how he fails to see that yes, preserving the (written for broken emulation) community productions from the early SNES emulation scene is a valuable goal in of itself...his argument only holds if you subscribe to the same kind of specious "only officially released things count for emulation" view.
He's not saying that. He take the example of Zsnes written in x86 assembly, who can die at any moment if microsoft decide to drop 32bit compatibility (which will not happen anytime soon for sure, but still can happen), and with it the lost of all traductions and hacks written exclusively for this emulator (which are basically patches for an emulator who use patches to work).
Instead he proposes that these hacks and traductions are written a way they work with the real hardware, and then emulators have to deal with that to run them (accurately or through patches).
But not every one can be able to test their traductions or hacked roms on the real hardware, so for that it's great to have something that try to approach the real thing, like an accuracy oriented emulator.
Byuu seems to be a guy quite norrow to his point of view, and difficult to understand sometime, but I think what he's trying to achieve is really benefit for emulation. With works like his, emulation will be perceived more like a way of preservation, instead of just a way of not paying for playing games.
Well, yeah, that's a reasonable point, and I've written my thoughts rather clumsily and not especially generously.
ZSNES is an example of a system whose authors have unwittingly painted themselves in a corner, and probably in large part that's due just to the realities of emulation at the time - there wasn't getting around some of the limits ending up influencing community productions, although some of the other "fixes" like removal of limits might have been poorly conceived even then (but that seems like a typical rom hacking thing to do, and not of itself a bad thing). Anyway, what should be of central importance here is whether getting support for the way the ZSNES emulator (for example) worked is a reasonable goal. Ultimately the answer is going to come down to - will any of the emulator authors be prepared to give a damn? If there is a place that emulation resources should be spent first, it's towards improving accuracy mainly, features next, and then maybe considering supporting special things that the community wants. Like the DOOM port scene I mentioned earlier, there are really two conflicting aims here - serving accuracy that can be replicated and checked against real hardware first, and then serving the community's projects, where the community is often dissatisfied with the limitations of systems but still want to feel like they're playing SNES games, or where they just want speed over accuracy, or they want compatibility with old versions of the emulator as the target platform, rather than the real SNES.
If the community was full of people who would program things the way they liked, then perhaps we would have emulators that put more focus on the second group. However committing oneself to the project of building an emulator seems, generally, antagonistic towards being predisposed towards wanting to support things that are at odds with the project of emulation, even if more than reasonable accuracy has been achieved. byuu admits that there are diminishing returns in continuing to refine bsnes, and even talks about something like what I had been amusedly mulling for years - diode-level emulation - but at some point the question should be asked, "does it make sense to keep going after this, instead of looking at other areas of the SNES scene that might be well addressed by a competently written emulator?" He certainly seems to know exactly what some of the effects are that could be improved. Of course I make no judgments about whether we are close to the point where it makes sense to "give up" on the emulator, and actually my fondest wish is not that retro productions of the emulation community be serviced, but that other systems also get highly accurate emulators in this model, so I admit I rather share his view.
Of course there is also good news here - since higan is open source, people can screw around with it and change what they like! Of course it might take an emulator author to begin with in understanding the implication of changes from one emulator to another...
Would this really have that much less input lag than a PC? Some small things aside, most of the things that causes input lag in emulation seems it would be the same across all platforms.
As far as emulation is concerned I will not be happy with anything less than emulating the planet earth of the 1990's with subatomic accuracy. That way you can go back and actually enjoy the games when they were new and you get the benifit of the cultural phenomenon surrounding them at the time being emulated as well.
Until that level of emulation is available for me to jack my brain into I'll stick to my SNES/CRT combo.
I'd like some real clone hardware, or at least some new replacement parts for the real systems. None of this emulation for me.
Subatomic emulation of the earth...haha, that might not even be theoretically possible. We don't know what (if anything) directs quantum-level variations (i.e. randomness).
Fudoh wrote:Little bit excited about the GBA functionality though - shouldn't be too hard to achieve better results than through a Cube+GBA player.
+1. I would love to have a compact GBA -> TV solution that looks decent. Sure, I have a GCube + GBA player + Component cable, but something in me despises requiring a disc based system to get the job done.
-ud
Fudoh wrote:Little bit excited about the GBA functionality though - shouldn't be too hard to achieve better results than through a Cube+GBA player.
+1. I would love to have a compact GBA -> TV solution that looks decent. Sure, I have a GCube + GBA player + Component cable, but something in me despises requiring a disc based system to get the job done.
-ud
PC emulators are pretty good, better than the GC player at least. Of course if you want to play on a real GBA and PC emulators with the same saves, you'll want to use a flash cart.
Maybe something like the Retrode will be usable for things like that in the future, but at the moment it doesn't support reading/writing GBA saves.
The Gameboy player for Gamecube uses hardware that's almost identical to an actual Gameboy, how would using some PC emulator or FPGA solution ever give better results?!
a) The Cube's video output isn't the best, even if it's 480p and b) the GBA player runs at the original GBA speed, which is not exactly the 59.94Hz the cube's video out is working with. The result is a slight judder in smoothly scrolling games. With an emulator the GBA games run v-synced to the output.
The GC Player also for some weird reason manages to end up with more input lag on a CRT than VBA-M does on my Panasonic plasma. After five minutes with the thing I decided getting GC component cables was definitely not worth it.
The cubes component output looks fine to me, much better than the Wii, for instance. I've not noticed any judder in Metroid, for instance, but now I know to look for it I probably will, thanks guys
If you're messing with the speed of emulated games in an emulator that has to have side effects too, surely? (either tearing, stuttering or more input lag for buffered frames, or perhaps slightly altering the pitch of sounds in the game like higan does?)
The GC Player also for some weird reason manages to end up with more input lag on a CRT than VBA-M does on my Panasonic plasma.
Probably due to interlacing the picture internally on the Gamecube ? AFIK the Gameboy screen was always progressive.
The cubes component output looks fine to me, much better than the Wii, for instance.
that's right, but considerably worse than a PS2 or 360 for example.
I've not noticed any judder in Metroid, for instance, but now I know to look for it I probably will,
it's a regular hickup maybe once a second. Easy to notice in Gradius.
If you're messing with the speed of emulated games in an emulator that has to have side effects too, surely? (either tearing, stuttering or more input lag for buffered frames, or perhaps slightly altering the pitch of sounds in the game like higan does?)
no side effects. That's the only real cool thing about emulation. On the GBA we're talking a speedup of maybe 0.2% - nothing you would ever notice.
Probably due to interlacing the picture internally on the Gamecube ? AFIK the Gameboy screen was always progressive.
the GBA player's output is rendered natively progressive and is only interlaced afterwards if you chose 480i output. I couldn't notice any heavy lag. Last time I used the GBA player, it was with 240p output to a CRT. Pretty awesome and very responsive.
_________________ http://raptr.com/BuckoA51
Probably due to interlacing the picture internally on the Gamecube ? AFIK the Gameboy screen was always progressive.
the GBA player's output is rendered natively progressive and is only interlaced afterwards if you chose 480i output. I couldn't notice any heavy lag. Last time I used the GBA player, it was with 240p output to a CRT. Pretty awesome and very responsive.
I can't find any option for 240p/480i, where is it, does it go by another name?
I'm running with default settings and it's definitely noticeably more laggy than the alternative.
I forgot to mention: if you're worried about sound quality (minor pitch change), I think the GBA player has to resample too? I think the GBA uses some weird 32khz-ish sample rate and unless the GC supports that... you're not getting that authentic GBA sound anyway.
why would resampling hurt the audio quality ? Basically all audio on your PC is resampled to your audio card's output sample rate. Nothing wrong about that, is there ? Resampling doesn't change the pitch or the sound (unless you're downsampling).
that's right, but considerably worse than a PS2 or 360 for example.
I don't know as I'd agree with PS2, the PS2's component seems quite noisy, or at least very susceptible to noise. Maybe quality varies between consoles, and I have a 'Good' Gamecube (or just a poor PS2, more likely). Last game I played on GBA was Minish Cap and that was lovely, my curiosity is piqued enough to investigate this further in the future though.
no side effects. That's the only real cool thing about emulation. On the GBA we're talking a speedup of maybe 0.2% - nothing you would ever notice.
Yes I'd generally agree with that, it's why I like Neo Geo games on the emulator (that and I'm too poor for the original hardware), but having had problems with tearing and stuttering in various emulators too, I would have thought there were always trade-offs even for altering the speed you run a game by a tiny fraction. Must do more reading.
why would resampling hurt the audio quality ?
Personally I was talking more about a tiny pitch shift due to the game running at a different speed, not something you'd really notice but a trade-off in accuracy, if you like.
If you use 31khz RGsB output from the PS2 (instead of component) the noise is gone.
but having had problems with tearing and stuttering in various emulators too
definitely a configuration problem.
Personally I was talking more about a tiny pitch shift due to the game running at a different speed, not something you'd really notice but a trade-off in accuracy, if you like.
with fixed frequency displays (60Hz on a PC LCD) I prefer the speedup (e.g. DoDonPachi from 57 to 60Hz) to anything else. This is where you can start to hear the differences, but on the GBA it's really something like 59.89 to 59.94Hz.
ZellSF wrote:I forgot to mention: if you're worried about sound quality (minor pitch change), I think the GBA player has to resample too? I think the GBA uses some weird 32khz-ish sample rate and unless the GC supports that... you're not getting that authentic GBA sound anyway.
Gamecube (and Wii) supports 32kHz and 48kHz. So no resampling is necessary on the gamecube side.
but having had problems with tearing and stuttering in various emulators too
definitely a configuration problem.
That's always fun with PC emulators. There are some emulators I can spend hours trying to get to work right. VBA-M is one of the more user friendly ones.
If you use 31khz RGsB output from the PS2 (instead of component) the noise is gone.
Rather complicated to get that to work though, I believe you'd need PS2 -> Sync stripper -> Extron RGB for it to work in RGB all the time in all screen modes, at least in my setup.
I couldn't find one C64 emulator that didn't stutter (at 50hz, with PC monitor set to 50hz), in the end I just gave up and bought a C64 and a 1541 Ultimate.
with fixed frequency displays (60Hz on a PC LCD) I prefer the speedup (e.g. DoDonPachi from 57 to 60Hz) to anything else.
Would that be "Sync to monitor refresh" in Mame then?
These kinds of timing issues are likely to effect the RetroN too of course, and will be interesting to see how they deal with them.
Rather complicated to get that to work though, I believe you'd need PS2 -> Sync stripper -> Extron RGB for it to work in RGB all the time in all screen modes, at least in my setup.
probably, yes.
Would that be "Sync to monitor refresh" in Mame then?
yes, but the function is broken in several MAME versions. We had quite a few topics about this here on the board already.
Makes you wonder where they go from here. I imagine in a few years (when patents/copyrights expire/pin connectors become available) they can add even more systems like N64, TG-16, Atari 2600/7800, Game Gear, Neo Geo and maybe Intellivision/Colecovision and other Atari consoles (For Master System you just use a Power Base Converter, the Genesis/Mega Drive slot could also take 32X games and you could play Neo Geo Pocket games through an adapter to the Neo Geo slot). But that's assuming they get compatibility and image quality right.
If you use 31khz RGsB output from the PS2 (instead of component) the noise is gone.
Rather complicated to get that to work though, I believe you'd need PS2 -> Sync stripper -> Extron RGB for it to work in RGB all the time in all screen modes, at least in my setup.
I'm not sure if I follow. Set your PS2 to RGB mode, then get the ultimarc PS2 cable which outputs in a dsub15 pin (vga port), plug that into a Dsub15 to BNC cable, plug that into a extron 210 which converts the sync to RGBs or whatever you like and plug that into your CRT or line doubler or whatever.
If you start off with the Xploder HDTV player (or mod your PS2 to output in RGB 31hz all the time), then you can ditch the line doubler all together.
