Joined: 3/18/2006
Posts: 971
Location: Great Britain
It seems I have found the memory address for when a text-box can be skipped.
The value 001FFE4E becomes non-zero when a text-box can be skipped.
The only problem is that it is 1 frame late. So I need to create a script that can press Circle 1 frame before 001FFE4E becomes non-zero.
Can someone help me to accomplish this lua script?
I guess the script could see when the value becomes non-zero, load, and then press circle 1-frame before?
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Yep, it needs to save the state every frame.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
It seems I have found the memory address for when a text-box can be skipped.
The value 001FFE4E becomes non-zero when a text-box can be skipped.
The only problem is that it is 1 frame late. So I need to create a script that can press Circle 1 frame before 001FFE4E becomes non-zero.
Can someone help me to accomplish this lua script?
I guess the script could see when the value becomes non-zero, load, and then press circle 1-frame before?
X = savestate.create();
while true do
savestate.save(X);
emu.frameadvance();
if memory.readbyte(0x1FFE4E) ~= 0 then
savestate.load(X);
joypad.set(1,{["circle"]=true});
emu.frameadvance();
end;
end;
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Lil_Gecko wrote:
antd wrote:
It seems I have found the memory address for when a text-box can be skipped.
The value 001FFE4E becomes non-zero when a text-box can be skipped.
The only problem is that it is 1 frame late. So I need to create a script that can press Circle 1 frame before 001FFE4E becomes non-zero.
Can someone help me to accomplish this lua script?
I guess the script could see when the value becomes non-zero, load, and then press circle 1-frame before?
X = savestate.create();
while true do
savestate.save(X);
emu.frameadvance();
if memory.readbyte(0x1FFE4E) ~= 0 then
savestate.load(X);
joypad.set(1,{["circle"]=true});
emu.frameadvance();
end;
end;
Many thanks!
One more thing, the script makes the emulator run pretty slowly.
Would it be possible to add something to speed it up. I'm thinking that the script wouldn't need to save a savestate if there is no textbox on screen.
So could it not save a savestate when 00071E2C = 0
There's a textbox on screen only when 00071E2C = 1.
Would this work?
X = savestate.create();
while true do
if memory.readbyte(0x71E2C) == 1 then
savestate.save(X);
emu.frameadvance();
if memory.readbyte(0x1FFE4E) ~= 0 then
savestate.load(X);
joypad.set(1,{["circle"]=true});
emu.frameadvance();
end;
else
emu.frameadvance();
end;
end;
Perhaps emulator developers could study the possibility of making savestates a lot more efficient so that they could be done on each frame without affecting the emulation speed...
Joined: 3/18/2006
Posts: 971
Location: Great Britain
Lil_Gecko wrote:
Sure.
X = savestate.create();
while true do
if memory.readbyte(0x71E2C) == 1 then
savestate.save(X);
emu.frameadvance();
if memory.readbyte(0x1FFE4E) ~= 0 then
savestate.load(X);
joypad.set(1,{["circle"]=true});
emu.frameadvance();
end;
else
emu.frameadvance();
end;
end;
Perhaps emulator developers could study the possibility of making savestates a lot more efficient so that they could be done on each frame without affecting the emulation speed...
That's unlikely. You either have to copy the entire internal state, which is much slower than just modifying things as they happen in normal execution, or somehow work out what's changed since the last time you savestated, which will typically halve the emulation speed because you have to record everything in two places rather than one.
If the complete state of the emulated hardware were in one continuous block of memory, it could be quickly copied to another location and handled by another thread...
Joined: 9/21/2012
Posts: 11
Location: Northern Virginia
If there's one thing I learned from my forays into emulator development, even from the perspective of someone doing ports, it's that things are complicated for a reason. Optimizing for state saving probably would have costs elsewhere.
To add:
Since savestating is so suboptimal, I would create a savestate every 100 or so frames, then start a counter. When the frame is reached, reload the savestate and use the counter to advance frames until the button needs pressed, then start again.
This should make the program run magnitudes faster.
That's unlikely. You either have to copy the entire internal state
Which is what? Something like 2 kilobytes on the NES? Hardly sounds something that couldn't be copied around 60 times per second. (Even if we go to the SNES, it would be something like 128 kilobytes. Still sounds like an amount of data that can be copied around pretty fast.)
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
Warp wrote:
ais523 wrote:
That's unlikely. You either have to copy the entire internal state
Which is what? Something like 2 kilobytes on the NES? Hardly sounds something that couldn't be copied around 60 times per second. (Even if we go to the SNES, it would be something like 128 kilobytes. Still sounds like an amount of data that can be copied around pretty fast.)
When you reach the PlayStation we're talking ~4 megabytes of data.
When you reach the PlayStation we're talking ~4 megabytes of data.
So because the state of the PlayStation takes 4 megabytes, it's impossible to make a fast savestate routine for a NES emulator?
creaothceann wrote:
Internal status (maybe a few KB at most), 128KB WRAM, 64KB VRAM, 64KB APU RAM, ?KB SRAM, additional memory on special-chip cartridges.
Do you know how much data is processed by a typical modern computer game on each frame, at 60 FPS? (After all, we are talking about modern PCs, not PCs of the early 90's.)
Those amounts of data you are listing aren't much. They all fit into processor caches quite nicely, several times. Copying them around doesn't take much time.
I don't think it's the amount of data that's the problem.
Joined: 3/2/2010
Posts: 2178
Location: A little to the left of nowhere (Sweden)
Warp wrote:
Warepire wrote:
When you reach the PlayStation we're talking ~4 megabytes of data.
So because the state of the PlayStation takes 4 megabytes, it's impossible to make a fast savestate routine for a NES emulator?
You did not specify that you were talking about NES only. Besides, as far as I know, the script in question is for FFVII on PSX, hence the PlayStation factoid.
I don't think it's the amount of data that's the problem.
Just wanted to make the "something like 128KB" a bit more correct.
Btw. wouldn't it be easy for a developer to find out how much time saving a savestate takes? Might be useful to know for this discussion.
