I've been looking at the sample lua scripts to get an idea of how to write it (I really see how I can use this in some of my future projects) Its nothing too different from Java or C++.
However, some parts of it seem fuzzy for me. Just to be sure I get the basics of it, how would the general syntax of these two look like (with Desmume 0.9.5 as the emulator):
While a certain memory value is 0, press "right" and X
Keep advancing one frame until a certain memory value is 1, then have a save state at that point.
state = savestate.create();
while true do
if memory.readbyte(0x1234) == 0 then
joypad.set(1, {"right" = true, "X" = true});
elseif memory.readbyte(0x1234) == 1 then
savestate.save(state);
emu.pause();
end;
emu.frameadvance();
end;
Actual code may vary, but that should be more or less usable.
Setting the speedmode to normal (regardless of previous settings) will make the message pop up. Use a variable to track what it was last set to, and only set it if it changes.
As for why it doesn't change back, I can't begin to guess.
Could you post your test.lua script?
Bisqwit pretty clearly indicated that this was the script he was testing:
Home
About
Movies
Submissions
Staff Contributors
Articles
Game Resources
Emulators
Forums
News
I would remove the News (in the forums already and on the front page) and Staff tabs, replacing the latter with Contributors (players, editors, etc).
How well do emulators really emulate what happens when you reset while the game is saving? Is it a 1-to-1 accurate simulation of what would happen in the real hardware?
No. And it never will be.
The problems that arise are plentiful.
First, the emulators tasvideos uses (and most in general) allow input only once, then execute a full emulation frame, then take input again. Example: it would be theoretically possible to freeze SMB3 by changing controller inputs within microseconds, just enough for a CPU cycle or four to pass. The game reads the controller input repeatedly and only continues when the last two inputs read match (to compensate for a hardware issue involving PCM). This could be seen if you use a debugger to change the values read for "controller input" before these checks are made.
Applying this to SRAM, it is easiest to visualize it as a printer. The printer begins printing a document (saving). You are only allowed to turn the printer off between pages (frame delays). This means there is a lot of potentially valid time where you could turn it off and cease the operation, but you are prevented from doing so. When using real hardware, you are not prohibited from this whatsoever; cutting power will make the hardware stop immediately.
What makes "accurate emulation" impossible is that power fluctuates, and cutting power to a device does not necessarily mean that it will cease operation immediately. The magic of capacitors and other such things can mean that several more CPU cycles will be completed before the system fully shuts down, making what is already a microsecond-based operation even less accurate.
The only cases in which emulation is accurate is when the game has a forced pause between writes that is sufficiently large, for example the end of one frame and the entire next two frames. As these pauses in constant writing decrease, the resolution of reset timing to save data written changes drastically, and you begin to see far less predictable results on the actual hardware.
In a short summary, save interruption will never, ever be 100% accurate to hardware (unless it is a software reset like A+B+Sel+Start for some games, but most disallow this while saving anyway). However, the effects are theoretically possible on actual hardware, even if extremely unlikely.
Here's hoping this post was informative.
The guy's following the rules. If you have an issue with it, upload quality content and tell people about yours instead. If people like your video style better than someone else's, they'll subscribe to you instead.
This has to be the most pathetic pissing contest I've seen yet.
Lua coordinates over 255 won't work regardless of whatever the screen's resolution currently is.
gui.text(255, 10, "now you see me");
gui.text(256, 10, "now you don't");
Draw boxes and shit on screen, hit F12, get a clean screenshot without anything on it.
Also for the love of God please introduce a "Reload Lua script" hotkey or something
Many of my bots on FCEU have breakpoint handlers such that if the CPU happens to execute e.g. ROM location A56C, the value of the CPU register A can be captured into a variable, and used by the bot. This can be used to determine various things, from success in performing a glitch, to identifying an item that was just picked up.
Now, how do I do that in FCEUX and LUA?
(I've presented this question years ago and it was without a solution back then, but I imagine emulator technology has improved by heaps since then!)
EDIT: It indeed has! Congratulations to all programmers. So, replying to myself for others' benefit:
Wow, registerexec exists now? Wonderful, given that's the only way to tell what a game is doing sometimes.
I need to check if some of the other functions still maim FCEUX.
we've only had this discussion about 27 times, I figured reading the same thread with all the same ideas that'll never actually get implemented would be a bit redundant
"how is that fair" is solved by moving towards inclusionist, i.e. publishing good runs of any game regardless of the actual game's quality or fitness for a "speedrun"
but trying to argue that idea on tasvideos is like trying to make the titanic not sink
why not provide bounties
you know, maybe some $ in exchange for a publishable obsoletion
let people give the owners $xxx, then $xxx - 10% (used for the server as a "donation"/fee) is posted as a bounty for obsoleting or creating a certain movie
though this would inherently require somewhat more inclusionist rules for tasvideos so whatever
I don't see how it's "embarassing", given that at the time most of these movies were pretty comparable to what you'd see back then
why not just add a note in the video description that the movie is fairly outdated? better than having a ghost publication obsoleting 27 different movies.
You can only get it the "first time" you play the level. Let's say you get the 1up in the first level, if you die it won't appear the next time. You'll have to be game over first in order to get it again.
More generally, the bonus 1up will always appear the first time you play 1-1; for the other -1 levels it will only appear if you warped there or if you had collected all of the coins in the previous -3 level: http://www.themushroomkingdom.net/smb_breakdown.shtml
That claim looks very suspicious. I think we'll need to do some Source Diving to figure out this one.
There is a specific amount of coins that must be collected in the previous, but it isn't "all of them".
The coin requirement is ignored if you warped to that level ...
Hidden1UpCoinAmts:
.db $15, $23, $16, $1b, $17, $18, $23, $63
...
lda CoinTallyFor1Ups ;check third area coin tally for bonus 1-ups
cmp Hidden1UpCoinAmts,y ;against minimum value, if player has not collected
bcc NextArea ;at least this number of coins, leave flag clear
inc Hidden1UpFlag ;otherwise set hidden 1-up box control flag
To explain a bit further, a few levels have one or two more coins than on this list, so you can theoretically miss one and still get a 1up in the next world.
The guy's following the rules. If you have an issue with it, upload quality content and tell people about yours instead. If people like your video style better than someone else's, they'll subscribe to you instead.
This has to be the most pathetic pissing contest I've seen yet.