Thanks for going the extra mile and finding that decimal/hexadecimal confusion pattern. Was a bug in hex cheats, which the freeze system uses for its implementation. Fixed in r6046
In neshawk right now it's 514 in order to pass a test, which must be dependent on it being on an odd CPU cycle, according to nesdevwiki. Anything dependent on this timing I would not trust until it's been fixed properly to depend on the even/odd state
Have you bound your joystick as "A Up" or through the analog controls tab? If youve bound it as digital (turn on the input display and check for all 127's) then goemon will be skidding whenever he changes directions abruptly. It's working fine for me with analog controls bound correctly.
I'm sorry that those processes stay running. It's my bug and my job to fix that and I havent done it yet. But I dont think that made your crash happen. It could grind your cpu into dust.
Sorry, you're wrong. Scripting is core and integral to many applications designed to get work done and facilitate creativity, as emulators are. It's so people can do experiments without mucking up the source code and having everyones experiments stomp on each other eventually.
Experiments carry a cost when checked into the source code. They bitrot and create dependencies, increase bloat and build time. They slow down development by leaving hooks in things even if there arent very many hooks.
Of course, some experiments can only be done in the sources and those are what forks are for....
I can't really respond to the rest of this, except to say that I don't have time to figure out how to be nice since it doesnt come naturally to me and I am already booked 16 hours a day for the rest of my life working on things to make people happy. I think I'm being nice when I help you get work done, which I am, to the best of my abilities, whose quantity might be debateable. Thats the only kind of nice I know how to be.
Mustard-cutting and inefficiency are technical evaluations. It's nothing personal.
You might not understand what's going on if you dont have much experience developing software collaboratively. If you're interested in the health of software instead of just jamming your toy in it, youll listen to the people that have invested hundreds of hours of their lives (feebly, perhaps, trying at least) cultivating it, when they tell you ways you too can contribute to its healthy growth. We can't all jam our toys in the same box, eventually it'll bust open. We have some experience judging which toys fit and which toys dont.
Now that I've thought about it more, I'm very interested in the possibilities of blasting framebuffers over TCP to external programs for post-processing. That could be a useful tool and would profit from baking-in to the emulators.
one could always ABORT!! and use lua to dump the framebuffer to a socket and do the visualizing in an external tool. I think this would more likely be due to the difficulties of getting GL contexts working in lua from various emulators and platforms. assuming anyone's ever done it even under hospitable circumstances.
anyway, if fceux were hosted in git, you would have already been doing it as a fork because thats the way everyone does everything.
edit -
I just got a iupGL and luaGL demo running in fceux in windows (but I had to mod FCEUX sources a little due to some confusion about whether we're static linking libraries or using dlls. it seems someone decided to change us to using lua DLL, but we're still static linking to some old libraries. thatd need sorting out.)
the luaGL is sort of an old model that doesnt support shader, but does support client arrays and index buffers. should be possible to produce some faster approaches.
maybe someone's made a better lua GL binder, but using openGL is excessively complicated nowadays and I doubt anybody's trying to do anything real cutting edge with it in lua...
If you want to add a third arm to a man, go ahead. That's cool. If you want to give him infra-vision, do it. Want to triple his memory? These all make sense. Don't bolt a fully-automated mini marching-band jukebox to his back. It doesn't belong. If we commit your voxel stuff, then we'll commit the next guy's minesweeper clone?
I looked at the voxel code which was checked into the trunk instead of the branch so that I could judge it. Whatever difference in computational speed between lua and c++ there would be is dwarfed by the relative inefficiency of the opengl approaches used.
Also, you didnt actually put a license on the source code. That's not acceptable for FCEUX; it needs to be one of MIT or zlib or GPL.
I get it. You want to make something cool and contribute. This doesnt cut the mustard. If you do it through lua and discover deficiencies in the communication from FCEUX then we'll address those and youll be performing an actually useful service by encouraging the development of things which _cant_ be done in lua right now, so that in the future they can. If you prove that lua can do opengl visualization, you could open the gateway to some seriously cool stuff.
there are lua opengl bindings. anything lacking with respect to emulation or emulator introspection wouldnt be hard to add to the lua implementation file and would actually be of further use to other people.
Its possible that the ring buffer method will dysfunction on systems with less than 4 cores. I probably should have wrote that in the config box.
The ring buffer method causes bizhawk to go into a busy loop doing rx/tx to libsnes. Libsnes will be running on its own thread. You'd have to have at least two cores for this to work without total failure. Then, bizhawk is polling its input in another thread; and lately, rewind runs in its own thread if you tell it to. So you can see, there might be trouble.
It is a performance increase for some people. It depends also on how fast the game is running. It has different characteristics at different framerate. Theres also some related optimizations which havent been done yet.
I share nach's enthusiasm for discovering whether this can happen with power cycling instead of just reset, and am dismayed that it took his dedicated skepticism to discover someone we were using as evidence mumbling about demoing it with a hacked rom file.
However, if it can happen on an actual cart, via power cycling, I don't care what initial register state is possible vs which was used. We'd know its possible to get a certain outcome from certain hardware, so we have to emulate that as best we can. Maybe the IC is in some glitched metastable state. Emulating that faithfully isnt even sensible. But emulate it we must, as best we can, and if that means by arbitrarily selecting startup values that match known behaviours (as we do for RAM) then so be it.
Regarding this cart being hand manufactured and the possibility that various carts supposedly identical could be acting differently, I think ordinarily I would suggest as an acid test verifying a behaviour on two independent carts. However if all we had was a diversity of anecdotal evidence to rely on, it sounds sufficient.
Regarding meshuggah's suggestion to somehow study the NES ram startup state... first of all, thats been done by someone sometime I'm sure, and second of all, its meaningless. It's known to be bizarre, variable, and unpredictable, IIRC, and there is no correct answer. We select a pattern, deterministically, which is most advantageous for our purposes--which results in the fewest possible glitching games. This situation is already well-decided.
adelikat insists he had a video that was using the power button. I never saw it. I'm taking his word on it, but I'm very cranky about it. I still want to see it done by the power button. If it's possible via reset, I would prefer that we did it by reset. But if it's possible that it can be done by the power button, then I say we're forced to allow emulating it, even if reset is a better way.
Adelikat's movie uses the initial mapper register state only. The initial register state could be any nonsense on a crappy PCB. In fact, we did prove that it took zapping the mapper by proving that no initial memory state is used in the boot-up process. That's the opposite of what I said earlier. I'm sorry, I was confused in my last post. I'm not sure why we were talking about memory suddenly.
AnS wrote:
. Initializing these registers is the same as initializing CPU registers, which in turn is the same as initializing RAM.
Ah, here's why. Yeah, it's the same. But initializing RAM is a bigger can of worms. I'm glad we didnt do it, although technically, I suspect eventually we'll be forced to.
adelikat wrote:
I'm suggesting that a TAS need not work on all possible start up states to be legit, as long as it works on at least one possible state.
Define the TAS as a NESbot script, which includes the capability to power-cycle and check the results via a camera. Then, the TAS can work on "all possible startup states" by virtue of being able to align itself to its desired startup state.
Me and adelikat argued about this at great length. I eventually had to bless it.
Maybe some ram start-up states are possible, and some are not.
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 (I tried to prove it was possible just by making the mapper malfunction through repeated zaps, and failed)
The FF 00 etc. initialization state we suggest emulators use is proven as more or less possible, due to multiple games depending on it.
If anyone else can prove that another ram start-up state is possible, then I guess they could use it. I don't think I would bless anyone choosing a start-up state without some documentation that it's possible.. on some hardware (if someone's going to make a policy, they should probably specify which nes/famicom models count as real, vs clones).
"Well, it's technically possible for the RAM to start in any configuration, even DEADBEEFDEADBEEF" doesn't work for me without proof. Here, we have proof.
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 you ask me, NESbotability should be an ultimate decider in favor of legality.
I wish someone would try to reproduce this movie's trick by glitching the game into the right memory state and then issuing a reset. But adelikat wants to open a discussion, because we're the scientists of this stuff and who better than us?
Those hashes are weird. I'm not sure what they are. Theyre supposed to be typed.
I just made edits to add a info (details) view to the firmware options dialog so you can see which files the firmware manager is expecting and what their hashes are. This will make it easier to solve this problem in the future.
google the error message, seems like it might have been some compatibility issue between various svn implementations or versions. perhaps googlecode fixed things on their end
You should notice also that the file disappears when the codec selection process is done.
I'll be glad to debug a different stacktrace, if youve discovered the directx SDK can un-scramble your drivers. If you get the same stacktrace now with your new repro steps, then all youve done is paper over the real problem somehow by jiggling your files around a bit.
We shouldnt be depending on anything in the SDK. Maybe for some reason directx web update is malfunctioning on your system(s) but thats usually very reliable
bizhawk doesnt depend on any services or anything strange that the prerequisite installer doesnt install. windows codec subsystem is crashing, not bizhawk.
its strange that both your test systems have the same cpu. do they have the same motherboard and gpu as well? since some combination of hardware and drivers is likely causing your problem, testing two very nearly identical systems isnt the most valuable of tests.
I should mention, if you havent installed any video drivers at all, then youre either operating in a configuration that the codec suppliers probably havent tested, or youre using a default video driver which is as likely to have bugs with the codecs as any other driver. Perhaps on configurations where you havent installed video drivers, software opengl is getting used by the mupen core and thats hosing your codecs in a way i havent ever even tested. You'd know because mupen should be going about 1fps.
Possibly youre using a 16bpp or 24bpp desktop color depth? That's getting hard to support or test anymore.