Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Personman wrote:
imagine a v1.1 of SMB1 in which you start one block further to the right, and there is one fewer column on the left edge of the level. It's not as though a run on the v1.1 ROM could NOT gain those few frames, but it would still uncontroversially be accepted as the shorter movie, no?
I think, the answer is obvious.
BadPotato wrote:
At this point, it seem that no-no people would think that register are still part of the states
What, anyone still thinks they are not? How else would I be able to make this movie?
Well, ask an expert (like zeromus) - mapper registers are part of console game state, so they are part of any savestate. This submission muddles the matter because it uses differently named tag to write the data from the movie file into registers. But I thought at this point of discussion the initial confusion cleared a bit.
BadPotato wrote:
I see nothing wrong with that, but I'm not sure if this is the way to go if the site want to promote entertainement.
The site promotes either entertainment or legitimate tool-assisted world records. But this submission is none of these two.
feos wrote:
I think it was proven that this run is valid in all terms, and must be judges as a real run.
The movie is only valid in one term: the initial state it uses is possible to have on a real console. But, you know, KONAMI Code is also possible to have on a real console. Doesn't make it an acceptable speedrun yet.
Radiant wrote:
For what it's worth, it is likely that some or most of the negative feedback is either due to misunderstandings earlier in this thread
For what it's worth, the positive feedback is simply an incorrect interpretation of the question about entertainment, as usual.
First pages of the thread focus on hardware question, so it may seem that this is the only questionable aspect of the movie. But no, this movie has many questionable aspects.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
I don't really stick to calling the movie "savestate-anchored", I'm perfectly fine with calling it "a different version of the game" or any other distinctive label.
Although I don't quite understand how a movie for the 2levels-version can obsolete the movie for the 6levels-version. It's not like player could not skip the first 4 levels after selecting the shorter version - so I don't get where's the gameplay improvement, the time was gained solely trough versions difference.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
adelikat wrote:
AnS wrote:
That's the point I was trying to convey since the first page of the topic: let's realize that this movie essentially starts from a savestate
And now we are on page 6 and I'm no closer to agreeing with this.
Is it because you intentionally refer to a very specific definition of savestate, like "a file or a data blob storing the state of entire emulated platform"? Well, of course then your case doesn't match the definition. But it matches the broader meaning of savestate, which includes all those TASes starting from dirty SRAM, etc.
I wonder how would you characterize your case then. "A movie starting from an alternative initial state"? But this assumes the state is as valid as all those states where you start from title screen. You've proved it's physically possible, now prove it's legitimate in the context of playing games. Or do you want to simply accept Nach's idea that TASing has nothing to do with games, and is just software testing? I suppose you don't.
If the proverbial superhuman were to start his playthrough from level 5, the audience would ask him to reset the console up to the regular state, or else the playthrough won't be accepted as a world record for default category.
If the game were so glitchy that level 5 would be launched from every 2nd try, the playthrough would be accepted as a different category (so the run would be named "a world record for playing the game starting from level 5"), but in no way would it be considered to beat the existing "world record for playing the game starting from level 1".
adelikat wrote:
The implications of accepting this movie's premise (exploiting the initial hardware state) is a good debate and worth having, and I hope we will focus on that now, going forward. (Note: this post intentionally avoids this subject, but I do have a lot to say on the matter)
Uh, so, when are you going to you say what you have on the matter?
Also, in case you want to bring the old argument that previous TASes rely on the arbitrary initial state stored inside emulator. No they don't. Instead, their synchronization depends on various constants in the emulator code, like CPU timings or initial values in registers. When the emulator changes some constants (or when console behaves differently from emulator), some movies may desync, so they have to be resynced, which means changing the form without changing the content.
https://en.wikipedia.org/wiki/Form_and_content
For the concept of your movie to even exist, it requires a specific state. While regular TASes only require determinism, and they don't care if emulator implements determinism by making the initial state to be constant (instead of rand()) or by auto-adjusting the final Input of the movie every time when replaying (or by re-rolling the initial state until sync, or by any other method of making TASes possible).
That's why your work is state-anchored while other TASes are not.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Sergunov wrote:
Can we hope for Dendy-mode in future?
Only if someone who is interested in this mode joins the development. Personally I don't care about the mode, as I've been playing NES emulators for more than decade, while I was playing Dendy only for a few years in 90s, so I'm long accustomed to 60FPS instead of sluggish 50FPS.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
adelikat wrote:
misconception
Look, there's no much point in diving into physics just deep enough to prove something on your side, because then someone might dive into physics even deeper and prove that the state is not truly random, etc. This is infinite process of studying the reality, but when making rules for the site we'd better not stop at a point that is biased towards a single idea.
I suggest not basing the legitimacy of a speedrun purely on known physical intricacies of the game.
adelikat wrote:
In that case, it is blank, because it wasn't touched, it was simply one of the many possible states the cart could be in, on power-on.
OK, physically it's blank (if we're gonna call every possible state blank), contextually it is not blank.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
feos wrote:
Since reset doesn't seem to do the trick properly
This is not a fact. My script in the previous page only simulates CPU reset, without actually emulating all physical nuances of pressing the button on a real console.
On a real console the reset will likely trigger the trick as often as poweron does.
feos wrote:
Because yes, if we use some preset values to even start the game, it is a savestate of some kind.
That's the point I was trying to convey since the first page of the topic: let's realize that this movie essentially starts from a savestate, and then let's decide whether this is justified (as in, case by case).
feos wrote:
But it can not be treated as movies starting from "blank" state
Physically, there's no such thing as a blank state, although conceptually some subset of states can be considered "blank" (or "regular").
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
AnS wrote:
nor logic meaning. (unless they do)
Speaking of which, maybe this submission actually has it. The alternative starting point leans on those AVGN/Kickstarter ballyhoo. Not very solid base if you ask me, but maybe it is for adelikat. This would probably look appropriate in a Demos tier, but I wouldn't like this to create a precedent of accepting meaningless movies to the Vault.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Patashu wrote:
AnS: Would you still argue the same way if both the register state in adelikat's movie and the register state that was previously used in Cheetahmen II TASes were physically equally likely to be taken upon power on of the cart? e.g. if a TAS that starts from stage 1 is powered on and the cart decides to start from stage 5 instead, now that TAS is broken, so shouldn't that TAS need the same trick of restarting until it is a correct register state?
Short answer: yes.
When legitimacy of speedruns cannot be based on a physical meaning, it has to be based on some other aspect of real world. Nach suggested allowing free choice based on a model of having an absolute control of reality, but I find this model a bit too presumptuous and not very creativity-inciting. Instead I think the basic guidelines should be inherited from regular speedrunning (we could argue about this in a separate thread).
If such a game as you describe existed, both states would be equally considered as possible starting points to play the game normally. Regular players would be often starting their playthrough from the latter levels, so a TAS movie anchored to the latter point would adhere to known rules (while having different rules on how to play the game after it has started).
Speaking about NESBot, any movie for the game you described would need the same trick of restarting until it is a correct register state. Because all movies would be starting from a physically arbitrary state, and at the same time all of them would be starting from an audience-approved audience-related point.
Fortunately, in most games we can anchor the playthrough to a state which is both physically-realistic (may be achieved from a couple of tries in NESBot) and familiar to general audience.
I'm saying "physically-realistic" instead of "physically-justified", because apparently nothing is consistent in real-world physics. But while the "00000000FFFFFFFF" pattern may not have an absolute physical meaning, at least it has a semantic meaning - it's a state with consequences known to everyone. Other patterns have no physical meaning, nor logic meaning. (unless they do) And when you anchor your movie to a completely meaningless state, you can't expect the result to be meaningful by itself.
Note: all this talk about legitimacy of world records is only related to Speedruns. Superplay movies (playarounds and, generally, everything above Vault) do not need to be based on some real-world phenomenons, because they are already justified by the real-world phenomenon called "entertainment".
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Not only the movie can be "simulated" by starting from a savestate, it is actually achieved in the BKM by starting from a disguised savestate.
Sure, the BKM doesn't specify CPU registers or RAM contents yet (but, as seen on the first page of the thread, adelikat already considers doing it when necessary).
OK, let's call it "partial savestate" for now.
Now, if you say that specifying the initial game state using "partial savestate" (new tags) is not the same as specifying the initial state using old savestate tag, then indeed, my assertion would be a fallacy of four terms.
But I consider it to be the same thing (when talking about TASing).
In my opinion, a genuine TAS movie should only contain instructions (code, not data) which describe player's actions (pressing a button, switching disk, etc).
If a movie contains a pre-prepared data which represents a finished result of player's actions, this is not a pure TAS movie (doesn't mean it must always be rejected, e.g. some movies start from dirty SRAM, which essentially is data = result of playing actions that were too boring to include in the published TAS).
This data takes some non-zero time to prepare, but when inserted in the movie it effectively takes 0 frames, and its actual time is not accounted in the final time of the TAS. I consider this to be a violation of speedrunning spirit. I'm okay when this is done as an entertainment boost, but don't agree with the movie being Vaultable.
If adelikat were to submit a movie where the state of registers were achieved by describing the necessary player's actions (e.g. the BKM would contain a script which powers console on and off until it notices the trick worked), I wouldn't have any objections. And of course I also wouldn't have any objections if it was a movie achieving the trick by resets. Because it would be a genuine TAS, not a "TAS + some unaccounted activity".
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Bobo the King wrote:
Compare that with the 40 minutes it took for the script to run.
But human time and processing time are incomparable. Leaving a script running for a whole night isn't much of a trouble. Well, I'm not insisting on screenshots, that was just some obvious idea to bring up.
Bobo the King wrote:
That sounds really cool! I don't care too much about getinput, submitinputchanges, and savin every frame because my script already works fine without those features (though it could be improved with or without those features). However, I'm curious about how its visualization feature will illuminate different aspects.
If you're going to store the input in a custom container (instead of the actual played movie), then it won't illuminate this data of course. I guess I was more thinking of how would I make such a script.
Bobo the King wrote:
BadPotato wrote:
Thought, if you want to get rid of "artistic" value of a movie in favor of minimal input, you might prefer using the golden addresses. Ex: The game has some waiting time, so the player use this time to mess around, even thought he could just stay idle while the game prepare more gameplay.
That is exactly correct. I would like to try my script out on a game that features some small amount of goofing off and see if it removes the player's fidgeting. There's already a small example of that in my Dr. Mario movie where I screw around on the title screen.
This is certainly not a problem, since the script shouldn't be working on the whole movie (that would take too much time even with an optimized algorithm). Instead, users should be able to select ranges of the movie to process. (oh, I guess I'm thinking in terms of Piano Roll again, heh)
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
adelikat wrote:
The implications of accepting this movie's premise (exploiting the initial hardware state) is a good debate and worth having, and I hope we will focus on that now, going forward. (Note: this post intentionally avoids this subject, but I do have a lot to say on the matter)
Alright, this video does prove the initial state is possible on real hardware at poweron (as I was afraid after making some of my own experiments).
So, let's discuss implications then.
I am claiming that this submission should be treated as a savestate-anchored movie.
There's no difference between initializing mapper registers via movie tags or via a single "savestate" tag.
To show this I've made the FM2 movie:
http://tasvideos.org/userfiles/info/10117227735638386
This movie begins from a savestate, which is almost identical to the default state used for replaying normal TASes (those not beginning from a savestate). Namely:
* PC points at RESET vector, which means the game starts from the usual poweron routine
* other CPU registers have default values (to ensure this, I've paused the emulator, issued a Poweron command and then created the new movie before unpausing)
* RAM is filled using the standard pattern "00000000FFFFFFFF"
The only value that differs from default is the value of mapper 228 registers, which I modified according to Adelikat's instructions in the submission text (taking into account the difference between FCEUX and Bizhawk implementation of mapper 228). I can elaborate on the details if needed, but you can be sure it is the same as in the BKM.
Since the FM2 uses exactly the same initial state as this submission, such a playthrough of Cheetah Men II was possible from year 2004. Except back then there were more strict rules, because people were trying to keep the image of TASing as clean as possible, so movies starting from a savestate were not accepted (personally I would accept them to Demo tier or maybe even Moons, but definitely not to Vault).
So, this submission is not any more legitimate than my example movie. Using those new tags is just a way of hiding the fact. The site immediately recognized a savestate in my movie and added a special label. I agree with making such a clear distinction, but a similar label must be added to movies such as this submission. And such submissions should not be considered normal TASes. As in, they have to be of some value, other than being a record. If they are entertaining, the acceptance is justified, but if they are only interesting to author and not to wide audience, the acceptance is not justified. Unless the site dramatically changed priorities since 2004.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
ProcyonSJJ wrote:
Some thoughts on that: I definitely like that idea, since I think it would yield considerably better results, but I can't imagine that would be cheap. You'd have to query the color of over 65k pixels, tally them, and then identify the one with the highest count.
No, it can be very cheap. You see, the pixels are not in RGB, they use indexed colors. So you can just create an arrayColors[256], then every frame you first clear the array, then loop through all 61440 bytes of XBuf (in PAL, in NTSC there will be only 256x224=57344 pixels) and increase the arrayColors[XBuf]++. There, you have the array of weights, findmax and here is your color.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
kuja killer wrote:
oh thank you for the comments, been waiting for at least just 1, from someone.
Well, there would be more comments if someone posted an encode.
kuja killer wrote:
The only oppurtunity to ever do a zip was halfway through Doc Gemini with Rush Jet on those little bubble fish, just like the original megaman 3 in gemini.
Yes, good that there's at least one wallzip, it immediately makes the movie feel on par with other Megaman TASes.
kuja killer wrote:
im currently redoing this whole TAS all over once again, i started after needleman (screw his damn AI im not bothering with that) -- and i currently have 75 more frames so far to the start of Doc Shadow, 8 of them from less lag
OK, I'll be waiting for the new version on Workbench. Try to add some more variety and entertaining stuff, like clever usage of weapons.
Just watched the movie, looks pretty good, despite not much of wallzipping. :) Well, in the course of recent decade there were so many good Megaman hacks that my expectations were a bit high (especially after Minus Infinity). This hack doesn't seem to stand out by any unique mechanics or stylish level design. Even the music doesn't match the pace of gameplay. But the increased speed surely makes the movie look engaging at some points (namely those where you bring rampage while flying around). Unfortunately, sometimes it just looks like playing at 200% emulation speed, which makes watchers lose a sense of involvement. I mean, the apparent "turbo speed" emphasises the fact that we're looking at a recording which is bound to end with a happy end.
Good thing you were able to showcase different weapons (or was it speed-entertainment tradeoff?). Overall I think you should try submitting the run to let more people see it. If it gets enough support it might be published.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Bobo the King wrote:
6) The algorithm needs to be improved. I plan on changing it to a method that completes the process in four shorter steps.
That another algorithm sounds interesting. The current one is way too straightforward. But the main problem with the idea is that user has to actually spend manual work searching for those golden RAM addresses. I dunno if I'm too lazy, but the task of minimizing input doesn't seem important enough to figure new addresses for every game, especially since the script only reduces duration of buttonpresses and doesn't minimize the number of times the button state was changed. Maybe, if the performance of the script increases (after implementing the better algorithm) you could spend the processing power on comparing screenshots and thus not always requiring RAM addresses (sure, optionally providing them would allow the script to finish faster).
Bobo the King wrote:
I expect programming this will take a while...
Regarding the development, I suggest using TAS Editor's Lua API, to make the algorithm prototyping easier:
a) the API grants r/w access to input at any frame - use taseditor.getinput() and taseditor.submitinputchanges() instead of joypad.get() and joypad.set()
b) the IDE automatically savestates every frame (can be disabled when not needed)
c) the IDE visualizes the process of the algorithm's work (surely gonna be useful to debug the script)
http://www.fceux.com/web/help/taseditor/index.html?LuaAPI.html
But yeah, since TAS Editor puts some performance overhead, for the final script you may want to switch back to joypad.get/set. But actual making of the script will definitely be quickened by using the newer API.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
I've noticed on the video that you're drawing the whole 256x256 buffer of pixels, so sometimes there's black tiles at the bottom of the screen. You should only draw those scanlines that usual renderer of FCEUX draws, e.g. scanlines 0-239 in PAL and 8-231 in NTSC (in Windows version these numbers are customizable).
The Megaman example indeed shows the big problem with the current method of removing voxels. How about this idea: each frame you pass through the pixels array and find the color which the majority of pixels use, then use it instead of background color. This would probably make Iceman stage (and many other games) look decent.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Nach wrote:
There's nothing hasty about how I feel here. I've been complaining for nearly a decade now about the lack of documentation of initial states.
Is there a thread discussing this? One that would collect pros and cons of documenting the initial state in TASes. It's not a problem to implement (specifying the state was available long ago, see my savestate-anchored movie), but it's a matter of deciding which direction the site should take and which audience to consider.
Nach wrote:
If there's only one initial state allowed for something, the emulator should enforce it. If there's multiple, the emulator should allow the user to set the possibilities, or use rand().
That's it, between these two alternatives you would choose forcing the user to set values, while I would choose rand(). I'm saying "forcing him" instead of "allowing him", because we all know: missing an opportunity is not an option in TASing.
In a way, emulators already use rand() now, if you remember this picture: http://xkcd.com/221/ The returned state is random enough in that it doesn't correlate to player's wishes. Unfortunately, it can't be truly random, as this would make TASing impossible.
Nach wrote:
If the game was designed with hamming codes at every level, extreme regulation on all aspects and so on, giving the sense it was defensively programmed against such issues, implying they are part of normal operating conditions, then that would be an entirely different story.
Yeah, it would be called "software testing". That's what I meant by the technique being irrelevant to TASing.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
CoolKirby wrote:
Perhaps it can be achieved through hard resetting on a certain frame?
Frame-perfect reset is obviously not enough.
I thought an instruction-perfect reset could do the trick, but this way I could only begin from level 2. It seems that using only subframe resets is not going to be enough, in addition it's necessary to improve the accuracy of mapper 228 emulation (but who needs this crap???).
Try playing with this script, maybe you'll be more lucky than me.
Press "A" key to issue a reset at a random instruction of the next frame.
If you ever happen to appear at level 3 (5), you've hit the jackpot.
Download subframe_resetter.lua
Language: lua
resetAtInstructionCount = -1;
numberOfInstructionsAfterVBlank = 0;
function checkAfterEveryInstruction()
if (resetAtInstructionCount >= 0 and debugger.getinstructionscount() >= resetAtInstructionCount) then
resetAtInstructionCount = -1;
-- simulate subframe CPU reset
memory.setregister("pc", memory.readword(0xFFFC));
--debugger.hitbreakpoint();
end;
end;
memory.registerexec(0x8000, 0x8000, checkAfterEveryInstruction);
oldKeys = {};
currentKeys = {};
while true do
oldKeys = currentKeys;
currentKeys = input.get();
if (currentKeys.A and not oldKeys.A) then
numberOfInstructionsAfterVBlank = math.floor(math.random() * 9000);
resetAtInstructionCount = debugger.getinstructionscount() + numberOfInstructionsAfterVBlank;
end
gui.text(10, 10, numberOfInstructionsAfterVBlank);
emu.frameadvance();
end;
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Nach wrote:
Once something is valid, why should I reject it?
Valid means that it is permitted by rules, but there's no written rule on the matter yet. And I hope you're not going to hastily add it without a proper consideration.
Nach wrote:
With the same token, the ultimate player will set the temperature in the room to just the right percent of a degree. They'll have the sun hit the console at just the right angle. They'll have the electricity to power the system primed to just the right frequency. They'll use just the right television. Presto, they turn on the machine, and the audience sees the exact starting state the perfect player wanted them to.
Hm. I thought the superhuman is not supposed to bend the reality around the game, because it would be the same (or even more far-reaching) as modifying the console.
So, can he also affect how the light reaches the audience eyes, and therefore add some effects and other inexistent content to the game's output? Does he even need to play the game when he can just manipulate the audience to believe it was played?
I think your definition is much wider than the traditional image of TASing. It gives TASer an inadequate amount of power which is then used inconsistently and inefficiently.
But it doesn't answer my question. OK, so he can control the electricity and the sun, and he already used it to write the needed data into RAM at poweron. Why doesn't he use the same fine-tuned electricity outburst to write another value to RAM while playing?
Previously I thought the line was at having full knowledge and controlling own body optimally (omniscience + reflexes). Claiming something beyond the necessary minimum was prohibited, e.g. no unlimited resources (1-coin TASes of arcade games), and everything must be justified (e.g. a movie must be extremely entertaining or novel to be able to start from dirty SRAM). But your new definition really makes things more difficult to shape...
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Good addition, Nach, I didn't elaborate on the propagation aspect (only mentioning "certain patterns in schematics"), because I didn't want to focus on the technical part for too long. There are certainly other missed aspects which further decrease the entropy of the system.
But anyway, can you tell me, why would you accept a movie which requires an uncommon initial state (proved to be possible under specific conditions)? Don't you think that creating these confitions is a part of replaying such a movie? As in, the superhuman has to either manipulate the hardware or spend real time waiting for those conditions to happen (thus making watchers wait for eons)?
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
MESHUGGAH wrote:
"Goofy" values and "bizarre" words means (for me) that nobody knows exactly which but "some possibilities should work".
So, does all combinations could be possible for initial RAM state or there are values that doesn't ever happen to be?
This is not a question of electronics, it's a question of physics, so you'll never get a definite answer, because all models are crude.
Here's a layman's explanation of what "goofy values" mean.
In general, state of a trigger circuit (the basic component of RAM) at poweron is undefined, so the value can be either 1 or 0. But because of certain patterns in schematics, the initial value always gravitates towards 0 in one case and towards 1 in another. So it's not like the value of e.g. the byte #1 can be anything from 0 to 255 with even distribution of probabilities. No, the value will be 00000000 in 98% of cases and maybe 00000100 in 1% of cases, other cases take the rest.
So, chances of getting a "00000000FFFFFFFF" pattern are very high, the probability of getting "00010000FFFFFFFF" is still high (you might get it after a dozen of tries), but the probability of getting "0123456789ABCDEF" is vanishingly small and maybe even zero - you'd have to switch power on and off for billions of years to check it.
But my point in this entire argument wasn't about physics, it was about the philosophy of TASing. The proverbial superhuman may have amazing reflexes and a quantum brain to predict RNGs, but he doesn't have the right to mess with the console RAM/registers/etc directly. Instead, his playthrough will depend on the initial state, and each time will be perfect within the given conditions. In our case the conditions were given by emulator authors without a bias towards a specific game or a specific TASer.
Even if the superhuman is actually able to manipulate electrons (which is unrealistic and overpowered to no fun), he must still only use the controller, by definition. Or else TASing loses its point, because once he affects electrons at the beginning of the movie, why doesn't he affect them in the middle?
This should probably be discussed in a dedicated topic, but honestly I'm already tired of this and don't want to enjoy yet another round.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
ProcyonSJJ wrote:
1) I realize now that the resolution of the window is determined by the X and Y scales in the configuration. The only reason I've been testing in a 1024 x 768 window is because I had X and Y set to 4.0 and 3.0 respectively. That may not be ideal for viewing the voxels, but I'm not sure what else to base the window size upon. AnS, do you have any thoughts about this?
Ideally, the window should be freely resizable (also don't forget about saving the size/camera angle/position and other settings to config file). Something like 1024x896 (considering 256x224 as a native resolution of NTSC NES) sounds like a good default value, but users should be able to both increase and decrease the size.
ProcyonSJJ wrote:
3) The aforementioned issue with the lighting and general look of the voxels, but my hope is that once the code is released into the wild, someone with more OpenGL experience will be able to enhance the look of things.
Well, I wouldn't rely too much on the help. To get people so interested in your project (up to the point of contributing), you have to make it already valuable from the initial release. So I suggest adding a bit of polish.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
Wow, in search for excuses to use a sneaky technique which is irrelevant to TASing, we're now using some gossips as a proof. What has science done.
Also, wait, didn't the guy actually beat the last boss on this video?
Link to video
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(723)
Joined: 2/23/2006
Posts: 682
adelikat wrote:
Not true. The point is that you would have to attempt to run the bot many times before it finally worked.
Doesn't NESBot require starting from console power on? At least the movie does.
Youtube videos make it look like you have to first let the game run for some (small) time and then reset at a very specific moment - perhaps exactly while the game is writing data into mapper port.
So, simply switching NESBot+console on at random occasions won't do the trick.