Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
zeromus wrote:
But a start-up state like what adelikat uses is possible, and it is proven by videos of cheetahmen II booting up to the target level after multiple power cycles
Check these videos again, they are using Reset button instead of switching power off and on. Adelikat's movie doesn't use resets, so youtube videos don't validate the submission.
zeromus wrote:
If you ask me, NESbotability should be an ultimate decider in favor of legality.
Of course, naturally.
zeromus wrote:
You could even get something like a NESbot to play this movie, if you let it control the power cycling too. Eventually it would work, just like in the videos.
If NESBot were able to control the reset button then it could probably reproduce this bug... by playing a movie that uses subframe resets! (then again, maybe there's something else necessary)
As for this submission, NESBot would need to first recreate the bug on its own, and only then start replaying the movie input.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
jlun2 wrote:
er....now you're bringing up hardware limitations? I think Up/Down and normally other impossible input combinations were already pointed out in the SMW thread many times
Stuff that is normally impossible, but technically possible = field of TASing.
Stuff that is not even theoretically possible without modifying the game/console/etc = field of modding/hacking/etc.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
jlun2 wrote:
I just want to know why we are allowed to change the firmware settings for NDS movies to get a better RNG without all this debate, yet changing the initial state is wrong.
Firmware settings can be changed by the owner beforehand, and they are restored reliably when starting a movie. IIRC, manipulating these settings is even used by regular players (Pokemon/etc).
RAM values/mapper registers/other hardware quirks, on the other hand, are not as well examined, so you shouldn't be very picky, unless you have a proof that your chosen setup actually exists in hardware, not just in theory. And even then it would be more hacking than TASing.
I mean, I personally like hacking and reverse-engineering, but I know when I'm crossing the line.
jlun2 wrote:
Since my NDS most likely has a different setting than this, does that mean I'm cheating?
If NDS cannot possibly have these settings (e.g. because of some hardware limitations), then yes, you were cheating.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
True wrote:
To quote your own source, verbatim, "Please note that you should NOT rely on the state of any registers after Power-UP and especially not the stack register and RAM ($0000-$07FF)."
Why? It is how this hardware works.
The less vague answer is actually on the same page: "The memory values are probably slightly different for each individual NES console." Also, considering there were different revisions of the console, it's always wise not to rely on something that isn't officially supported by the console.
But at the same time, you should never rely on the opposite (that all consoles behave as a hardware random number generator). It is likely that some patterns/sequences of values are even impossible to ever see in NES RAM at poweron.
True wrote:
Do you want to learn?
If one were to accept the rule change, then yes, the technical ground behind the change must be learned in full.
Though I don't like where this change would lead TASing in general. This is not TASing anymore, because heavy tools would be used to achieve smaller goals, and that's just not cool.
True wrote:
For a practical example, try replaying the fighter FF TAS on NES, and notice the first battle is almost always different.
I see, the game reads a few addresses before writing to them.
Anyway, your console behaving differently from the one at nesdev doesn't make an excuse for TASers to edit the initial state of games any way they wish and still deny to be called cheaters.
DrJones wrote:
However, this run is interesting if only because it tries to showcase a bug that cannot be emulated, even if it achieves this by questionable ways.
I wouldn't call this a showcase, since the movie doesn't reproduce the bug itself, it just starts from a state similar to the state achieved by the bug. Here adelikat used special initialization tags in his movie, but you can also use the good old "savestate" tag. For example, this FCEUX movie enters level 5 exactly the same way - by changing the initial state of the mapper registers, and leaving everything else with default values:
http://tasvideos.org/userfiles/info/10117227735638386
See, what's the difference between movies starting from a savestate and movies starting from a craftly customized poweron?
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Allowing TASes to start from an arbitrary state (instead of a universally accepted state) is a huge change of the site rules. It's funny that such an unentertaining TAS would be a ground for changing rules so much.
Also, I'm questioning the technical side of the original assertion.
Where is the proof that NES can start with any uninitialized RAM values? This page states that "all internal memory ($0000-$07FF) was consistently set to $ff except for a few bytes". Same goes for mapper registers - you don't know for sure if they can have those values at poweron.
Nach wrote:
So here's the real question. How do we know the game can *start* in this state? Maybe it can only *reset* to this kind of state?
Think about the following scenario: The PCB initializes certain registers upon power on, but does nothing to them upon reset. The game does nothing itself when it begins. Do we have any data which proves the PCB does not initialize the registers in question?
The video above only proves it can be reset to a similar state.
Exactly. Youtube videos only show how the registers got those values after many consecutive resets (which could mean that the needed values are written after launching the first level, or that the mapper hardware needs to undertake several consecutive surges in order to gain enough heat, or something entirely different - but it doesn't show that fresh cartridges may have these values in mapper registers by default).
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
ProcyonSJJ wrote:
But if we did that, in the SMB3 example, the stage would not end in black, it would continue to be the color of the sky.
Well, there, if user prefers to see a sea of black blocks, he can uncheck the 2nd option ("Hide voxels using the palette of sample pixel"). So everyone will be able to choose whatever he considers the lesser evil. For example, I think omitting the black ending entirely isn't as bad as the sea of black voxels.
Your method of sliding pixel may solve this specific situation, but the color will change abruptly (from blue to black) and user will see first the approaching sea of black voxels and then suddenly the sea of blue pixels... IMO it's better to remove both.
ProcyonSJJ wrote:
I didn't mean to sound so pessimistic, I think it certainly could be ported to Windows specific code relatively easily. On the one hand, SDL and GTK libraries are available for Windows, so that's one route. On the other hand, OpenGL can play just as nicely with DirectDraw as it can with SDL, so that's always a possibility. That would make the port even simpler. I think it can and will happen, it's just a matter of finding the right assistance.
Glad to hear! I guess it's the matter of scale. It's always like this. It's pretty easy to make a proof of concept or a prototype to show friends, but once we start considering wider public, the new scale of the project suddenly brings us some unexpected tasks, like the need to think about UI and performance, to obey some 3rd-party code licenses, to write portable code, to write documentation, and, in general, to learn new stuff.
Mapper's registers are saved in a savestate file, their values are part of the game/console state. Initializing these registers is the same as initializing CPU registers, which in turn is the same as initializing RAM.
adelikat wrote:
This statement implies that something changed. It did not.
OK, this is pure hardware question which is too vague to argue about.
adelikat wrote:
On power on, there are many possible states the hardware could be in. Why is one of these states more valid than the other to because "the" state?
That one state is more valid, because it's universally chosen by the community, and it applies to all games on the platform. If the community chose a 0F0F0F0F pattern, it would have to be applied to all games and TASes on the platform as well. Having a custom pattern for a certain game is possible, but it counts as "starting from savestate", because it gives you an advantage over TASes that used common pattern.
adelikat wrote:
Until now, to create a "clean sandbox condition" we have arbitrarily been picking a state and calling it the state at which an NES starts up in.
At least the state was hardcoded in emulators and was obligatory for everyone, so it created equal opportunities for all TASers. Are you suggesting that "from now" TASers can choose whatever initial state they want and thus beat old movies with movies starting from a savestate?
adelikat wrote:
In summary, I don't see the logic in a verification movie to verify a possible state this game could start in.
Then what was the reason for this rule? If there's no need for verification movies, maybe we also don't need to submit input logs, just provide a savestate for the last frame of the movie (+Youtube encode)?
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
So, instead of emulating subframe resets to achieve the same goal legitimately, you decided to add the ability to store initial state of mapper. A quick-and-dirty solution suits the game well, sure. But, effectively, this new movie starts from a savestate, even though it doesn't initialize RAM, only mapper's registers.
According to the site rules we still need to have a verification movie (e.g. one which plays first 4 stages of the game and then resets at such a moment when mapper registers have all the necesssary values, or maybe just resets without playing any levels).
TASVideoAgent wrote:
If the all powerful superhuman that TASes represent can predict future RNG values, why can't he have full control over when to turn on the hardware to get the values of his choosing?
It's generally implied that the state of hardware doesn't change while it's powered off (at least it shouldn't be changing inside the clean sandbox conditions).
So, it's not enought to simply choose the right moment when to turn power on (when to drag the console out of the "cryo camera"). The superhuman would need to previously mess with state of the game (e.g. while recording a verification movie).
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
ProcyonSJJ wrote:
AnS wrote:
So, I guess most of time you'll need to filter out voxels of two colors: of the BG color and of the predominant color.
I don't see how that's possible to do. Only one color can be used as the fill color.
I mean, use one color as the fill, but remove voxels of both colors.
ProcyonSJJ wrote:
Though, truth be told, Transparency sucks. I don't know if it's due to the way I set OpenGL or what, but all it seems to do is reduce the quality of the picture.
Have you tried more ideas, like making the transparency depend on the distance from camera (so that nearest voxels are more transparent), or making the face of voxels to be more opaque than sides and backface?
ProcyonSJJ wrote:
It doesn't do what I hoped it would do, which would be to make the voxels more "crystalline" in appearance.
As far as I understand the effect, it's more about the play of light, not about actual transparency. Instead of simple transparency it is translucency that makes magic (and some advanced lighting + shaders, which I don't know anyway).
ProcyonSJJ wrote:
BTW, AnS, I started to look over the Windows specific code, and I realize that it's using DirectDraw, but not Direct3D, which makes perfect sense. But the lack of a proper 3D interface upon which to implement this means it may forever be an SDL-only feature. My knowledge of D3D has always been poor, and substantially weaker than my knowledge of OpenGL. A Windows solution may only come about through a willing volunteer who can undertake the port.
That's too bad. I hoped the engine could gain some popularity among casual players.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
ProcyonSJJ wrote:
For example, most Mega Man games just leave the BG color black.
Actually, even they use BG color, just not as a "skybox" fill. For example, I remember, in Megaman 2 screen flashes for a frame when using Flashman attack, and when you receive an item from Dr.Light:
So, I guess most of time you'll need to filter out voxels of two colors: of the BG color and of the predominant color.
BTW, the predominant color is better stored not as some coordinates of a pixel, but as an index of the palette entry (e.g. PALRAM[6]). Of course user should be able to define this index by simply clicking screen (then the program retrieves the pixel at these coordinates and finds out which palette entry the pixel uses at the moment). This method will work even in side-scrollers.
ProcyonSJJ wrote:
For games like Zelda, and others that have a top-down or birds eye view, I was thinking of another way to deal with the 3D effect. I imagine the emulator must know when it is rendering a background object versus a player or enemy sprite. If that is the case, it might be possible to have a secondary 256*256 buffer that serves as a depth buffer. Even if it's just 0 for bg and 1 for fg, that would be enough info to let the renderer know that a fg object should be drawn at a depth closer to the camera, so that it "floats" above the background. Any idea if that's easily doable? Without screwing up the emulation too much, because this is the only feature that could possibly take advantage of it.
This is not easily doable, as it requires a certain code injection in the core (ppu.cpp).
Once you successfully implement everything else, I can take the risk of carefully doing this.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
On the title page, shouldn't the screenshot of the "Featured Movie" be clickable? (similar to how "Latest Publications" section has a clickable screenshot to the right)
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
ProcyonSJJ wrote:
For example, in Super Mario Bros., the background fill color is black even when most of the background sky is blue.
No, in SMB the background fill is blue (and black in World 3-1, etc).
You can check this by running Windows version of FCEUX and resizing the window.
Although, yes, there are games where most of screen pixels are drawn using different color, so there should be a way to specify BG color manually. But default value should be taken from PPU.
ProcyonSJJ wrote:
In my experience though, if the background wasn't strictly black, most games didn't really do a good job setting that color.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Alright, so it seems you're working pretty efficiently, even though it's your first TAS. Good luck with the game.
TheAngryPanda wrote:
what exactly do you mean by a Piano Roll? Is it more or less just having a set of options/inputs and altering them until the output is acceptable? Like I said, still new at this so some stuff people say I'm not familiar with. I'll do a search once I'm done typing this though.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
TheAngryPanda wrote:
Regarding the "only test 3-4 strategies" thing
Just in case you've got me wrong, I wasn't saying that it's enough to only test a few strategies! I was talking about the number of strategies that are kept simultaneously.
Why would you want to keep savestates of a strategy that is considered obsolete? Just reuse all the slots that store the timeline of the old strategy when recording next strategy.
TheAngryPanda wrote:
state 5 = start of area (clean slate basically)
state 6 = player input location (where the dog is at in my case as well as if he's sniffing)
state 7 = start of combat + initial manipulations (first point of backup for fight)
state 8 = secondary manipulations during previously manipulated events (boy starts attack, damage isn't calculated until X frames later, between start and X frames i can manipulate things)
state 9 = 2nd basic reference point for various things (common-use state)
state 0 = 1st basic reference point for various things (common-use state)
This indeed looks like a problem caused by working with huge segments. It's only natural to break such segments into smaller subsegments. As I see it, you've already divided it into 3 segments:
A) pre-combat player input (dog/etc), until the start of combat
B) initial manipulations - those frames from the start of combat to the start of attack
C) secondary manipulations - X frames from the start of attack to the point of calculating damage
So I imagine you're doing the following (if not, then I would like to listen for your version of the workflow):
1. Slot 6 stores the start of segment A. Record a first version of pre-combat input using slots 2,3,4 for undoing mistakes. Then, at the frame when the combat is going to start, save state to slot 7 - this slot will store the end frame of segment A.
2. Slot 7 stores the start of segment B. Record a first version of initial manipulations using slots 2,3,4 for undoing mistakes. Then save state 8 right after pressing the trigger button - slot 8 will store the end frame of segment B.
3. Slot 8 stores the start of segment C. Record a first version of secondary manipulations using slots 2,3,4 for undoing mistakes. Then save state 9 after X frames elapsed - slot 9 will store the end frame of segment C.
4. At this point you have recorded the first strategy completely. Save it to slot 0. Since the final frame of the big segment coincides with the final frame of segment C, slot 0 will contain the same state as slot 9 (at least for now).
5. Now try different strategies. Do not touch segments A and B! Only rerecord segment C for now. Slot 8 stores the start of segment C. Record a 2nd version of secondary manipulations using slots 2,3,4 for undoing mistakes. Then save state 9 after X frames elapsed. Compare the result (damage produced in slot 9) with the result of slot 0 and rewrite the slot 0 if the 2nd strategy for segment C is better. Then try 3rd strat, 4th, etc... until you start thinking that trying different initial manipulations would produce better ground for secondary manipulations.
6. Slot 7 stores the start of segment B. Record a 2nd version of initial manipulations using slots 2,3,4 for undoing mistakes. Then save state 8 right after pressing the trigger button - slot 8 will store the end frame of segment B. Oh, and there's no need to keep the old state of slot 8!
7. Repeat steps 3-5, trying different versions of secondary manipulations, now they will likely produce different results, thus some of them may produce higher damage - each time the result improves, resave it to slot 0.
8. Repeat steps 6-7, trying 3rd strat for segment B, 4th strat, etc... until you start thinking that trying different pre-combat input would produce better ground.
9. Slot 6 stores the start of segment A. Record a 2nd version of pre-combat input using slots 2,3,4 for undoing mistakes. Then, at the frame when the combat is going to start, save state to slot 7 - this slot will store the new end frame of segment A.
10. Repeat steps 8-9, trying different strategies for segment A, for every new strategy you have to try different strategies for segment B and then for segment C. Any time you finish the segment C, compare the result (damage produced) to the slot 0, and overwrite slot 0 in case of improvement.
This is the only way to ensure you've tested everything. And it's more efficient than trying to rerecord the whole big segment from scratch every time you feel like you need to change something in the beginning.
Now, all this sounds like an exhaustive search (brute-forcing), but since you're human, you'll naturally be using some amazing heuristics, so you'll successfully skip many strategies before testing/recording them to their end.
Also, you can stop the search anytime and just take whatever you have in slot 0 at this point. At least it will be the best strategy from all those you've tested.
Anyway, as I see, most newbies don't divide the big segment into smaller ones, they usually only test a few strategies in a chaotic manner and get satisfied with a lucky but imperfect result. This is a viable option too, especially when you're tired.
TheAngryPanda wrote:
Is there a better/easier way to do this?
If actual botting of the RNG is not an option, I doubt there's any better way than described above.
Subsegments are the way to go - both when you want to test a thousand of approaches and when you want to just try a few.
RNGs aside, most games are simple enough that a few different strategies actually exhaust the range of possibilities.
TheAngryPanda wrote:
I imagine the save state as feature could be used fairly well here?
No. "Save State As" only slows down the process of loading states. And you don't need too many slots, even when you're working with such huge segments as in your case. And I consider you case to be really difficult one.
What would help: a Piano Roll which allows you to enter new strategies and test much them faster than with traditional rerecording. This way you won't even need slots 2,3,4 for undoing mistakes, because there's Ctrl+Z, rewinding and other neat stuff.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Most rerecording emulators do have unlimited savestates (you can use "Save State As" command and then type the name in the Browse/Savefile dialog). But they usually have 10 auto-named slots, that's different thing. The particular number of slots is because there are 10 numeric keys on the keyboard (plus at least 10 functional keys), which conveniently allows to use any slot anytime (either switch to any slot directly (without cycling through), or actually save/load the state of this slot without tedious searching).
Patashu wrote:
There's an easy way to make an infinite number of savestates available - type them.
Have you tried TASing? There's no time for typing. You need to juggle savestates using mostly motor memory, or else you're gonna lose attention.
www.fceux.com/web/help/taseditor/index.html?TraditionalTASing.html#savestates
Patashu wrote:
You could have memory watches saved and displayed when you hover over a savestate, as well (e.g. if you're comparing the x position and frame count of many different attempts, you'd like to save each one and hover over them all and see which one got further into the stage in the same amount of time!)
Memory watches are last week, it's better to draw Lua overlay on the actual screenshot. For this exact effect.
Patashu wrote:
Is there a particular reason why no TASing emulator has implemented this yet?
A certain emulator definitely has. Not exactly what you described, but I believe it's something which resembles your idea after it's been refined by 1.5 years of development and field testing.
Patashu wrote:
Wouldn't it be more user friendly than having to associate 10 numbers with what you're currently doing, and having to reuse them again and again and again for different mappings as you test different things? And if you go test something else at the same time you have to cram it into those 10 and so on... etc
The problem of scale is solved by only testing two (or 3-4 at most) strategies at a time (so their results can be saved in a limited number of slots) and culling early.
The fact is, human memory is even more limited, so there's no point in increasing the number of slots. Some TASers actually use only ~4 slots when working, and others use most of slots for navigation/rewinding (and only a couple of them for storing strategies).
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Actually, now that I think about it, maybe it IS quite enough to only mention previous authors in the submission text for most of cases. At least I personally wouldn't demand being a co-author of a movie that improves my old records, even if the new movie copies some of my playaround antics (some games have very limited opportunities to entertain).
So I wouldn't object if the site stated clearly (somewhere on the license-related page) that "Any submission recognized as a valid improvement to a published movie can freely use the old movie input without giving co-authorship to the old author, unless the judge or the new author himself considers it necessary."
This way the question can be handled by judges case-by-case. For example, 1 frame saved in SMB may be considered big enough improvement for completely changing the authorship, while the same 1 frame in Final Fantasy probably wouldn't be even accepted for publication, and the same 1 frame in SMW "Glitched" would probably need a co-authorship (judge may either check the opinion of the audience of just decide it for himself, of course weighting in the new author's opinion and explanations).
Derakon wrote:
If you have to rebuild significant portions of the input for any reason, then it's reasonable to claim authorship; you might well still list the previous author in the "special thanks" section of the publication, but you wouldn't be obligated. It doesn't matter if the visible improvement is only a single frame; what really matters is the amount of work you put into the run.
Agree, just with one clarification: the amount of useful work you put into the run.
So, I guess most of time you'll need to filter out voxels of two colors: of the BG color and of the predominant color.
BTW, the predominant color is better stored not as some coordinates of a pixel, but as an index of the palette entry (e.g. PALRAM[6]). Of course user should be able to define this index by simply clicking screen (then the program retrieves the pixel at these coordinates and finds out which palette entry the pixel uses at the moment). This method will work even in side-scrollers.
Although, yes, there are games where most of screen pixels are drawn using different color, so there should be a way to specify BG color manually. But default value should be taken from PPU.