Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Is there a specific version of Bizhawk I should be testing against here? The latest version does not sync the latest published Ninja Gaiden as described in the posts.
If you can, provide the BK2 you'd like me to test and point me to the version of the software to test against and from which I can extract button information for console verification.
EDIT: The input frames from the fm2 synced on real console.
EDIT 2: Scum pointed me to what I need, thanks. I'll write a script to verify the fceux-dumped input stream against bizhawk, and dump the desyncing run from bizhawk and verify against console. I'm not sure what will happen for the former, but I am assuming the run will not (de)sync in the same manner for the latter.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Sir VG wrote:
The save data isn't the problem for older games, but the battery that maintains them. Games that didn't use them (like Final Fantasy, for instance) the save will last forever, while ones like Pokemon (which did in 1st and 2nd Gen) die in ~12 years or so.
Final Fantasy uses a 3V primary lithium to retain contents. Current consumption to retain SRAM in these carts is less than the self-discharge rate of a primary lithium cell.
Primary lithiums tend to leak with age. It is not a bad idea to replace the 3V coin cell these used to prevent damage to the game PCB. Lifetime is expected to be 10-20 years, so you are certainly over the shelf life and on the lucky side.
It IS possible to read data out, replace the battery, then load it back in.
With care, it is also possible to attach a 3V PSU while replacing the battery to retain contents.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I'm extremely busy but want to provide information to find resolution to this, so I will try to verify this and see if the same desync happens on console, pre- and post-conversion. Give me a week or two, I should have things set back up to verify by then.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
It was in your list. Top of the list, in fact. I am mentioning that I have tried to verify every accepted TAS of this game and it does not sync...
Edit: I did not note nor suggest River City Ransom, other than to say the game does not sync. All I am saying the game does not sync. Can I be any more clear?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
The runs played by the robots are derived from the inputfiles, formatted for use with the respective console. In the case of NES and SNES for example, only the input frames the console asks for are sent to the console. Otherwise, it's what is recorded in the emulator.
The bot hardware differs. There are a number of NES/SNES robots, and few for other consoles. My current robots are on MIPS core MCUs and the firmware is written in C, and my next robot will have an ARM core and FPGA/CPLD. I sell my robots so others can replay runs if you don't want to develop your own. micro500's bots vary, being Arduino, Propeller (I think still C), FPGA-based, and so on. Others have made bots as well with varying degrees of complexity.
You can find some history here: http://tasvideos.org/TASBot.html
I guess we need to know exactly what you are trying or wanting to do?
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Unlike polled controllers on consoles, a PC keyboard works by sending scan codes to the host computer. There are codes for push and for release. Unplugging AT or PS/2 keyboard while holding down a key on a DOS computer would likely result in the key remaining "held" as no release scancode is sent - thus making end-of-movie equate to an unplugged state, which can be reproduced.
This should be confirmed.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Warp wrote:
True wrote:
Then don't buy them.
I honestly can't understand what your point is. You seem to be saying that it's a stupid idea to petition these companies to make a cheaper version of their product that would be more practical for the average gamer.
Yes, I believe it is. Go for it, but what do you _really_ expect you'll get? I think you'll get farther by making your own product.
Did you know the original creator of Oculus Rift did this very thing?
Warp wrote:
These VR headsets were from the very beginning aimed at videogames
No, they weren't. Most were designed for purpose-built applications, such as simulators. Those that were designed for games were _already_ cheapened significantly and were quite awful to use. Oculus Rift was an exception, as it was a quality HMD inspired for gaming use, but in later iterations it was discovered that there is _much_ more than gaming that a quality HMD could be used for - such as AR. With this "discovery" (or more appropriately "re-discovery") it was realized that the HMD alone was not the only part of the solution. Since then, there have been other gaming-oriented sets, but the creators of these also feel that their VR solutions _require_ some these other "useless" features. They aren't just targeting VR representations of existing games, but are trying to create new game genres, or even expand beyond gaming.
If you think there is a market for a product that the industry is not selling, do what the creator of Oculus Rift did. Create a product and compete.
Warp wrote:
Why do you oppose the idea of petitioning them to keep it simple (and cheap)? Do you honestly want to pay $800+ for features that you will not be using?
I don't oppose it. But it would be like petitioning my neighbor down the street to pull his weeds. I could ask him, or I could get all the neighbors to sign a petition asking him, but it still just isn't happening. It's a futile argument. If it bothered me that much, I would be better served pulling his weeds for him. You would be better served looking at some already cheaper solutions (some of which have been presented in this thread), or if none of them suffice, creating your own product.
By posting a petition, you seem to feel there is a market for a cheaper, cut-down HMD. If so, and they aren't delivering, then create one, sell it, and support it. You might then have an idea as to why these are so expensive and no, it isn't just parts cost, in particular the AR-related gear.
Warp wrote:
Keep in mind that the industry does not agree with you about your requirements.
I don't even understand what you are trying to say with that.
Exactly what was said. Perhaps that's really the issue here - you are unwilling to see why your petition is untenable? But I won't stop you from living your imagination... good luck with the petition.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
I was going to chime in and stay "start a business / make a product" but Bisquit was far ahead of me with that post. So instead, I'll elaborate on points made in your previous post.
Warp wrote:
I am basing my opinion on demonstration videos and critical reviews
That's fine. You're free to start a petition as you have, but think about this practically: you aren't the first to have this thought and if you were, people aligning with your viewpoint don't exist in numbers. There maybe grumbling, but there is no large outcry. But let's say there's a missing market here. Start a business based on this opinion. If others feel the way you do, maybe you can get what you want and make some money.
Warp wrote:
While I recognize that probably the most expensive part of a VR headset is its display, I still think that these companies have spent way too much development time on the augmented reality features, which can be seen in the higher price of the device.
Then don't buy them.
Warp wrote:
And the major problem with this is that the augmented reality features are pretty much useless from a gamer's point of view
You may think so. I disagree. But how you have framed your argument, you are arguing your opinion as fact. I want to call this out.
(Oh, and what is "pretty much?" Perhaps you are admitting defeat already?)
But let's imagine you are right: perhaps, then, gaming isn't the primary goal of this class of product? Perhaps the industry intends with these products to, I don't know, develop the state of the art. Maybe it is to enable new applications for immersive AR. Maybe these applications have nothing to do with gaming. This doesn't disqualify your use case, but if the market is not delivering it, maybe you can do something more substantive about it?
As a tip: this has been done before. While not as immersive as today's technology, each time, it failed in the gaming space. Research and creativity dominate gut opinion on these products today. If you aren't interested in what's out there, and seriously feel a niche isn't being filled, create a product that fills the niche.
Warp wrote:
My petition is for them to develop a more bare-bones version, a version optimized for practical games, existing games (such as Half-Life 2, the Portal series, the Doom series, and so on), which would hopefully be cheaper for the end consumer. We really don't need the ancillary augmented reality stuff. Stereo vision and head tracking is enough.
Keep in mind that the industry does not agree with you about your requirements.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
The setup time hasn't really been the computer side, except in cases of very custom stuff that a "custom computer" wouldn't solve. It's really more the physical aspect of moving equipment, making sure everything is talking and nothing is damaged, and so on...
We already have bots to do NES, SNES, Genesis, SMS, Gameboy DMG, GBA, N64, and more, but you are welcome to join #tasbot on freenode and discuss any ideas with us.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
rchokler wrote:
I am nearly back to square one with my attempt to improve the run. It turns out that I overlooked a crucial detail about the game mechanic. The detail being that which enemies are killed and in which order, also affects the item drops. I noticed it when on entering the store, the "sell" menu showed only one gem and a few pieces of cloth instead of three gems.
Yes, I wrote a script that shows you what will be dropped (incl qty) in the future depending on kill order.
rchokler wrote:
As a result, along the current route, we pretty much must kill the zombies in the same order as in the winning AGDQ run, even though it sacrifices many frames relative to killing zombies in a different order.
Routeplan with my script. It's posted in the main PAZ thread. It might come in handy for other routes if you need items.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
dwangoAC wrote:
River City Ransom sounds interesting, it hasn't been tried yet.
It has. It doesn't sync.
Gyre wrote:
Battletoads and Legacy of the Wizard are both in the failures list.
Battletoads has known emulation errors. The 100% run gets to the vertical stage past the snake stage, but the boss behaves differently than expected. Improve emulation and this game may sync.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
That doesn't mean that such a robot can't manipulate luck, just that it can't do so presciently. Obviously the goal would be not be to read game state through a side channel (as in, anything not on the screen) to play as a human would, so in this case, the RNG would need to be characterized if it would be manipulated by the robot.
Also, TAS does not equate to "luck manipulation," which is merely one facet of creating a TAS movie. The first two letters of TAS are "Tool Assisted." So not only would this robot be related to TAS, it _would_ result in tool-assisted play which could result in TAS. Just because the input derived might not be submittable here doesn't mean it isn't a TAS.
Perhaps a different take on this robot: it could act as a trainer helping a human player by taking over their inputs and helping them escape trouble (not hitting any spikes for example - hold right for justice).
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
dwangoAC wrote:
SGDQ is for things that require less time.
Try to be clear, articulate, and REALLY clear with this statement on-air and, if possible, with some other public method before the event.
Raiscan wrote:
I would personally like to see a same-input, multiple games run. Perhaps the Megaman quad run?
And if one of the consoles has a faster clock than the other? Then it won't be so neat anymore, since they're visually out of sync. To do this most effectively would require modifying consoles. That, and MM4 won't sync at all, MM5 is in a pretty bad state, some bugs exist for MM6. MM2 is reliable, MM3 might be, MM1 is not.
If you can improve emulation so that all of these sync, then I would see what I could do about console clock timings and sync.
Gyre wrote:
dwango, do you have a feeling for what consoles will be supported by the bot for SGDQ? We talked about adding more features beyond the existing replay boards. I'm assuming NES and SNES is a given. How likely would it be to get other consoles that have seen verifications such as Genesis or N64?
NES = yes
SNES = yes, though datarate-limited for ACE exploits
N64 = yes, select games
GBA = somewhat; emulation is lacking
GB = not sure; probably, not sure of GBP capabilities. If needed and GBA target is acceptable I have one and can work on this, otherwise I need a GB.
DS = maybe nothing else except Brain Age right now
Genesis = no, haven't heard from the botter in some time and it was pretty unique. I haven't finished the reset sync mod (determinizing hardware mod).
SMS = no, been waiting over a year for someone to make a quick Wonder Boy run for me to test viability, also emulators do not emulate startup state correctly
PC = no, though making an AT, PS2 or USB keyboard input emulator / playback device should not be difficult
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
marzojr wrote:
True wrote:
Genesis is non-deterministic.
The only significant source of nondeterminism on Genesis are memory refresh cycles, which are poorly understood and not emulated at all (and may turn out to be deterministic with enough knowledge).
Also Z80 R register.
Also VDP/CPU clock cycle offset and VDP register state.
Also probably other things I can't remember or don't know about right now.
It can be made to be deterministic, either with a loader or with some hardware modifications. notaz posted in these forums about his project but didn't provide a ton of information; he was able to sync some Sonic games and Ecco synced with NO input modifications IIRC.
marzojr wrote:
The rest is lack of proper emulation
That's putting it lightly :)
Bus access timings and contention are poorly emulated, if emulated at all
VDP is poorly emulated
Probably much else as you described
marzojr wrote:
If the game is sufficiently "simple", these innacuracies will not matter much: if you can guarantee that the game will always finish a frame with "ample" time to spare, poll controllers during vblank interval, don't use computational time as a source of pseudo-randomness (directly or indirectly) and don't do anything too tricky in regards to timing, the game will most likely synch on console with relatively minor changes (say, removing all lag-frame input).
I would like to test this theory, but all the games I have that have runs available desync nondeterministically. If I had a copy of Ecco I would love to test your point. I've actually calculated some odds for SMS (by empirical testing backed by math) and Genesis (math) and IIRC Genesis was something like 1/1024 or worse for starting state to be consistent.
True wrote:
Previous TAS verifies were done with a loader and input file manipulation. Work needs to be done to improve emulation and strip away the need for a loader.
Look in the console verification thread for notaz posts. We also discussed on IRC. I can't remember the details right now, but it allowed games like Sonic which behave very nondeterministically on console (particularly during SEGA scream) to be more deterministically played back.
Doesn't this discussion warrant a different thread, or to be put in Console Verification thread? Genesis wasn't even discussed as a potential target, though admittedly for the original idea to succeed, other consoles will also likely need to be more accurate than listed now.
Nach wrote:
I think making such a thing is unnecessary.
What, computer vision robot? It's a neat thing. Is it necessary? No, none of this is necessary. Yeah, we can illegally run a ROM alongside a game and hope it doesn't go out of sync...or we (or I) can write an AI that beats a game unmodified, like K3, and can adapt this to other platformers. I could even have it press keyboard buttons mechanically :)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Before I begin, I will state that I think this idea is dumb. But I guess it will work OK for the intended audience. Hopefully a better idea is chosen. I'll help where I can.
This will almost certainly require some protocol adapters between some of the consoles, as mentioned. Thus our output protocols can be non-standard if it helps at all.
dwangoAC wrote:
Bare minimum, we can put the first NES controller port in Multitap mode which would be four bytes per frame
NES doesn't have this like you think it does. This is SNES only. If you want to act like Four Score, then we can emulate that hardware, but at that point you might as well do independent data per latch and disable DMC if it is used. This will require some tool development. (My robots don't support Four Score nor dynamic latch detection changing, though both can be added)
dwangoAC wrote:
Hopefully we can do something similar to Pokemon Plays Twitch where we polled 8 times a frame by taking control of the latch pin manually
Yes, this can be done, but it requires a game that doesn't use DMC DMA or disabling DMC DMA and having some sort of trigger to switch playback mode in the bot. Hopefully by then we can get a higher datarate as well since latchrate was a bot limitation last time.
dwangoAC wrote:
With over 18 months to go to AGDQ 2017
Date?
ais523 wrote:
The fastest possible data transport to a NES, therefore, is to use a controller with infinitely many buttons, and just read all of them (i.e. you keep sending "read 1 bit" signals forever and get a sequence of bits inbound). I believe this would actually work on hardware if you had a large number of official controllers and swapped which controller was in the port every few clock cycles; our hypothetical TAS superhuman might actually be able to do that. I'm not sure offhand what sort of data rate would be possible because the limiting factor would probably be how quickly you could store the bits in memory.
The problem with this is we are no longer acting like a normal controller, and we strive to act like official hardware in the TAS community - be it emulators or emulating controllers. But in addition there are several flaws: 1) Physically swapping a controller several hundred times a second is probably physically impossible (yes, this is a robot and it is virtual, but as I said, we try to emulate hardware very closely...) and generally, controller swapping shouldn't be allowed anyway; 2) Without a latch, a swapped controller will have random contents in the shift register at powerup, and this powerup occurs upon plugin; 3) There is likely settling time so we may need to wait - this will need to be verified in practice and against the datasheet; 4) Assuming the register has power already, without the latch signal asserted, the register will contain the values at the last latch.
I guess if we need to act like unofficial hardware for a demo we could, but for practicality, we use latches as a sync point of reference. This is particularly important with cycle-inaccurate emulators.
marzojr wrote:
Oh, yeah, I forgot to add that Genesis emulation (even GPGX, the core used in BizHawk) is not good enough to guarantee synch on all cases on console unless the game follows some very strict rules.
Genesis is non-deterministic. Previous TAS verifies were done with a loader and input file manipulation. Work needs to be done to improve emulation and strip away the need for a loader.
----
Another idea would be creating an AI for a normally multiplayer game, perhaps using computer vision or something. Or even a computer vision robot in a single player game, but in a race. (I already had an idea to make a K3 computer vision bot...) But this is getting away from TAS and more into general neat stuff.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
WST wrote:
It is worth to mention that I had Russian КТ819Г transistors, which also suited this purpose perfectly, but there was a little problem: their pinout differs from TIP41C, which was supposed to be used. I had no mood to redo the whole board because of that, so I just put MJE13007, as I do not have anything else in TO-220 package (except some other Russian transistors, but they all have E-C-B pinout, not B-C-E).
They're TO220 and you aren't heatsinking them, so...just put them in backwards...
But even if heatsinking, like you mention later, just bend it out of the way a bit, it'll be OK :)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
Etching is really clean for home-done work. As I sent to you personally though, Chinese fabs are so cheap today, home etching isn't very common anymore... but I guess you have to wait longer for those...
Now help us build some robots :)
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
The money glitch (or at least one of them) involves the Buyback feature being exploited with some (all?) firearms. Basically you are able to sell your firearms and then buy them back with the Buyback feature for free. This has been documented and tested. It's not like a quick overflow or anything like that.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
deogenerate wrote:
My sentiments exactly. I don't recall exactly what the rules state on different versions, but now that the competition is over, I would probably continue working on it if work moved to the original version over the AGDQ version because I'd rip my hair out over RNG otherwise. But again, I don't know if that's allowed now so I'll just keep on poking around routing shenanigans with everyone else for now.
RNG is still manipulable and isn't particularly difficult to do. The most important RNG target is drops and I've written a script to show pending drops - this can calculate future drops per enemy index as well if the script is extended. It just isn't as "free" for a TAS as the prior version, that's all.
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
If someone wants to run this, maybe this overlay will help with route planning by showing enemy item drop info. Shows both what the enemy will drop and what is actually dropped. Enemy RNG can be advanced by killing enemies, so route planning would need to figure out which enemies should be killed. This RNG loops every 16 kills.
paz_enemy.lua
edit: updated script to support more drop types, work with bird emu, fix bug in RNG calculation that resulted in bad values half of the time, remove overlays from NPCs
edit 2: forgot something, also it still didn't work, fixed bug and works on bird version again
edit 3: just want to point out, that if a drop says it is going to happen (example, sticks) but it doesn't, it just means that the quantity was zero. once quantity lookup is detected it will show you this info.
edit 4: quantity to be dropped information added
edit 5: added render offset loop, more prescience
Editor, Experienced Forum User, Published Author, Player
(68)
Joined: 1/18/2008
Posts: 663
The previous run didn't sync because a frame-floor didn't appear in one of the Wily stages. I'll try verifying this tomorrow and will edit this post with results.
