Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
CoolKirby wrote:
In BizHawk 1.5.3, when I make and save a RAM Watch .wch file with ColecoHawk or SMSHawk and then load it up again later, all of the data types reset to Signed (though their sizes are kept).
GBCHawk's RAM Watch gives this error when attempting to load a wch (but loads it anyway) and this error when you try to save said wch (but saves it anyway).
Also, in Atari2600Hawk, something I did caused me to get this error while trying to save a watch file and the wch did not save. I haven't been able to reproduce it though.
All these have been fixed in what would be a 1.6 release. For those reading this, a 1.6 release will feature GenesisHawk, but will disable TAStudio. If anyone was productively using that dialog (I can't imagine that being true), let me know, but for the time being it will have to be disabled.
The only reason it hasn't been released is that googlecode is lame and removed the ability to add downloads, we are waiting for a good solution for tasvideos housing the release builds. But I may release and host it temporarily on dropbox, if anyone has opinions, please discuss.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
I voted meh, overrall I liked it but it did drag a bit. However, I really appreciate you made this! More Coleco imo!
One suggestion though, there are times where you wait for a while for the "exit" to appear and go in, maybe you could move around a bit to keep the "dead air" to a minimum? Or maybe this causes lag or costs time in some way?
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
PJ64 makes no difference. We use mupen64plus, whatever it supports we can support. Would be nice if someone looked into this, especially before assessing what should be done about it :)
The connotation of "Forgoes memory corruption" is "Forgoes time-saving memory corruption" so perhaps the category should be changed to precisely that.
The reverse would be "Corrupts memory to save time" ?
Any tag with the word "forgoes" is the same intent. For instance, we are tagging time-saving death, dying as a way of playing around doesn't count. So there maybe other tags in need of a change
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
Warp wrote:
This means that this hypothetical being ought be able to somehow affect the initial RAM state of the console as the game starts. Is this even physically possible?
It doesn't mean that this superhuman and CONTROl the random initial state. He only needs to be unbelievably lucky. The super human turns on the NES and it just happens to start in the perfect configuration for his needs.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
I personally support the notion of a TAS being able to control the initial (and arbitrary) ram state. And I be willing to support the notion in BizHawk and convert this movie into a movie that does not need to start from savestate. At that point the only criteria that keeps it out of the vault is the Game show rule. And that rule was written to be conservative at first. Given the amount of complexity of this run, maybe at that point it would be worth seriously considering it.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
BadPotato wrote:
Yep, exactly. Just like when you press the stop button with your mouse.
Aren't you already in control of this? Simply exit the script and it will turn off. I'm assuming you are in an infinite while loop. When you want to "stop" the script, break out of that loop. I don't think you need to tell the emulator to stop your script, from your script...
waitToNext() to get the same thing as pcsx.suspend.
seems like you are on the wrong path to even be considering needing this, sounds like the equivlant of fixing a javascript error with SetTimeOut() (a function that is almost always used as a hack rather than its intended functionality).
You shouldn't be thinking in terms of milliseconds, but rather definable events in the emulator. If you can give me a valid use case that I can't argue as another event, then I'll consider it. For instance, maybe you are really just wanting event.onpaint() to make sure on screen stuff is drawn even while paused between frames?
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
This type of run has been asked for, for about the past 7 years. I'm glad someone finally made it.
About 7 years ago is when megaman TASes became so glitched that there isn't really any megaman gameplay left. It is a popular game and people actually wanted to see the game. However, once you remove the glitches and show the game. You show how mundane the TAS value is in normal gameplay. I found the movie's entertainment value mediocre and eventually predictable ("oh there's an enemy I bet he's going to run into it, and do the select trick. Yup, he did"). Constrast that to the glitch-full movie which is exciting, unexpected and one of the most popular TASes on the site.
I found this movie lacking, and so I voted "no" because I was not sufficiently entertained.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
I changed it to "low glitch" which is the convention for movies that avoid game breaking glitches while still doing minor time saving ones.
Imo though, this is glitchless.
I'm more concerned about the fact that this run actually does use glitches: pause tricks to prevent damage knockback and to reset boss invulnerability periods.
The first one you mention is a pretty clear cut case of a "trick", not a glitch. The 2nd I would argue as a trick too, I don't think it is unintended behavior that select doesn't freeze timers, and the trick simply takes advantage of that observation. But I would be willing to concede to a minority opinion on that one, but the first is clearly not a glitch!
Also, I very much agree with the glitch choices in the goals of this movie. And glad to see this TAS finally made.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
The problem with the past demo section was it was poorly defined. It was never clear what movies would qualify, or more importantly which would NOT qualify. As such, any movie that was facing a rejection was suggested as a demo.
For this tier to come into existence is MUST be clearly defined. Such that we could take a 100 movies at random and determine their eligibility with a clear consensus of opinion.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
BadPotato wrote:
I'll suggest a function like emu.quitscript(), to directly stop the script.
Currently, if you use multiple script(by using something like require'myscript'), you can't easily stop the script, despite using coroutine.yield() but this isn't a good pratice if the script already use coroutine for other means.
Based on this description, I'm not sure what you want built. You just want a script to be able to be in charge of stopping itself? couldn't existing the while loop do this?
Maybe I need an example of what you problem you are having.
Also, sometime you need somekind of realtime timer to perform specific task, without doing a "busy-wait" function inside lua. At some point, I did a pcsx.suspend(int cycleToWait) function to suspend a lua script(without suspending the whole emulator) for a x number of cycle, but there's probably a better way to do this.
In this example, what unit of time is a cycle? A cpu cycle from the core?
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
I've heard a lot of debate about which definition of 100% is the right one. Personally, I don't care which one gets used, they are all plausible enough, and none affect the entertainment value of the run significantly.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
I think it is not a vaultable movie, and bordline at best for moons.
It is fast and obviously inhuman, so it does have some "entertainment value" in the way that we look for when judging moons. So I vote meh.
I do think it does the bare minimum when more effort could yield a much better result. We think we would all would agree that an all modes movie would be much more impressive and entertaining.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
Sappharad wrote:
I'm disappointed that he's basically replacing vecna's attempt at C# cores with more native code
Nothing that has happened has to be permanent, the C# core is still in the code base. But the reality is that it has been 2 years since vecna has worked on his core. The reality is that most likely it is dead or won't be done anytime soon. We do need to look for alternatives. And G+ seems to be a great alternative.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
TheAngryPanda wrote:
I'm having this issue as well with a SNES game, manually adding the folder did nothing for me. Letting it generate itself by using the quick movie creation still didn't solve the problem:
http://i.imgur.com/ZNjIHD5.jpghttp://i.imgur.com/t3S3OnN.jpg
There's what EmuHawk's throwing as errors. If it matters, nothing is saved post-crash in settings, but the movie is saved at the frame is was crashed from.
If it matters, Vista 64, unfortunately.
This is unrelated to AndyPanther's problem. With SNES though, there's always the possibility of these kinds of crashes. What game is it? Some games are known not to work (it was a tradeoff, either we have sysnc stability or 100% game compatibility, but not both).
And congrats you found the new emergency save feature. The intent is if it crashes while recording a movie it gives you a chance to save (attempt to, obviously the emulator is in a state of crashing, depending on why it might not work). The intent is for the movie to save, not any other settings.
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
andypanther wrote:
Shouldn't the "Movies" folder also be written by Bizhawk if the first recorded movie happens to be made from a state?
As stated, you shouldn't be using savestate N64 movies in this release. I am working on a solution to this problem but it isn't trivial.
However, you did find a nice edge case there, if I have no movies folder, and do a starts from savestate movie instead of a regular one. I'll add that to the TODO
Emulator Coder, Published Author, Site Developer, Site Owner, Expert player
(3636)
Joined: 11/3/2004
Posts: 4758
Location: Tennessee
Robert_Ordis wrote:
Excuse me.
I have two questions about drawing by gui.draw○○ functions in GB mode.
1.Can I disable ClearType drawing on gui.drawText()?
I'm using "Misaki Gothic(美咲ゴシック)" which has bite-sized legible font.
But its legiblity is little perished if this font is drawn in ClearType.
2.How do I set timing of gui.draw○○() function to earlier than default ?
I think that drawing by gui.draw○○() function is delayed for 1 frame from gui.text() doing.
Here is a test code for the second question.
Lua: http://sdrv.ms/Je5K5x
And here is a result of this code.
Top left value is displayed by View -> Display FrameCounter.
Small sized letter is displayed by gui.text() (this value indicates framecounter).
Center big sized letter is displayed by gui.drawText() (this value also indicates framecounter).
capture: http://sdrv.ms/Je5Slm
gui draw functions are done AFTER a frame is emulated, it was decided that is the most logical situation. However, ram viewing tools require to be updated BEFORE a frame is emulated. gui.text() is a nebulous hybrid of those two, so it isn't 100% clear which place to put it, but it was decided to happen BEFORE. If you need gui.text AFTEr a frame, use the events library: event.onframeend() to register a lua function that performs this task.