I'm asking because some guys in the GC forums are trying again to prolong load times of Matroid Prime to make it more like it is on console.
Imo that is insane. My argument from that thread:
We are TASvideos. We play on emulators. Everyone knows it and if not, they should.
Why would we prolong loadtimes? They don't show gameplay. TASes can't be compared to console runs anyway.
What happened to aiming for fastest time? Is it now "prolonging the game artificially, to more closely mirror restrictions of optical media, that any game designer would kill to get rid off"?
Derakon wrote:
You extend load times to make things more directly comparable to realtime speedruns. Because like it or not, people compare TASes to them all the time. And you want the time difference to be down to the difference between skillful human play and inhuman play, not down to inaccuracies in emulation.
Then these people have to compensate for the load times while timing. We also have to do that with version differences. See the OoT TAS.
You will never be able to emulate the load times correctly. So you'll alsay have to adjust timing by hand anyway.
I would prefer as accurate of an emulation as possible, regardless of what is being emulated (load times included). Of course we will never have Dolphin be like the GC, but 95% is good enough. The same goes for PSX, PS2, etc. Besides, with increased performance of emulators over consoles, it causes different TAS possibilities and routes. May I reference MegaManX2? There is a time saving glitch in Crystal Snail's stage that can't be done on emulator because it requires lag frames (which only console produces in that area).
"Here at TASVideos, we strive to push games to their limits. The emulators we use allow for undoing mistakes, slow-motion gameplay, and even in some cases utilizing robots to do our bidding.
Using these tools, we overcome human limitations to complete games with extremely high precision, entertaining our viewers as our players tear through games at seemingly impossible speeds. The end result of this process is simply a series of key-presses which can be performed on the original hardware."
From the TASVideos about page. The entire point of this website was to show how games can be played if human reflexes and mistakes were not a factor, not how games can be played if things that are part of the game are removed (through inaccurate emulation).
Joined: 5/13/2009
Posts: 700
Location: suffern, ny
But the game must start Form power on, As if one were starting a game. I think that they should, so it would feel as if they just turned on a system. Does the same thing happen for the playstation?
[19:16] <scrimpy> silly portuguese
[19:16] <scrimpy> it's like spanish, only less cool
But the game must start Form power on, As if one were starting a game. I think that they should, so it would feel as if they just turned on a system. Does the same thing happen for the playstation?
yes, load times are emulated in PSXjin/pcsx-rr.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Well, if it's an emulation problem, then it probably should be fixed. We can't exploit Dolphin's inaccurate timing and call that the fastest time.
What if a GCBot was ever made? All the runs that use the inaccurate timing would never sync on console.
"Here at TASVideos, we strive to push games to their limits. The emulators we use allow for undoing mistakes, slow-motion gameplay, and even in some cases utilizing robots to do our bidding.
Using these tools, we overcome human limitations to complete games with extremely high precision, entertaining our viewers as our players tear through games at seemingly impossible speeds. The end result of this process is simply a series of key-presses which can be performed on the original hardware."
From the TASVideos about page. The entire point of this website was to show how games can be played if human reflexes and mistakes were not a factor, not how games can be played if things that are part of the game are removed (through inaccurate emulation).
Alright, I'll try to reword that better.
<klmz> it reminds me of that people used to keep quoting adelikat's IRC statements in the old good days
<adelikat> no doubt
<adelikat> klmz, they still do
"Here at TASVideos, we strive to push games to their limits. The emulators we use allow for undoing mistakes, slow-motion gameplay, and even in some cases utilizing robots to do our bidding.
Using these tools, we overcome human limitations to complete games with extremely high precision, entertaining our viewers as our players tear through games at seemingly impossible speeds. The end result of this process is simply a series of key-presses which can be performed on the original hardware."
From the TASVideos about page. The entire point of this website was to show how games can be played if human reflexes and mistakes were not a factor, not how games can be played if things that are part of the game are removed (through inaccurate emulation).
Alright, I'll try to reword that better.
Uh, that was reworded after NESbot was created. It has been demonstrated that these files can play back on original hardware.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
May I reference MegaManX2? There is a time saving glitch in Crystal Snail's stage that can't be done on emulator because it requires lag frames (which only console produces in that area).
Actually, it can. I've done said glitch in snes9x 1.52, as it is more accurate than 1.43/1.51.
Joined: 4/21/2004
Posts: 3517
Location: Stockholm, Sweden
A dumb question, isn't an emulator doing it more "right" by not emulating waiting periods? Because the waiting periods is a result of a disc reading the next area. Isn't an emulator a better option in such case because we aren't using a disc, but rather an .img or .iso and therefore don't have waiting periods? All in all, I too want an emulator to emulate the waiting periods but I still would like to get an answer for my question.
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
Isn't Metroid Prime a special case anyway? As long as the next room hasn't loaded completely, the door won't open, so you'd have to wait, but you could f.e. charge up your Speed Ball while it's still loading. If you eliminated load times, it would thus change the gameplay into something slightly different, so for me it's pretty clear that they should be emulated correctly for that game at least.
We are TASvideos. We play on emulators. Everyone knows it and if not, they should.
Why would we prolong loadtimes? They don't show gameplay. TASes can't be compared to console runs anyway.
What happened to aiming for fastest time? Is it now "prolonging the game artificially, to more closely mirror restrictions of optical media, that any game designer would kill to get rid off"?
You do realize that that same argument could be used to speed up the emulation and make the emulated machine run much faster than the original console? Without limit (except for the capacity of the hosting computer to run the emulation).
In the same vein: Why should lag frames be emulated, given that an emulator can skip them?
(This is not an opinion on whether CD loading times should be accurately emulated or not. It's an objection to the argument.)
I think the idea is simple. We want to move away from the idea that TASing is cheating, and since it is now possible to playback input files on a real console, we should strive for emulator accuracy as much as possible, else it can be seen as cheating by having the emulator run much faster than the actual console could allow. This is why all the runs on faster snes9x versions, for example, should be obsoleted by runs on more accurate emulators in the future, even if they are slower in terms of real time.
Btw, can CD loading times be ever perfectly emulated?
It's certainly not enough to have a "this much data takes this much time to load". With a physical CD there are several other things that would have to be taken into account for a perfect emulation. There's seeking time (which means that there will be a pause before loading data can commence, and the length of this pause depends on where the head is currently, and whether the CD drive or the CD driver uses some kind of caching scheme). This not to talk that if the system stops the CD after a certain time of inactivity, it will take a (relatively) long time before it spins to full speed again (and this is quite a non-deterministic amount of time, when we are talking about frame-perfect emulation).
(It becomes even more complicated if the CD indeed stops spinning after a certain amount of time, because this stopping is not immediate either. If data is read while the CD is slowing down, it will be accelerated again to full speed from that. Emulating this accurately can be a nightmare.)
Btw, can CD loading times be ever perfectly emulated?
I would say no, already because emulating that would lead to "multiple oscillators problem", which already renders perfectly accurate emulation impossible.
Worse yet, the second "oscillator" in this case is a motor, which are not exactly accurate with rotation speed.
Sure you could probably get it near correct (and some games may even rely on loading times being there).
The "multiple oscillators problem" is as follows:
If there is only single oscillator in synchronous digital system. Then it is possible to compute future states of the system from the current state and logic-level description of the system.
The oscillator may jitter, but speed of everything else will jitter with it, canceling out the effects of jitter to system state.
If there are OTOH multiple oscillators, those oscillators can jitter with respect to one another, and these may have effects that don't cancel out.
You can't simulate the jitter because jitter depends on all sorts of factors that aren't known (like noise from the power supply).
You cant emulate cd scratch, those can alter the speed of loading, as well as reader errors correction or motor spinup time, basicly it mean its impossible to sync-bot anything that use a optical drive.
You can only make a theoric speed emulation, and youll never reproduce it 100% accuratly on the real hardware.
Btw, can CD loading times be ever perfectly emulated?
Probably not, because they're not fully deterministic: small variations in kinetics of disc rotation and optics of pitch scanning will happen and affect load times on the scale of frames (so syncing disc-based runs on an actual hardware will most definitely be impossible), and an imperfect condition of a disc will exacerbate the problem much further. Thankfully, cartridges are virtually free of it, having no moving parts.
That being said, we shouldn't rely on emulator inaccuracies for speed advantage. If the exact conditions cannot be simulated perfectly, we ought to find a suitable approximation to the best of our abilities, like it is done with every other rerecording emulator.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
If the exact conditions cannot be simulated perfectly, we ought to find a suitable approximation to the best of our abilities, like it is done with every other rerecording emulator.
Yes, but even that can be problematic. Due to the mentioned physical properties of a CD drive, it becomes quite highly a question of definition and even opinion what constitutes "a suitable approximation". How well should seeking times be emulated? Does the CD drive on the PlayStation stop spinning after a certain time of inactivity? If yes, should that be emulated? (And if yes, how far should this emulation go? As said, if the CD is currently slowing down but not yet completely stopped, and new data is read, how well should the speeding up be emulated based on physical CD drive characteristics?)
Well, if the goal is getting the experience more accurate to the actual hardware, I would postulate it as "going with the average durations achieved on actual hardware in perfect or near-perfect conditions" (unworn drives, mint discs). This would of course involve gathering some statistics first, but many emulator developers have (or able to gain) access to that kind of statistics, so it's likely not implausible as a long-term goal.
It's more likely that nobody gets around to it, though.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Using average loading times could even be more favourable than a totally accurate emulation. After all, I think we'd want to prevent situations where you could use a slower strategy in a certain room, but significantly speed up loading times for the next room by doing that *. Or use tricks to keep the disc spinning before it actually starts loading the next room, so you'd save time because the motor wouldn't have to go through the acceleration process anymore. I don't think I'd like to see the application of such strategies.
Average loading times under optimal conditions seems like the best solution to me.
*) Of course even going for average times won't totally prevent such situations from arising, but I guess it would at least keep them to a minimum.
Joined: 4/21/2004
Posts: 3517
Location: Stockholm, Sweden
That being said, again, if anyone is willing to help the developers to time the waiting periods for metroid prime and whatnot, please do so so we can get the ball rollin'!
Nitrogenesis wrote:
Guys I come from the DidyKnogRacist communite, and you are all wrong, tihs is the run of the mileniun and everyone who says otherwise dosnt know any bater! I found this run vary ease to masturbate too!!!! Don't fuck with me, I know this game so that mean I'm always right!StupedfackincommunityTASVideoz!!!!!!
Arc wrote:
I enjoyed this movie in which hands firmly gripping a shaft lead to balls deep in multiple holes.
natt wrote:
I don't want to get involved in this discussion, but as a point of fact C# is literally the first goddamn thing on that fucking page you linked did you even fucking read it
Cooljay wrote:
Mayor Haggar and Cody are such nice people for the community. Metro City's hospitals reached an all time new record of incoming patients due to their great efforts :P
I didn't mean it in that way. I meant to use average times for certain instructions, for searching and loading data, etc. (some emulators I've been looking at seemed to be doing something like that), not to time average loading times on a game-by-game basis. I don't think that'd be feasible at all.
If you mean we should log the loading times anyway for them to have something to compare to, then I think that might be a good idea. I own a quite scratchy PAL version of the game and a GameCube from the RE4 era.
I'm not sure old hardware is relevant for these tests. Times shouldn't be average between straight-from-factory hardware and kill-me-I'm-in-agony hardware, they should be average between hardware functioning to the 100% of its practical capability. Emulators aren't supposed to take physical wear into account.
In any case there should be a strict methodology for testing, and it might require additional hardware (because honestly, good luck timing anything on the order of milliseconds with a stopwatch).
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
I'm spectacularly amazed we're having an argument about disk based systems's loading times when it's basically impossible to emulate certain things such as a CD drive's motors speed (for the laser).
I know for a fact, for example, that many Sega CD drives had differences in loading times simply because of how slow or fast the motor powering the mechanics to move the laser varies in power (and the condition only gets worse with age and especially burned disks).
I dare be not at all surprised if basically all later disk based consoles suffered the same problem. Only thing that'd come to mind that'd have stable loading times would be somehow loading the game from a ROM or RAM into the console anyway.
