Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Kurabupengin wrote:
I don't know if this is a bug or just a silly mispelling error, but one of the movie tags says "Foregoes memory corruption". I guess it should be written forgoes instead of foregoes, but I'm a spanish speaker, so I dunno.
Or you could just google it and see that the third person present of "forgo" is, indeed, spelled "foregoes".
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I personally feel that in-game time is much like score: an in-game statistic. Aiming to keep it as low (or get it as high) as possible is an arbitrary goal (i.e. not any% or 100%) and should, like all arbitrary goals, be judged by entertainment value and go to moons if accepted. I don't consider it to be a vaultable goal.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Not to intrude, but I think this discussion would do better in the Rockman XZ thread, as that's where I'd look for an analysis on its RNG. That said, I think the best course of action would be to disassemble the ROM (does DeSmuME support breakpoints?) and figure out how the RNG addresses are used to look up the item dropped as I doubt there's an actual list with an entry for each possible value.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
To be frank, if we're taking the Yu-Gi-Oh! episode as the setting, it's "because he had a hunch". For those who haven't seen it (or looked up a summary): he thinks the brothers don't play fair, and can switch the doors after you've made your decision. By concealing his "decision" (a coin) he manages to trick them into revealing the door they think he chose as dangerous (and the other as safe), while actually choosing the other door. Very little to do with any actual sort of logic riddle, really.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
The improvements result in this run having a lot less "down time" compared to the previous one, which results in a lot more entertaining movie. Yes vote from me.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Flip wrote:
Which 6 countdown numbers would give the greatest possible range of attainable answers?
Looking at just the numbers allowed within the game (3-digit numbers), the numbers 1, 6, 7, 9, 10 and 100 allow you to make every number.
Disregarding validity within the game, the numbers 5, 8, 9, 50, 75 and 100 win, allowing a whopping 32644 possible numbers to be made.
If you (or anyone else) like, I could make files listing all these numbers and a possible way to make them. EDIT: Actually, no need to ask. You can download the first set here, and the second set here.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Masterjun wrote:
Ever since I wrote this script for predicting RNG in this run I wondered if the formula could be reduced. [...] So my question is: is it possible to reduce the formula or function to a simpler one?
Yes. Alyosha already noted how a single step in the inner loop behaved, which is basically a linear feedback shift register. For the code below, I used the standard bit library that comes with Lua 5.2, but any implementation or bit operators would do. I also, like creaothceann already mentioned, considered your RNG to be a single 16-bit value, rather than two bytes, which makes manipulation a lot simpler.
Language: Lua
require 'bit'
local function myRNG(rng)
local b
for i = 0x01, 0x0B do
b = 1 - bit.band(1, bit.bxor(rng, bit.rshift(rng, 1), bit.rshift(rng, 15)))
rng = bit.bor(bit.lshift(rng, 1), b) % 0x10000
end
return rng
end
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Warp wrote:
Determine what the ending of the game is (and be prepared to present an argument of why that's a valid definition of "end"), and then end the input when no further input can make the ending be reached faster.
I'd prefer if you didn't state this as a matter of fact, as this is just opinion. Some people prefer to end input as soon as no further input is required to reach the ending, others think that it should be ended when no further input can prevent the ending. In this case, I agree with MUGG and think that entering your name would be best (as that's where a regular play session would end).
creaothceann wrote:
Then someone else doesn't and supersedes your movie.
Of course not. If someone else submits a TAS that only cuts out the name entering without improving on the gameplay, it won't be accepted.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
feos wrote:
Am I missing something, or you're suggesting to host DOS Doom runs separated from Windows Doom runs? "It's not the same game"!
According to the guidelines, we A) only accept multiple versions if they offer different content, which is not the case, so we only accept one version. B) We select the version based on originality, popularity and superiority. For Doom, the original and most popular version is DOS, while for superiority does not matter, as they are all equal. Of course, there exist ports like glBoom, but those aren't officially sanctioned and should, as such, not be considered.
feos wrote:
Elaborate on the differences between these 2, and on (again) how emulating Doom altogether is better than making an internal movie for it (have fun expanding that principle to Hourglass too).
As you yourself said; maintaining a strict policy for which game engine movies we accept is impossible, and this will eventually go wrong. This is the first reason I'm against it. The second reason is that game engine replays aren't the same thing as TASes. In the case of Half Life 2, replay files contain actor positions rather than input, which means that completely impossible movements (like going through walls) is possible by hex editing these. In the case of Doom, it is impossible to control the menu, while this is very much part of the game. If a menu related glitch was found, a TAS would be allowed to (and in fact should) exploit: something that wouldn't be possible with demo files.
As far as Hourglass is concerned: the input file isn't played back by the game itself, but by Hourglass. All input is possible, but nothing more, which is precisely what a TAS should be.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
feos wrote:
First of all, DOS is only an operating system. DOOM was developed to run on any IBM PC compatible machine, and it's how we are running it actually.
No, it isn't. Doom was written for DOS, its graphics and sound were done by hooking into DOS. Yes, there is a version that runs on Windows, and yes, there is a version that runs on Linux, but those are not the original. Those are ports.
feos wrote:
Sure, you can completely limit yourself to running it on DOS only, but how would you dump AVI from it then? And what quality it will be? Some may say "it will be autentic original quality", but why use poor 3D if we right now can afford superb 3D? Just run glBoom, and it starts looking as good as possible, while still syncing for the same movie. Should we drop advantages? I don't think so. It all means, DOOM is not DOS-exclusive. It's just a map.
glBoom is, again, a port. It is designed to mimic the original Doom, but it's not the same game. If I ported Super Mario 64 to Windows, you wouldn't care how pretty it was or how perfect the physics and everything else were copied: you would never allow it to obsolete the N64 run because it's not the same game.
feos wrote:
The benefit from it being... what?
That we actually have a proper run of the game. It would mean that we're actually TASing Doom, rather than making the best demo that Doom can play.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
adelikat wrote:
I'll start the debate by explaining my distaste for the DOS option. Doom isn't inherently DOS, as it also runs on windows. In fact, DOS had NOTHING to do with the making of this or any DOOM TASes.
How is Doom not inherently DOS? It was developed for DOS, and the original version runs only on DOS. Sure, there were ports to other systems, but when did we start considering those to be the same thing? And no, DOS had nothing to do with the making of this or any Doom TASes, but that's only true because the development of a Doom TAS is done on a port. I could make a Super Mario Bros. TAS using only a hex editor on my TI-86, but it's still an NES TAS.
Warp wrote:
What ambiguity? The PC hardware is pretty de-facto standardized. (It's a combination of x86-compatible processor with a certain memory and I/O layout, which allows certain specific OS's and programs to run on it.)
What, like a PS4, or an Xbox One? I find that a pretty terrible definition.
Radiant wrote:
But other than with such source ports (which are exceedingly rare), you cannot play DOS games on a windows machine except in an emulator, and of course you can't play Windows games on a DOS machine either. For starters because one is a 16-bit system which has issues accessing more than one megabyte of RAM, and the other is a 32/64-bit hybrid that runs on dual or quadcores and has system requirements starting at one gigabyte.
Although I agree with most of your post, I'd like to point out that the first non-DOS Windows was NT 3.1, which required a whopping 12 MB of RAM.
In general I'm not happy about having movies specifically for one game. These input files are played back by Doom itself, not fed to the game by an emulator. This means that you're entirely limited by (or not, in the case of playback files that record position or such) what the game itself supports. You can't even go back to the menu, switch levels, change settings or anything, because .lmp files don't support that.
Now Doom is very popular and has a big place in TASing history, and I think it's a bad idea to not make an exception for this. However, I feel it should be done with the note that a proper, DOS-emulator-made TAS should replace it in the future.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
There's a story my high school maths teacher told me about our national exams (for graduating high school): there had been a question that was phrased "Can you draw a graph representing this function?", to which a student had answered "yes". In the end, they had to give him full points for the question.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Aqfaq wrote:
The encode looks a bit dark. Maybe use gamma correction level 2 or 3? (Press F11 to change it.)
Vanilla DOOM vs. Aktan's encode
Sampling these frames shows that vanilla DOOM is actually even the tiniest bit darker than Aktan's encode. It's close enough to be nigh unnoticeable, but making it brighter is definitely not the way to go.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
FatRatKnight wrote:
The function should return an object. Not a handle number like with form calls, an actual object that can be indexed like a table.
I understand that this might be more convenient, but is that really such a hard demand for you? Otherwise, implementing some functionality for the form-component PictureBox would make most of what you want to do possible.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
FractalFusion wrote:
3) Not everyone knows how or is willing to deal with a command line.
I feel that if using something as straightforward as a command line is too technical for you, even if you have to do it exactly once, to work around a bug, you're not the kind of person we want to cater for.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
That Nintendo page states several things as facts that are generalizations ("The video games are obtained by downloading illegally copied software, i.e. Nintendo ROMs, from Internet distributors."), highly disputed ("Are Game Copying Devices Illegal? Yes.") or baseless assumptions ("If these vintage titles are available far and wide, it undermines the value of this intellectual property and adversely affects the right owner."). Of course, that doesn't mean it's completely wrong, but it does mean that it has little to no juridical value, and is not to be taken as a trusted source of information.
And as to uploading encodes of TASes to Youtube: well, the clue's in the title, isn't it? The work on display is the TAS, not the game. There's plenty of case to be made for fair use here: the work is transformative, non-commercial, highly creative and does not compete with or harm the market for the original product. Of course, Nintendo (and possibly other companies) will deny the latter, but they have lost that case before.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
adelikat wrote:
If you made a movie of all 4, it could be broken into separate movies and still sync, and vice-versa. I'd rather the separate movies, that can be more easily competed against, than one monster movie that is just a concatenation of separable content.
The fact that you could improve a single episode and then safely stitch the whole thing back together means that a single "monster movie" is just as easy to compete against.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
MUGG wrote:
You can download them and play them back in media player classic over and over.
jlun2 wrote:
It utilizes gif's loop only once feature. You can download it, then resave it in GIMP with the options "Loop forever" ticked to see it loop over and over. :P
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
To reiterate what I said earlier in IRC:
To anyone looking up the original NES version (so not this one) on the site, having this run obsolete it means they won't be able to find a current TAS of it. Which is, of course, not a situation we want.
And something I didn't say in IRC:
Should you decide for obsoletion (you shouldn't), I'd argue against co-authorship. We don't do retroactive rejections, but there have been cases where an existing run was deemed "bad goal choice" (or something similar) in hindsight, and as such a new run was made to obsolete it, without any mention of the previously existing run (i.e. co-authorship). In my opinion, this would be a similar case, with the "rejection" reason being bad game choice.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
Nisto:
From a quick look at your script I see that background and forecolor aren't defined anywhere. Not sure if that would cause the error you name, but it's a bug nonetheless.
phoenix1291:
Well yes, but we don't have any affiliation with Emucr. If their description is wrong, that's something you'd have to take up with them, not us.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
I have tested freezing and poking for both SNES cores, on both 1.9.2 and r8948 and everything works. It's not always perfect - this is probably due freezes actually being repeated pokes, which means values can change during a frame, but it definitely works. Which means you're probably using the wrong addresses or misunderstanding how the game uses them.
Experienced Forum User, Published Author, Player
(144)
Joined: 7/16/2009
Posts: 686
This looks good, and I have only one question: in level 29, why did you take the leftmost route (17 moves) instead of going down the middle (15 moves)?
