Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
moozooh wrote:
If there were different revisions of the Gamecube that had different hardware upon release, then the emulation should be adjustable to match all of the revisions, like it's done in, say, Amiga emulators.
Yeah, but then that'd open an entire bag of worms.
For example, the Mega Drive has a whole shitload of revisions, excuse my French. That's only further exacerbated by the combination of CD drives and 32x expansions that can be connected.
Of course, Gens is so inaccurate anyway that it doesn't 'properly' represent any Mega Drive models anyway. :B
This hardware thing is just the same as Left+Right input. Some may quickly jump and yell 'THAT'S NOT POSSIBLE WITH AN ORIGINAL CONTROLLER". Well it becomes possible after months of use, after the dpad center digs a depression in the board. You'll get all 4 directions pressed at the same time but that's enough in most cases.
Are those defective controllers allowed in SDA? I don't think so.
Not exactly a good comparison. The controller is completely obvious if using Left + Right together for an advantage in certain games. There's no way to pass that off as anything but that. Yet faster loading could easily be passed off as a "fresh" last gen gamecube with a "fresh" disc.
Anyways, I know this isn't SDA. Being that Metroid Prime 1/2 runs will likely never sync up correctly due to hardware differences, I actually wouldn't mind seeing them ran with instant loading. It'd be something completely different than anything else that is out there for them. As long as the game is emulated properly enough that there isn't any emulator exclusive bugs, abuse or tricks.
If realistic loading times get included later in Dolphin, why not just have separate categories for the different runs that use instant-loading effects? There are tons of games with different branches as it is <_<.
Yes, loading times should be emulated correctly because for some games loading times have a direct influence on the gameplay, and because the whole porpuse of an emulator is to emulate the hardware correctly. Of course there are some limits to emulating them totally accurately. It's silly to account for room temperature, scratches on the games, etc. Imo, you should just take the average optimal loading times (not per game, but add up access time and average tranfer rate * amount of transferred data) and be satisfied with that.
moozooh wrote:
If a laser's resistance (wait, a laser's resistance? What exactly is resistance being measured on here?)
If you screw open your GameCube, there's a potentiometer on the opposite side of the laser adjusting its strength.
Wouldn't this be sufficient information to get the average loading times on an optimal system?
"Panasonic-developed CAV miniDVD-like 8 cm optical disc, 2.000 MB/s–3.125 MB/s transfer rate, 128 ms average access time, 1.5 GB capacity"
What's the problem? Wouldn't it be relatively easy to add 128ms for every access command and 1ms for every 2-3.2kb of transferred data? (and then maybe apply some slight tweaks if that doesn't yet produce the desired results)
Why not use this simple and practical solution? Am I missing something?
I think emulating loading times correctly is really important when it actually affects the way the game plays. (For a really obvious example, watch the Metroid Prime 3 (Wii) speedrun at SDA; the runner frequently uses an invincibility ability while waiting for doors to open so that he doesn't take damage from getting shot at during loading times. The point is that the loading time is gameplay time too. Likewise, slightly less obviously, loading times lead to frame rules in Metroid Prime games; eliminating frame rules obviously causes major differences to which routes are possible.
Basically, any game that allows gameplay during loading times is likely to be very affected by this. (Non-Metroid, non-CD-based example: fourth generation Pokémon games, on the DS, start loading an area as you cross the centre of the area before, in a similar way to the Prime games. Cross the load lines fast enough and the game's loading routines get confused, allowing you to go through an unloaded area out of bounds. This would be impossible with instant loading.)
Sure, it's annoying waiting for a door to open while things are shooting at you. But it's part of the game, and cutting it out on an emulator is much the same as using a cheat code to make doors open faster in a game where they're unrelated to loading.
I suspect an approximate solution will be accurate enough to make this work to within a frame or two, though, and within the range that actual consoles actually manage. So I like the average bandwidth/average latency suggestion above.
Also... I'm not a hardware modification (or laser for that matter) expert, but isn't it theoretically possible for someone to modify or swap their gamecube's laser to have a resistance of 2 or 1 ohm? I know there's a "no hardware modifications" policy at SDA, but what's stopping someone from changing that 66 ohm down to a 55 ohm? That person could blame their "fast" load times on someone else's just being "slow".
There is a potentiometer you can turn that changes the resistance of the laser, or rather the energy that is fed to the laser, which makes it stronger or weaker. (Sometimes it's kind of hard for me to express myself in english.)
Modders used to lower that resistance to get the cube to read burned discs that's how I know the value of my cube. I never had to change it, since I just used good media and a good burner, but I measured it non the less when I isntalled the modchip.
moozooh wrote:
Again, there is no original hardware for an emulator. There is emulated hardware. What you choose to emulate is as good as original for you.
Ok I choose not to emulate load times. Thus it's as good as original. Problem solved!
If a laser's resistance (wait, a laser's resistance? What exactly is resistance being measured on here?) deteriorates with time, as your data seems to suggest, then a model piece of hardware is obviously the one with no significant deterioration. Which means, as I already suggested, that durations should be measured on newest, least used models available, and averaged out. That way it will be closest to the model hardware's behavior. If there were different revisions of the Gamecube that had different hardware upon release, then the emulation should be adjustable to match all of the revisions, like it's done in, say, Amiga emulators.
It's the energy fed to the laser. I was a little bit unclear there. And no the resistance value stays the same over the gamecubes life. It doesn't deteriorates.
Gamecubes produced later will have a lower resistance. Nintendo probably thought those won't have to last as long thus they could just crank up the current. This will give them less warenty cases because of "disc read error"s. Once the laser fails the cbe will be out of arrenty anyway and nobody will play that thing anymore, so there won't be any outcry in the press. (well that's my speculation on that part, anyway)
It doesn't matter what people expect. At all.
Really?! I remember countless arguements that were based in "pople know the gams this way, so we should give them to them this way, damn it!!!!!!"
The games language comes to mind here.
What matters is getting it close to how the hardware is supposed to work when you unpack it in the store.
Yeah, except for the quadrillions time: There is no "supposed to" when it comes to loading times. There is an average, but no consant, so you can't emulate constants, like with the cycles on the SNES or something. It's just not possible.
You might as well use the Nintendo Kiosk System (or child hospital system) as reference, load the game from a harddrive with no loading times at all, except the initial ones.
That's also how it's "supposed to work".
God I wish I had had space for quotation marks in the thread title...
Hmmm. This brings up many interesting points.
It doesn't matter how the discs are emulated, most likely, since they will differ from the original anyway (as some has mentioned, there are different models with different lasers and so on).
Also, what is a potential runner acquired a SPECIFIC cube system just to take advantage of certain bugs? Why shouldn't emulation be able to do that?
So are we going to...
...choose a fixed speed (none/average), and ignore all possible improvements we might achieve due to the hardware differences?
...or allow some type of variable speed in order to maximize abusing the hardware?
Also, I do believe emulating is the same as mimicking the output of device that is being emulated as someone mentioned, and simulating is the same as mimicking some device's internal state.
Many emulators have had improvements over the original hardware in some way or form (texture packs for n64, for example), so it isn't "purely" mimicking the system. SNES emulators, I believe.
Ok I choose not to emulate load times. Thus it's as good as original. Problem solved!
Load times are not hardware. A laser, a motor, and a disc with data are hardware. When they interact you get load times. You're being lazy again.
Slowking wrote:
Gamecubes produced later will have a lower resistance.
There's no particular problem in having several sets of values corresponding to each hardware revision, since it makes perfect sense from the accuracy standpoint anyway. A TASer is then free to choose whatever value they like. Might as well go with the faster one, but hardcoding it from the start doesn't make sense, since it can break some games in ways that aren't quite appreciable to exploit TAS-wise (purposefully choosing a weaker set of hardware to execute the same code is poor sportsmanship).
Slowking wrote:
Really?! I remember countless arguements that were based in "pople know the gams this way, so we should give them to them this way, damn it!!!!!!"
I don't enjoy the way you tie together completely unrelated issues just because they're worded similarly. You still don't seem to understand what an emulator is, either. Most people don't like lag. But guess what, emulator developers don't artificially overclock an emulated system's CPU just to get rid of it. They also don't make it show colors it can't physically show, or make sounds it can't physically make. If it happens, it's an error that is subject to a fix, or an option that is made at the latest stages of development. Again, it doesn't matter if you or any other amount of people don't want lag or loading times or something else: if it's there on the hardware that is emulated, it will be emulated, by definition.
But anyway, the arguments you're referring to were also made in favor of accuracy, since "people know games this way" was about making a TAS look more authentic to the game in question (in other words, with better accuracy).
Slowking wrote:
Yeah, except for the quadrillions time: There is no "supposed to" when it comes to loading times. There is an average, but no consant, so you can't emulate constants, like with the cycles on the SNES or something. It's just not possible.
Please re-read what I said earlier, the bit about statistics and averages. It flew over your head completely as you were busy making your point. I'm done here.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
For TAS, load time should be emulated as accurately as possible.
Lack of accurate load time shouldnt stop TASer from TASing game although, but if the option is there, it should be used.
Bringing me to my last point, it should be (and most likely will/is already) an option, so people who just "play" the game can do so without/with faster load times.
Edit: I also think emulated load time should be low on the emu coder "TO DO" list, get pretty much everything else working accurately/properly before bothering with this. So, if I was a Dolphin coder right now, there would be a crap load of things I'd do before bothering with accurate load times.
For TAS, load time should be emulated as accurately as possible.
Define "as accurately as possible" ;)
One of the problems is that there is no standard load time as it varies between each system, and it is possible to tweak the load times of standard systems!
One of the problems is that there is no standard load time as it varies between each system
That's not a problem. Lots of things vary between systems, such as CPU speeds, amount and speed of RAM, and so on. Each emulator emulates each individual system independently. They don't share common "average" specs between emulated systems.
Even if the hardware (in this particular case the CD drive) varied on the same system (which I don't think is very common, as invariability of the hardware is one of the basic tenets of game consoles) that wouldn't still be the problem, as an emulator could easily emulate any of the possibilities that are/were available for the console in question.
The actual problem is that, unlike a game cartridge, the speed of a CD drive is effectively non-determistic from the point of view of the CPU (for instance, it's very easy for seek times to vary by many frames depending on a ton of things, most prominently the physical properties of the drive and the disk).
Even if the hardware (in this particular case the CD drive) varied on the same system (which I don't think is very common, as invariability of the hardware is one of the basic tenets of game consoles) that wouldn't still be the problem, as an emulator could easily emulate any of the possibilities that are/were available for the console in question.
Sure, that is one definition.
Just, Master of Puppets did specify any such definition. Just the vague term "emulate load times." The "load times" is so vague, it requires a more proper definition to emulate.
Joined: 5/13/2009
Posts: 700
Location: suffern, ny
I think we should for one reason, With load screens it will show an approximation how long the run is supposed to be. For example, someone could do a run and say I saved over 10 minutes over the SDA run of the same game. But out of that 10 mintues, how many were inaccurate loading times? and how many were actual game play? IF you watch the current Metroid Prime run, all the loading times are skipped. It just looks like he skips to locations, and important information is missed. because of the games Cutscene like loading screens.
[19:16] <scrimpy> silly portuguese
[19:16] <scrimpy> it's like spanish, only less cool
IF you watch the current Metroid Prime run, all the loading times are skipped. It just looks like he skips to locations, and important information is missed. because of the games Cutscene like loading screens.
No, that's because he removed the item-get pauses and cutscenes from the encode. The loading times not being present just means that doors open immediately instead of sitting there closed for several seconds after you shoot them.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
@EEssentia: Actually I used "emulate load time" to simplify what I meant. It should emulate the hardware that cause load time, so in this case memory limitation (which is most likely already done) and optic drive, using an average or a range of delay/speed as posted by another user in this thread. If using a range rather then an average, it should done in a deterministic way, otherwise movie wont synch (unless movie file format get a huge makeover and stop basing themselve on frame)
Sure its not perfect, but much better then no load time at all for the sake of "accurate" emulation.
