Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Many adventure games broke up their data by location, and you'd have to swap floppies or CDs as you moved around. Most adventure games also require revisiting past areas with new items collected, so at least a few will require disk juggling.
How about this?
-User up front can specify all the disk images that might be used for each removable device.
-There are forward and back cycle buttons (hot keys) to loop through the list of disk images for each device.
-There's a button to replace the currently loaded disk image with the current selection from that device's cycle.
We'd want information somehow provided to the user regarding the disk cycling/replacing so they know what they're doing. But at the same time, I don't think we want the cycling itself to show up in encodes. We probably do want information like "Disk in drive B: replaced with disk image 4" to show up in encodes.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Being able to swap between 10 CDs with hot keys should cover almost everything.
The titles that use more I'm not even sure are suitable for publication on TASVideos, so it might be moot.
Floppy disks on the other hand can be an issue. Some games went absolutely nuts on floppy disks. I think most of those games eventually had a CD-based re-release, but for anything that didn't, 10 will not cut it.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
You could in theory add a CD drive for each CD and put one in each, and this technique is good up to 23 CDs (I think the largest game is 14 CDs or so).
However, I don't think DOS games are able to scan all CD drives for the appropriate files. They have one configured up front, and then keep checking that one.
If the game is able to pause and resume at the CD swap point, you can change the config or use the DOS assign command to swap a CD drive over. However, that's probably rare for most of those multi-CD games as well.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Sounds good.
Just want to check, PCem supports juggling CDs during play, right? Some late 90s games have 4+ CDs to them.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
The idea behind having 3 machines is mainly for convenience as slamo has said. For games where there is absolutely no information regarding requirements you really have to go based on when it was released.
Also even when we do have recommended requirements, PCem doesn't necessarily offer that exact setup. Sometimes the requirements will also not be all encompassing. Therefore having a preset goto system for the era is helpful.
As for the machines I suggested, I purposely suggested things which lean towards the high end of the era so they're capable of playing anything, but not so high end that it should seem ridiculous for most of the games of the era. If you have a different suggestion which you believe is better, we're certainly open to reviewing it.
Also at least for the 90s, the games at that point understood the existence of shifting clock speed and more powerful CPUs, and nearly all those games were designed to self-adjust to the speed of the computer. They should run well on a machine which wasn't top of the line when they came out, as well as machines that would be out a year or two later. Then the only real difference at that point is loading times, and for TASVideos purposes of judging this sort of thing, that's not actual gameplay.
Lastly, we also need to consider the needs of the judges and encoders. Having players just choose any machine randomly is going to make a judge's life miserable, as they'll need to put in a lot of work to get the same setup and get things to sync. Accepting a drive image from a player is problematic, because they could hide something in there which affects game play, and it will be difficult for a judge to be aware of it. Using a preset machine helps keep things simpler and verifiable.
We want to keep things as consistent as possible where players of a particular game use the same setup each time, not constantly changing it between each run. We could have a discussion before each first run of a game is made and if someone suggests a more suited machine, our judges can put something together to ensure it is done without any underhanded activity, and provide a consistent setup. But this could get cumbersome.
If you have better ideas how we could meet these goals, they are most welcome.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Agreed.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
slamo wrote:
Terminal Velocity: This one will probably end up getting TASed on the late 90s config, but it runs very nicely.
We should probably have some rules along the following lines:
Games released until 1989-12-31 should be played on 80s machine.
Games released from 1990-01-01 to 1994-12-31 should be played on early 90s machine.
Games released from 1995-01-01 to 1999-12-31 should be played on the late 90s machine.
If a game was originally released in one time frame, but is using official patches or secondary release from a later time frame, it can be played on machine in either time frame. However, if the patch or secondary release requires features of the later time frame, then obviously it should be played in the later one.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
One important factor for 90s DOS software is the VESA BIOS extensions. It'd be nice if we had good video cards which supported VBE 2 and 3 because those added support for higher resolutions and greater bit depths which some games might be able to make use of.
However, a lot of that can be added via software if necessary, and we should bundle it if PCem doesn't supply us video cards with those extensions.
Incomplete list of video cards supporting these extensions: https://web.archive.org/web/20090112210259/http://www.xerxys.info/index.php?title=VESA
SciTech released their UniVBE/Display Doctor which added modes via software, worked great on various S3 Trio chipsets, and eventually became freeware. It can be found on ftp://cyberia.dnsalias.com/pub/filebase/freedos/FILES.HTM along with some other DOS utilities.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Other suggestions:
Early 90s:
Packard Bell PB570 (Hillary)
Pentium 133
8 MB RAM
Sound Blaster 16
Built in GD-5430
I think this is a reasonable spec for that time frame, and it should cover pretty much everything of that period. Only question is the video card, I think it's sufficient. What do you guys think?
Late 90s:
Gigabyte GA-686BX
Pentium II 450
32MB RAM
Sound Blaster 16
Phoenix S3 Trio64
3DFX Voodoo 2
For late 90s, I would even go Pentium III, but it doesn't seem we have anything beyond a Pentium II in PCem. Cyrix had some good processors back then, but you'd run into the odd compatibility issue. Sound Blaster 16 still seems to be the most compatible option that doesn't require external firmware. For 2D video, the S3 Trio was by far the most popular series, this card seems to be the best of the bunch available. Going for separate 2D and 3D instead of one of the combined because the early 3DFX combined 2D/3D cards were known to have some 2D visual quality issues. There's combined S3 ViRGE based video cards, but then it won't be able to accelerate games designed specifically for 3DFX cards. The Voodoo 2 is the best one PCem has.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Since we're having some issues with my previous suggestion, how about the:
Compaq Deskpro 386
386DX at 20 MHz
4MB RAM
It supports ISA, so we can use it with IBM VGA and a Sound Blaster Pro. The SB Pro is backwards compatible with the original SB and Adlib, so it should give us sound in practically every 80s game.
Edit:
Added RAM amount.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
To get the ball rolling, how about the
IBM PS/2 Model 70
386DX at 25 MHz
Built-in VGA
As a machine for late 80s games? It should play everything reasonably well. We can consider that many games of that era for designed for that machine or a similar machine.
Some games back then had early sound systems like Adlib. Can we put any sound card into such a machine in PCem? Or are we limited to a certain subset?
I think for that era, a 3x86 is ideal, because it's 16-bit, so it gives us access to all that software, while at the same time, isn't so new and fast that it's heavily divorced from the software of the era.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
ThunderAxe31 wrote:
We already allow any different revision of the same game, especially when one revision has specific bugs that allow to beat the game faster. We also already allow different hardware revisions, for example the different PSX BIOS versions, for which in some aspects may feature even deeper differences than GB vs GBC. You insist that GB games haven't been designed for the GBC platform, but that also applies for any other platform game that was developed before introducing hardware revisions. Is there any reason why we should treat the Game Boy differently?
This is actually a good point, which I accept. I have also mentioned a similar case made recently that such later console changes should also be disallowed. In such a scenario only BIOS versions made prior to the game should be allowed.
However seeing as we've long had the PSX BIOS version rules in place that only the region has to match, and it's an easy to go along with rule, I don't suggest we change it, or disallow later versions of the same console in the same region. However as we are rethinking this, versions earlier to the game should probably be the preferred version, especially if you want to claim accuracy. But we can accept it either way.
feos wrote:
Subjectivity. If I'm familiar with situations that are covered by our movie rules, and I stop considering some of them valid and acceptable, then the rule itself is not legitimate anymore?
I think you're looking at this backwards. You come across a scenario which aren't covered by our movie rules, or the movie rules weren't exactly intended for. In which case you need some updated rules. We shouldn't just be going blindly with an old rule when it was made with incomplete knowledge. When we get new knowledge, we can adapt as appropriate.
feos wrote:
So in any encode of GB Zelda, you will see the same flickering when watching on your computer, regardless of the mode.
That actually depends on what kind of screen you have and if you have any sort of video filtering going on. My friend also informed me of several other games that have similar issues, and the worst one of them all is ZAS. That game is practically seizure-inducing if played on anything other than an original DMG, poor quality ghosting screen, or using some sort of frame blending.
feos wrote:
How many people you want to come in and say "I'm fine with all those subtle differences" to finally understand that information you bring up is not being missed?
I don't believe that's the case, because they weren't aware of it prior to me mentioning it, and they made believe it didn't exist after I mentioned it. I cannot see into people's minds, but it seems to me people are saying they're fine because they don't want to acknowledge that there might be issues, and they are not fully aware of the problems, and instead chose to attack me.
adelikat wrote:
I find this and most of your posts in this thread to demonstrate terrible leadership.
Having a conversation is terrible leadership? I'd rather have a conversation than just doing something. You'd rather have no conversation at all?
adelikat wrote:
I trust senior judges to make these kinds of rule changes. They are the ones dealing with submissions every day and are paying the most attention, and dealing with our audience and contributors. Our senior judges are in a better position to make decisions than either you or I.
We've already decided in the past that administrators should be involved in rule changes. If you want to change your mind, fine.
adelikat wrote:
You admit you haven't been paying attention. A good leader in that position gives their staff the benefit of the doubt. However, you've come in with the assumption that things were done wrong because a decision you don't agree with happened.
I admit I haven't noticed this particular issue. I'm sure there's things that happened that you also haven't noticed. I came in with an assumption because over the past ~3 years, every time there was a rule that needed changing, the judges asked my opinion. I'm surprised there was a case that for some reason they didn't. If they never asked me my opinion, then I wouldn't be surprised, but this case for some reason did not follow other recent rule changes.
Mothrayas wrote:
For reference, all submissions and publications of GB movies that had their system labeled as GBC have now been set back to GB. This fixes the issue where GB-in-GBC movies couldn't be found in the GB movie listing as they were supposed to be.
Thank you, that was my main issue.
feos wrote:
Do these look good?
Yes.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Spikestuff wrote:
I'm not bringing anything to the table, but when there's a large significant agreeance with majority of Staff about this and one is making it difficult especially something that's been unofficially been in place for 2 years now you should get the realization why Staff won't ever agree with your stance Nach.
For me it hasn't been 2 years. Just 2 weeks.
Spikestuff wrote:
It's because Staff want to evolve whilst you don't.
Why are you assuming that?
I don't know what everyone knows and doesn't know on the topic. Most of the push back I've been getting on this thread appears to be about not understanding the situation. Why should I accept a differing viewpoint when I know the other viewpoint is missing information which I have?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Mothrayas wrote:
I was senior judge at the time, and senior judge had the final call on movie rules.
Senior judge has final call on interpreting the movie rules. Admin(s) are supposed to be involved when it comes to rule changes.
Mothrayas wrote:
Each of these rule changes were discussed in the staff IRC channel at their respective dates. Especially the overall GB rule update (from 2018-01-01) had adelikat as an active contributor to the discussion (alongside other judging staff).
According to my logs, I was not on IRC for the weekend prior to the New Year, so that explains why I wasn't there for what I assume was an important part of the conversation.
Now that I look there though I do some conversation around that time for which I was there about some SGB run in the queue (Rolan's Curse II), and whether we should accept, but nothing that I see regarding the larger discussion.
Mothrayas wrote:
You may not recall it as you in particular weren't (actively) involved in either, but that doesn't mean that no discussion happened between judges and admins in the proper channels, or that the rules were "being modified unilaterally" by "judges". The logs are right there. (For as good as IRC is at keeping them).
Okay you're right, just because I didn't see it and was not aware of it, doesn't mean it didn't happen.
In general though, important rule changes should try to involve as much of the senior staff as possible, and staff should try to be in the staff IRC channel as often as they can.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
I'm going to need your exhaustive definition of the word "legitimate", because it's becoming impossible to discuss anything without having the same questions asked over and over.
Everyone familiar with the situation finds it acceptable and valid way to play and consider it to be a reliable method for TASing purposes.
feos wrote:
VC is quite clearly unique compared to all those bundles. Limiting a unique rule to the unique situation means you don't need to extrapolate anymore (hooray).
As you know, we often clarify how to handle new situations on the basis of how we handled previous situations. So how would you define our allowance of VC in such a way that it doesn't open the door to anything that may come along later?
feos wrote:
Nach wrote:
feos wrote:
If the game is separated from that layer, even if it loses those enhancements or tweaks, it's fine.
I find this debatable.
You disagree with your own ruling?
I can argue either side and believe each has merits. We can have a long discussion about pros and cons.
Nach wrote:
Except none of that helps with prejudice/inconsistency towards the platform itself.
That's because the platform itself is inconsistent.
Nach wrote:
VC games were explicitly re-released with this extra layer, I don't see any difference between them and non-VC games officially released for Wii. The point about AV bugs was about GB games that weren't explicitly re-released for newer modes, instead the console itself was tweaked to support them.
Not all DMG games with issues got a black cartridge re-release for CGB. Also for some reason, some of these games only got a re-release in one region but not others, such as the game Alyosha referred to earlier.
It's not fully clear what criteria they used for the re-releases. Nearly every re-release is known to have its original version exhibiting some kind of problem, so that was certainly motivation for it, but not every problematic game or game/region got that treatment.
Later console changes didn't fix all the problematic games either.
You want to block DMG games on CGB when there's some noticeable issues, which I agree with. It's a combination Nintendo wants to support, but their success rate was not perfect. Same for VC, they want to support all these games they're bringing over, but their primary focus here is the $, not whether the game runs perfectly well or not. They're not extensively testing them like they would a brand new game. If there's AV issues in VC that aren't exhibited on the original platform, why should we support it?
TiKevin83 wrote:
Nach:
"I do have a problem where we say, nope it's perfect, because we compared it to something which is another emulator."
Ok so for VC and the like, this is a reasonable criticism assuming you allow no nuance with things like additional content exclusive to the VC release or VC exclusive bugs that are intentionally being TASed under the consideration of VC as the base platform. I think there's room for those nuances though.
I think there's room for nuance where VC adds on content.
However if it's really just the original game, I don't see why we should allow for this nuance anymore than we'd allow for making use of bugs in MAME.
TiKevin83 wrote:
When referring to the GB/GBC/GBA situation, this would be a bit strange since the systems all have a nearly identical SOC for playing GB games, each revision has its own bugs, and they're all official hardware from Nintendo with no software emulation involved.
Whether it's software or hardware really isn't relevant.
TiKevin83 wrote:
Some cases where GB games don't run on GBC are as much caused by bugs in the original GB hardware that the game accidentally relied on as they are caused by new bugs in the GBC.
That is indeed true. I spoke to a friend of mine over the weekend who is more familiar with some of these differences, and he told me the flickering in DMG Zelda on a CGB I mentioned earlier is due to the fact the game was made understanding the ghosting effects of the poor quality screen the DMG has. The CGB having a better screen without these ghosting effects has a flicker in several places. SGB or emulators with older televisions or computer screens had ghosting effects and also looked great, but playing them on a new higher quality screen has flickering issues unless you turn on some kind of frame blending or motion blur. The Zelda DX version fixed this by redoing some of the visual effects the game uses, and when necessary, draws these effects on more frames so it doesn't require the screen to exhibit ghosting issues to look right.
Although this differs to the situation when we talk about the randomness being different, and thus the enemies act differently, or somehow instantly kill you and become unbeatable. The game was made with a particular design in mind, and was tested that way.
TiKevin83 wrote:
It's at the very least pedantic to consider the exact set of bugs present on the DMG to be the only legitimate TASing platform for games that were designed for it. It would be much more straightforward to only worry exactly which of these micro-revisions the game is being TASed on in the niche cases where it actually causes an incompatibility.
Those DMG games that may have relied on some DMG bug did not envision that someday a new system would come out which was intended to be backwards compatible, but would fix the bug and thus break the game.
I find it more straight forward to just play each game on the platform it was designed for. If a game was designed for multiple platforms, then allow it on any of those. We then don't have to start worrying about whether something unusual is due to an incompatibility or not.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
CasualPokePlayer wrote:
Can I ask if playing a CGB game on the GBA game counts as "pseudo-emulation" and should that be disallowed for nearly all cases? For nearly all CGB enhanced games, there isn't any enhancements for the GBA, so by this logic nearly all CGB games should not be allowed to use GBA mode for the sake of console verification.
I'd agree with that. I believe the earlier thread I linked also talks about CGB issues on AGB as well.
CasualPokePlayer wrote:
Also "pseudo-emulation" would really be closer to something like the Analogue Pocket, claiming the CGB has "pseudo-emulation" of the DMG is really like saying the SGB has "pseudo-emulation" of the DMG, or maybe saying the DS has "pseudo-emulation" of the GBA, or maybe even the Wii having "pseudo-emulation" of the Gamecube.
I mentioned earlier that a colleague of mine considers later SNES consoles to be pseudo-emulation of earlier SNES consoles.
feos wrote:
Why exactly are you not arguing for absolute purism regarding emulator accuracy though? If an enemy behaves differently, then you're not verifying how it works on console, so it's not the same game anymore. Consistency please.
I have no problem where we say look we're using an emulator, it may have some differences from the original, but we try to avoid that.
I do have a problem where we say, nope it's perfect, because we compared it to something which is another emulator.
feos wrote:
What is being verified is how a game runs in GBC and then on console. If the differences between GB and GBC for a given game are subtle, then running it on actual GB would still fundamentally work after some resync. If the difference is significant, we prefer the original thing of course.
It may or may not work on the original. It's really hard to know how big the difference is until you check.
feos wrote:
Nach wrote:
From my perspective, you have all absolutely lost your minds.
I won't tell you what people think about your posts from their perspective.
You don't need to, I'm sure those of you living in reverse-world are thinking the same of me. That's how perspective work.
feos wrote:
You ask the author to prove that whatever looks suspicious is also there in the original mode. If it's not there, and the difference is significant, reject.
I agree with this. However, not all our judges are necessarily familiar with the game in the original mode to know if something even looks suspicious or not.
feos wrote:
Nach wrote:
If you're copying a single value describing something it should be legal.
Which value do we need here?
I have to double check my notes, I believe there's a value or set of values in DMG/SGB/CGB headers which describe the capabilities of the cartridge. I can look that up for you. That information should probably be copied to the movie file, along with information regarding which mode or capabilities were used to play it back. This way we can both identify the system and know how to run it.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
That's what I mean as well. Though logically, if you get nearly identical runs from different game versions, then you can consider the versions nearly identical. We already do this with game versions that result in nearly identical runs. Just in this case, they would complete across platforms.
This is now taking my statement out of the original context. If you now deem the later emulated release as valid, you open it up to bugs and other kinds of new releases. The new releases we're talking about here isn't just the game, but all sorts of software added to the game. The point I was making is that we either have the exact same game (use the original), or it's not the same (is it then legitimate?).
When we came up with the concept of using the correct version, we were talking about remakes of NES games on the SNES or AGB, or arcade ports to consoles. Those were games natively copied to the other platform with some changes to better fit the other platform, and sometimes new additions in the later release.
With VC and other kind of emulation we're now talking about the original release - the same game, no changes or additions, just presented with a new potentially buggy shell. I'm not sure the same rules should apply.
feos wrote:
If other publishers release their IP bundled with emulators they haven't created or contributed to, we don't need to support those "releases".
Why not? If a company legally releases their IP bundled with an emulator, why shouldn't we support the release? What difference does it make their level of involvement?
feos wrote:
That means you consider VC illegitimate altogether.
Only if the game is (nearly) identical to the original or can otherwise be played fine on the original.
feos wrote:
It has an emulation layer of some sort, which is perfectly fine. That layer may enhance or otherwise tweak the games, also fine.
Agreed.
feos wrote:
If the game is separated from that layer, even if it loses those enhancements or tweaks, it's fine.
If you ban abusing emulator bugs in VC only in some situations, then you're allowing them in others. In which case you're not being consistent.
My criteria is simple:
Is it the original game (can easily be verified by comparison of the files) - play on original.
Is it close to the original game which also works on the original console (differences might be a harder gameplay mode or something, can check to see if it works on original) - play on original.
Game has enhanced features only present on VC - play on VC.
If it's the original game, but VC still somehow enhances it on the VC - play on either.
Close to original game, works on original console, and VC enhances it - play on VC.
feos wrote:
And from what I've been saying so far, arbitrarily so, because you decide for the company who owns the IP for all those games as well as the console, that it's not official enough for us to bother approving of whatever they release for it.
I don't think we need to consider every kind of release and combination legitimate or the correct version to play. You yourself agreed which should disregard potential use cases if it causes A/V bugs.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
Nach wrote:
Again, you're missing the point. I don't know how many ways I can explain this. There is a subtle difference causing the obvious problem here. This subtle difference will exist in many games, even when it's not obvious.
How many times do I need to reply to this?
I keep seeing replies that appear to be missing the point I'm making.
feos wrote:
If subtle differences don't cause problems in gameplay, audio, or graphics, then it's essentially the same superplay as on the original system, barring differences in randomness, which we've had zero problems with in our emulators.
Just because you don't easily see the issue doesn't mean it's essentially the same. If enemy patterns change, then you're not playing exactly the same game.
I wouldn't say we've had zero problems in our emulators, from working on emulators I know we've had emulators where the enemy in the game acts differently than on an actual console.
feos wrote:
Yes, emulators also have subtle differences compared to actual consoles. Yes, it can affect randomness and other things that may not be obvious. And we only really ban bugs in emulators that aren't present on actual hardware if the emulator bug abuse is the only way to pull off some trick, fundamentally. If it can be easily resynced to work on console, it's not an emulator bug worth rejection, just slight inaccuracy.
We agree on this point.
feos wrote:
So this is all in line with what we've been doing for years.
Except it isn't, because suddenly I'm hearing the DMG is being redefined as the CGB or AGB, and that verification on those later consoles is considered true verification. You're not longer comparing emulator with a console, but comparing an emulator with some other console which does pseudo-emulation. From my perspective, you have all absolutely lost your minds.
feos wrote:
Nach wrote:
How do you define normal gameplay?
The way it works in the original mode.
And how do you know that if you're verifying it against a non-original mode?
feos wrote:
With how I worded the rule suggestion, one doesn't have to verify things that aren't obvious glitches.
So now I see a run, and I suspect something, and it would force one to have to console verify it?
feos wrote:
feos wrote:
It'd be better if the file format would include some information copied from the game's header.
Is distributing parts of ROMs like that legal?
If you're copying a single value describing something it should be legal.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
Nach wrote:
Why are we publishing nearly identical runs for the same game twice?
If they're nearly identical, we can prefer some version we agree about.
I'm not talking about nearly identical game versions, I'm talking nearly identical runs. I don't need to see HappyLee's SMB in under 5 minutes published on every Nintendo console, with a frame added here or there to account for minute timing differences.
feos wrote:
Nach wrote:
If you're just looking to exploit bugs in the emulator, then what are you even doing?
Even you admit that VC is not simply emulation. It's some kind of a virtualization+expansion layer on top of the original games, tweaked or not, developed specifically for those games, packaged as an integral game image for Wii, and officially distributed by the copyright holder.
I admit that it's not always simple emulation. But in most cases, it is just simple emulation. I have no problem where the VC is doing more than simple emulation and somehow enhancing the game beyond what you'd get if you tried it on the original console.
feos wrote:
Nach wrote:
Then why not exploit bugs in any emulator? It's how people remember the game because more people have an emulator than the original.
VC releases have huge player base, it's how they remember those games that they have legally purchased from the creator of Wii and the copyright holder of those games.
In China, Snes9x/Mednafen/VBA/whatever have a huge player base. It's how they remember those games that they have legally purchased in China from the creator of the Chinese ARM-based console, and are considered the copyright holder of that creation in China.
As an aside, I'm pretty sure some of the early NES games have outsold themselves on the NES compared to whatever sales the VC is currently doing for them.
feos wrote:
Oh and I still see no "examples of actual problems with the future of tasvideos if we still allow people to TAS VC images as they are, without extrapolating this to anything less known and common, like bundles where we know an existing emulator has been included" in your replies.
See what I said about HappyLee's SMB.
And despite not having offhand examples, I don't find it legitimate to exploit bugs in the emulator if there is such a thing.
If you want to allow using emulator bugs for the VC, then why shouldn't we extrapolate it to other things? And don't start calling other things less known just because some of us may be unfamiliar with what is going on in other countries with billions of people.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
it's saying that the game "doesnt work on a GBC or up", does not work on a GBA, or "works maybe 1 out of 10 times".
Yes, exactly.
feos wrote:
Nach wrote:
Burai Fighter (the original monochrome one) doesn't work right on the GBA, and possibly the GBC. You die almost instantly as soon as the first boss appears.
Doesn't sound like obvious glitches in audio or graphics, does it?
No, it talks about the game not working, you die where you shouldn't be dying, and therefore you can't even complete the game.
Great. Now tell me why it's happening?
feos wrote:
If you can't play the game and complete it, it's not even remotely a "subtle difference we cannot easily see". It's an obvious problem.
Again, you're missing the point. I don't know how many ways I can explain this. There is a subtle difference causing the obvious problem here. This subtle difference will exist in many games, even when it's not obvious.
feos wrote:
It means the bug is getting in the way of normal gameplay in some way.
How do you define normal gameplay?
feos wrote:
Any bug in how a given mode replicates the other one
Terrific. Therefore you cannot consider "verification" made with only the new system to necessarily replicate the other one. You won't know if there's a bug or not until you do proper verification.
feos wrote:
Nach wrote:
Does the file format include what system the game is supposed to be for?
It has the ROM name that the author used, but it can vary, and one has to match the hash (also contained in the header) against some list of games, and determine the intended mode from that.
ROM image file name is meaningless.
It'd be better if the file format would include some information copied from the game's header.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
Well I get the impression that in your opinion, allowing people to TAS VC images as they are (even if the extracted game works properly) is absolutely fundamentally completely unacceptable and no one is allowed to ever question this
Why not just TAS the game on the original system?
Why are we publishing nearly identical runs for the same game twice?
If you're just looking to exploit bugs in the emulator, then what are you even doing? Then why not exploit bugs in any emulator? It's how people remember the game because more people have an emulator than the original.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Alyosha wrote:
I think it's also worth pointing out here that over the past couple of years, several of the examples of running GB games in GBC mode and making TASes of them, with the goal of console verification, has directly lead to significant advancement in emulation accuracy.
How do you know it's making it more accurate? Maybe it's making that particular mode more accurate, but it's not accurate to the original? Unless you're verifying it on an original DMG-01, I don't know on what grounds you can assume it's more accurate.
feos wrote:
I finally read the linked thread about problems in GBx games in later modes. They don't seem to even discuss all those "subtledifferences" only old DMG experts can spot. They talk about games that either don't run at all, or have obvious glitches in audio or graphics.
Have you been reading the same thread I have?
Sachen games are usually incompatible with anything newer than whatever was around when it was released. I have one of their mono 4 in 1s from the mid 90s which doesnt work on a GBC or up. And Beast Fighter, which is also a mono game - even though it was released in 2000 - does work on a GBC, but not a GBA.. unless you use a Game Genie, then it works maybe 1 out of 10 times. Sachen is weird.
Sounds like some randomness difference, which Alyosha mentioned earlier, so that's not obvious glitches in audio or graphics is it?
Burai Fighter (the original monochrome one) doesn't work right on the GBA, and possibly the GBC. You die almost instantly as soon as the first boss appears.
Doesn't sound like obvious glitches in audio or graphics, does it?
I don't know why, but for some reason most of the replies in this thread again and again keep missing the main point. It's not about the A/V issues, those we can easily see. It's the differences we cannot easily see. If reading back from the output is being used, or something that relies on specific timings or something else, the CGB will act different from the DMG. There's ample evidence of this, the cause behind this is known. I don't get why you keep ignoring this. From the two comments I just quoted, you see it goes deeper than just what is being output.
feos wrote:
Why are the rules being modified unilaterally? Judges are not supposed to modify the rules, only clarify them.
In the past 5 years, we've had many discussions between admins and judges regarding changes to the rules. We had various threads about them, discussion in the staff channel, some changes we announced publicly. We asked admins and judges if they like the new wording or not. I don't recall seeing any discussion about anything Mothrayas did here, at least not in the usual staff places. So I don't think anything about those rule changes are legitimate.
feos wrote:
People that support GB-in-GBC are those who currently contribute to GBx emulator coding, to GBx console verification, and to GBx TASing. If that doesn't make the demand legitimate, I don't know what does.
If they're using a CGB or AGB to benchmark what a DMG is supposed to be doing, then I don't see how it's even remotely legitimate.
feos wrote:
In addition to those, staff members also agreed (here and on discord) that unless there are obvious problems with newer modes, console verification is a good enough reason to allow those modes.
Why are important staff discussions taking place on Discord? When I said let's make the Discord channel official and put it on the site so anyone can find it, I also said it's not to be used for official business that requires our senior staff.
Regarding console verification, all I see is you verifying with some other platform, which is similar yes, but not the same. So I don't really see you verifying anything.
feos wrote:
Suggested rule.
[*]If glitches that are caused by newer mode hinder gameplay, we don't want that mode.
[*]If glitches that are caused by newer mode are obvious to unarmed eye/ear in normal viewing conditions, we don't want that mode.
Agreed.
feos wrote:
[*]If glitches that are caused by newer mode can't be easily noticed and don't hinder gameplay, the newer mode is allowed for the sake of console verification.
Disagree. What does hinder even mean?
feos wrote:
[*]If newer mode doesn't cause any glitches at all, it's allowed.
What's considered a glitch here? Although if we know some game in particular runs identically down to the last detail on either platform, then I would agree we can run it on either platform.
feos wrote:
Categorization seems to need that publications of DMG games are labeled as GB, but how do we automate that in the parser?
Does the file format include what system the game is supposed to be for?
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
We could also limit this to just VC, at least for now.
First of all, we can't even know if they used any of the emulators available on the internet, or made their own.
I've spoke to other emu authors about this. We don't think Nintendo used any of our emulators wholesale, although we do think they may have taken some bits and pieces here and there due to the occasional quirk that exactly matches a particular emulator. In the case of releases by other companies though, we know for a fact that a bunch of them are using our emulators, and often we even know exactly which version.
feos wrote:
Since randomly substituting games in the VC layer doesn't always result in a playable game, those could be either barebones emulators targeting only specific games, or not even emulators in the usual sense, but running some game programs on actual hardware. Nintendo said about VC SMB that “emulation program in question was created by Nintendo internally”, and I couldn't find evidence disproving that.
I imagine Nintendo has more of an emulator library that they made in general, and they compile it with whatever components they find is necessary for the game in question. Therefore it's a bit hit or miss whether some other game will work. In some cases, they also needed to make some minor tweaks to the game to get it to work. Those tweaks won't necessarily break the game on the original platform, but at the same time, other games would need similar tweaks to run on their emulator.
Based on my discussions with other emu authors, Nintendo has developed its own software internally for this purpose. If they took anything from us, it was something minor.
There can also be games that seem emulated, but it's more of a mix, as when the game reaches certain points, it knows to run some code (typically to play audio/video) for the primary system, not the emulated system. In these cases I would agree it's meant for the more modern system, and it's using some pseudo-emulation for only part of it.
feos wrote:
Second, I feel strongly against requiring people to fiddle with officially shipped game images. We've only ever allowed it in cases when the game would've been simply unTASable otherwise, and now outright require it unless the extracted image itself doesn't work?
Requiring people to fiddle is a broad concept. In some cases you just pop the medium the game came on into your computer, and copy some files. In some cases you might need to use a decompression or extraction tool. In the worst case you might need to sit down and manually pull some pieces of out it by hand, but that's generally rare when considering all the cases one game is wrapped up into another or is part of some kind of bundle.
When we talk about tampering with the game, what is the game? If you consider the emulator part of the game, then yes you're tampering with it. If you consider the actual game the part you're extracting from the rest of it, then you're not tampering with anything.
feos wrote:
That breaks the authentic connection between the game image and the environment it was made for
We can agree exactly on this point, but use it differently.
I consider the game image and the environment it was made for is the original console it was created for, not the new package on a more modern system being shipped with an emulator.
feos wrote:
Third, if we require extracting those games, we should ensure that it comes from the actual VC release, and that it was extracted cleanly, without additional edits.
Well, the judge and publisher would need to get their copy of the game from somewhere, just like we do for everything else. We should not just be accepting something from the submitter saying this is the game.
feos wrote:
This will have to be verified by the judge, by reproducing the extraction process and comparing the results to what was used in the movie, or by comparing what was used in the movie to some "known good" database. Does such a database exist, like we have redump for example?
Funny you should mention this. As far as I know, I was the first person to extract a game from some bundle, at least in a public fashion. ~20 years back, a movement was starting online to build a database of different games. I worked on some of these databases. I extracted a bunch of games from within others that I had on standard mediums and added them to these databases. At first people were surprised as to where these came from, but when I said I just copied them off this CD or that floppy or extracted from that zip file, and they did the same and found they had matching games.
For the more modern systems doing this, I admit I don't know what the database situation is like these days. However if the people handling those databases are competent, they should be keeping track of extracted games as well.
As to "known good", that's highly arguable. I found many things that were labeled as "known good" in various databases to be flawed. As just one example, I'm responsible for practically eliminating the over-dump situation with SNES games. Prior to that, you had hundreds of over-dumps floating around that were considered perfect dumps, but they weren't.
feos wrote:
Finally, are we sure extracting games in this manner is perfectly legal?
Yes, absolutely.
feos wrote:
We don't want emulators to be illegally used in such bundles of course, and we don't want bootleg bundles. But we can't suspect VC releases in any of that so far.
AFAIK, all the VC releases should be 100% legal. My point was I feel the situation of accepting emulated releases to be problematic, and opens the door to a lot of problems. Legality is also a concept that depends on where you live, and we do have Chinese TASers for example. I'd prefer if we stuck to something that doesn't come back to bite us later. At the same time we can have what I consider a more authentic game experience, and not something slapped together with little care just to make more money.
To share an example from a different situation, Nintendo changes their consoles through the lifetime of the console. Early SNES consoles had boards with multiple chips on them. Later SNES consoles used a system-on-chip, and ran a bit differently. Some early SNES games have various bugs using these later SNES consoles. SNES emulator authors (and clone console creaters) purposely have been targeting the inner workings of the earlier SNES consoles in order to avoid bugs.
Here's the words of another SNES emu author, emphasis mine:
yeah, nintendo's own soc was *****
i don't even consider it when i think snesglitches on the first line comes from cheap ***** that's unable to output this early despite the whole undisplayed line 0 to delay it
for the sound glitches, i'm guessing that nintendo didn't have the rights to integrate sony's spc700 in their clone
due to not exactly being in good terms at that time
so they probably used a cheap chinese knockoff
There's clearly a scale regarding what different people consider original, compatible, or designed for.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
feos wrote:
Nach wrote:
Why is it wrong when we publish a run which uses an emulator bug from one of our emulators?
And before you jump to answer that, bear in mind that some companies are reselling their old console games as PC games, making use of some of our emulators, bugs and all.
Should we be publishing the results of relying on emulator bugs?
I don't see a problem with TASing the officially released bundle, with or without bugs within that bundle.
You're opening up the door to quite a lot with this statement. Capcom has released their CPS-1 library multiple times with different versions of MAME. Their NES library with different NES emulators. I've seen Acclaim, Accolade, and Midway sell some of their SNES games bundled with Snes9x 1.43 - illegally at that, or Mednafen. I'm sure there's plenty more that I haven't seen.
feos wrote:
It's how it's been released by the publisher, so people are playing it that way and experiencing those same bugs. They could've fixed those bugs, but they haven't. Exactly how we TAS original games with bugs that devs could've fixed.
This also gets into a gray area. Who is the publisher in various areas? Many Asian countries don't respect copyright law of other countries. In Iran or China you can walk into a store and purchase a DVD or flash drive from a respectable Iranian or Chinese company loaded up with many video games and popular emulators, and it's legal there. They're using various versions of FBA, MAME, Snes9x, mGBA, DeSmuME, Mupen64, PCSX, and more. Billions of people have access to these, and between that and those importing off of AliExpress, quite probably most people on the planet that have experienced the most popular games have done so via these emulators.
I imagine that you've seen similar things in stores in Russia.
feos wrote:
Bugs in unofficial emulators are not okay, because those don't belong to the release people are meant to be playing, on the original system without any extra layers.
What's official or not, and meant to be playing really depends on where you live.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
DrD2k9 wrote:
There are literally NO games designed to be played on the SGB as the primary system for playing the game. Every game released with SGB enhancements was first and foremost intended to be a GB or CGB game. From the perspective of playing games on the systems for which they were originally designed, we really should question why SGB would ever be preferred over the same game in GB or CGB mode.
If this were true, then why did HudsonSoft put out games that appear correctly with an SGB, but look squished on a DMG or CGB? They clearly designed some for the SNES resolution and not the DMG/CGB.
DrD2k9 wrote:
If developers had wanted the SNES to be the primary system that their game was played, they would have created a SNES game, not a GB game.
This is a good argument. However, there are reasons why a company might have done this, namely to get more sales for their game because it also runs on another platform.
I don't know if you know this, but later on in the SNES's life, Nintendo was selling SNESs with a bundled SGB and an additional game.
Making an SGB game at that time allowed you more market reach than just an SNES game which was restricted to that one console.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
