Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
deltaphc wrote:
from Lua, Gens doesn't allow you to load a state without redrawing the screen. So if I were to load a state afterwards, it'd just bring me back to where I started (if I'm understanding it correctly).
Loading an anonymous savestate does not redraw the screen. (If this is not true for you, then it's a bug that I have never seen happen, and I could use an example to reproduce it.) Furthermore, loading non-anomyous savestates can also be forced to not redraw the screen by using speedmode("maximum").
EDIT: In case anyone is confused about this and would like to become either more or less confused, you might want to read this.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
DarkKobold wrote:
Aqfaq wrote:
How about a random input generator?
That is easy.
...
Here's a condensed version of yours:
local buttonmap = {[1]='up',[2]='down',[4]='left',[8]='right',[16]='A',[32]='B',[64]='C',[128]='start'}
gens.registerbefore(function()
local temp = math.random(0,255)
for bit,button in pairs(buttonmap) do
if AND(temp,bit) ~= 0 then
joypad.set({[button]=true})
end
end
end)
And here's one that makes it easier to adjust the chances per button:
local function setbuttonrandomly (button, chance)
joypad.set({[button]=math.random()<chance})
end
gens.registerbefore(function()
setbuttonrandomly("right", 0.7)
setbuttonrandomly("left", 0.1)
setbuttonrandomly("down", 0.15)
setbuttonrandomly("A", 0.2)
setbuttonrandomly("B", 0.1)
end)
Finally, here's a simple macro-playing script (somewhat stripped-down but probably already close to being usable):
-- define a macro to jump right from a standstill faster than normal
-- (at least that's what it does in Popful Mail)
jumprightmacro = {
{B=false,right=true}, -- frame 1, hold right and don't jump yet
{B=false,right=true}, -- frame 2, hold right and don't jump yet
{B=true}, -- frame 3, actually jump
{right=false}, -- frames 4-8, don't press right
{right=false}, -- (anything else is ok, but right would
{right=false}, -- slow you down if pressed anytime
{right=false}, -- during these frames)
{right=false},
}
-- more macro definitions like that would go here...
--spindashmacro = { {down=true,left=false,right=false}, {down=true,A=true}, {down=true,B=true}, {down=true,C=true}, {down=true,A=true}, {down=true,B=true}, {down=true,C=true}, {down=false} }
-- this function advances 1 frame (fast) during a macro
function doframewith (buttons)
repeat
joypad.set(buttons)
gens.emulateframe() gens.wait()
until abortmacro or not gens.lagged()
end
-- this is the function to start playing a macro
function domacro (buttonseq)
abortmacro = false
for i=1,#buttonseq do
if abortmacro then return end
doframewith(buttonseq[i])
end
end
-- cancel the macro if I load a savestate while it's playing
savestate.registerload( function(statenumber)
if type(statenumber) == 'number' then
abortmacro = true
end
end)
-- play the jumprightmacro whenever I hold Ctrl and Right at the same time
-- (could use registerhotkey instead, or a clickable button, or whatever)
gens.registerbefore(function()
if alreadyin then return else alreadyin = true end
if input.get().control and joypad.peekdown().right then
domacro(jumprightmacro)
end
-- more checks to do other macros would go here...
alreadyin = false
end)
It starts getting more complicated fast if you want it to support things like layering macros on top of each other, continuing the rest of a macro when you load a savestate that was saved before it finished playing, making the macro playing context-sensitive to what would be useful to do in the game at the time, or allowing recording macros without changing the script, but those should all be possible to add on.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Could you list that out in more detail? Like which emulator version are you using, which codec are you using, how big is the AVI getting, did you configure a split size, are you doing anything different when it works than when it doesn't work, what do you do at the end to stop recording, etc.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
RattleMan wrote:
EDIT: The forum isn't displaying a line of the code correctly
I think you have to make sure the box that says "Disable HTML in this post" is checked before posting something like that. (You can set it permanently in your profile.)
EDIT: here was my version of basically the same thing (S3K only).
gens.registerbefore(function()
local xvel = memory.readwordsigned(0xFFB018)
local yvel = memory.readwordsigned(0xFFB01A)
local sonicspeed = math.sqrt((xvel*xvel)+(yvel*yvel))
local bluramt = math.min(0.92, sonicspeed / 3072)
gui.drawimage(gui.gdscreenshot(), bluramt)
end)
I'm not sure it's really better to make it depend on Sonic's speed though. Maybe what it should be checking is how fast the camera is moving through the world.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I never mute the game's sound, since hearing it is really important to me for several reasons, but I usually listen to other music at the same time. I find that works best when the music fits the general mood of the game.
I used to type a bunch of frame counts into a text document with hyphens in-between so that I could copy any two of them and paste into calc.exe to get the time difference. Lately I've mostly replaced that with using Lua scripts that show visually how far I am from all the other savestates and from the other movie I'm comparing against (with some way of resynchronizing per level or per screen). There's often no need to time things out when I can plainly see which attempt is faster even while a new attempt is being made.
On the other hand, sometimes I have to stop and write down some equations and solve them before continuing, since I can't be sure I've gotten close to the fastest method otherwise. Probably not nearly as much as people that do RPGs and such, but sometimes it even applies to short-term goals in action games. For example, I found this in my notes: "SOLVE: find x and y such that 1303*x*y - 23*x*x*y >= 64640 with minimal ((x+1)*y)" [and x and y must be integers]. It was for figuring out the fastest way to jump up a ladder. I think 1303 was the initial jump velocity, 23 the gravity, 64640 the height of the ladder, x the number of frames to hold down the jump button per jump, and y the number of times to grab the ladder. (The solution revealed that the fastest way to climb the ladder involved making much shorter jumps than I would have guessed. Also, I wish I could remember the correct way to solve that sort of equation, instead of having to write a program to brute force it...)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Truncated wrote:
Another problem I had is also solved, but I don't see a change note for it. Is was that the Gens screen would be blacked out after the computer had been in sleep mode, which demanded restart, change of render mode or similar.
Oh yeah, almost forgot I fixed that. It also used to happen if you change between 16 and 32 bit color while Gens is open. In that case it still goes black for 1 frame, which you'll notice if Gens is paused, but simply unpausing fixes it (no need to change render modes). Also fixed is that, if for whatever reason you have hardware video acceleration completely disabled, Gens should still work (albeit with restricted available render modes).
One other thing I didn't see mentioned specifically in the changes: RAM search and RAM watch are must faster now (than in Gens10) so you can leave them open without the emulation slowing down much if at all. And the controls for what happens when left+right/up+down are disabled have been improved (holding left and right will go right, or holding right and left will go left).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
It looks like it keeps up to 100 savestates at a time, and they don't loop around (it simply discards the oldest ones, although I'd suggest changing it to recycle their memory). Also, they're not stored in the same save slots like 1-9 that the user can load, they're just savestate objects. The way it's written now, I think rewinding will simply undo savestate loads if you rewind through them.
By the way, I wish I hadn't made input.registerhotkey work like that. Using an existing "hotkey slot" was pure laziness on my part and creates all sorts of problems. It should add a new configurable hotkey entry with a default key press instead. Maybe in a future version...
EDIT: I assume the post after this is also referring to honorableJay's post instead of this one.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
DDRKhat wrote:
nitsuja wrote:
Also, now that there's Lua support it's entirely possible to write a Lua script that loops through the level's screens and dumps out an image of it.
But this would have the character actively moving at the period, would it not? So objects such as badniks (in this case) would not always be in the same location?
I don't think the C++ based maphack attempts to solve that problem either. It's not as much of a problem as it sounds because generally the game won't update things that are offscreen, so as long as you scroll through the level at a fixed speed then most objects will be positioned a consistently small distance from their starting positions.
But, I suppose the script could load a savestate before every screenshot to make sure that all the screenshots get taken at the same emulation time.
Also, depending on the game, there might be some way to pause the game without disabling camera movement. For some games that can be done simply by writing something to RAM, but even if that won't work, I believe you could tell the game to actually "skip over" the non-camera update code with something like this:
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
upthorn wrote:
for what it's worth, I'm using a bin/cue version of the game (only version I could easily find), not an iso+mp3 version, so deleting a track isn't a possibility.
That's probably why (although deleting a track is possible with bin/cue if you want to do it, I wasn't using that).
upthorn wrote:
It is loading from the cue file, and cd audio plays, but perhaps binary image redbook support is not fully sync compatible with mp3 produced PCM support?
The music format really shouldn't matter for sync, since they are both in exactly the same format by the time the emulation tries to use them. But we haven't proven that having lower-quality music resulting from MP3 lossiness can't cause desyncs (as unlikely as that seems considering the vastly different music tracks we've been able to use in Sonic CD without changing sync), and if the music format is different in your version, then it's possible that enough other things about the music and/or the game binary were also ripped differently enough to cause a desync. It's like using a different version of a ROM. I'd say the bin/cue version you're using is likely to be the more "official" one, however, and it's too bad this doesn't sync with both.
Your description of the desync sounds like what would happen if a single frame of lag got displaced around the transition to the screen with the acid pool, so I bet you could make the movie sync to the end with the occasional frame insertion/deletion.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
It (the "sonic maphack") is more of an old hack, I wouldn't call it newly-implemented... it's been updated occasionally but, yeah, you have to use it very carefully to get correct results and it's not part of the released Gens exe for a reason. It was really only for programmers that are willing to fully understand it.
Also, now that there's Lua support it's entirely possible to write a Lua script that loops through the level's screens and dumps out an image of it. Game-specific hacks in the C++ code are less necessary now. (Admittedly, heavy image processing is probably the worst example of what to move over to Lua, but it can be done and you'd have full control over what it's doing.) That goes for things like camhacks as well. If I were to make a new camhack for a Genesis game I'd certainly do it in a Lua script.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
upthorn wrote:
I'm getting a desync pretty early on. But I can't tell if it's at the title menu, or at the acid lake just after you get the whip...
He gets to the screen with the acid lake, then stands around for a while, and then just runs to the left and falls in the lake...
It played through to the ending for me and I'm also unable to reproduce that desync. Anything I try either causes a desync much earlier than that (like if I change the BIOS (away from 1.10), delete a CD track (needs 2 through 42), or turn off the perfect syncro option) or doesn't cause any desyncs at all (like if I change the BRAM size or change any/all of the sound options).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
DDRKhat wrote:
I also seem to have some bizzare issue. I've compiled this fine however when I run the created Gens.exe , whenever it applies a rendering mode (even when it's first loading up) it for some bizzare reason takes the entire width of BOTH of my screens.
The project should be compiled with VS2005, not VS2008. (They both have free versions available.) However, I would be interested in seeing a screenshot of this problem at the moment since your description is somewhat vague. (are you in fullscreen mode? is it maximized? can you resize the window to make it better? is it drawing outside of the window? does it happen with all the different render modes? what exactly does "whenever it applies a rendering mode" mean, does that mean it only happens while a render mode message is onscreen?)
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
You can turn on "Input Settings > Frame Advance skips lag frames" for this. (Assuming Gods has "red frames" normally.)
Just for fun, here's a way to make it always emulate 2 frames at a time regardless of hotkeys:
local oktocall = true
gens.registerafter(function()
if oktocall then
oktocall = false
gens.emulateframe()
oktocall = true
end
end)
-- you'd want to turn the speed down to 50% with this, for when you're not using frame advance
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
For some reason the Lua docs aren't in the zip with Gens11... For now, I put them here, for those who don't want to search through the source archive for them:
Gens Lua Documentation
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
First, I agree with Catastrophe that the best strategies for a human to do are not necessarily the fastest in a TAS, which means that simply minimizing total time like normal might make for an interesting TAS after all. It does seem like a long shot, but it's probably the first thing that should be attempted and it would help put everything else in context.
Failing that, I think we can come up with something better than forbidding the use of a particular set of abilities. How about using these priorities:
1: fewest battles
2: fastest time per battle that's entered
3: fastest time total
To further explain what that set of priorities implies: Because of priority #1, grinding on random battles is not allowed. Because of priority #2, wasting time in one battle to save time in a later battle is not allowed, but anything that can be done in-between battles to make the next battle faster must be done. Because of priority #3, wasting time for no reason in-between or across battles isn't allowed. Pretty much, these priorities guarantee "forward progression" without specifically restricting the use of any skills.
Alternatively, how about beating the game in a minimum number of turns instead of a minimum amount of time? A turn is every time any character's turn comes up, whether they're friend or enemy, even if they only move or wait on that turn. If acquiring the calculator would take a HUGE number of turns then that goal might be good enough on its own when coupled with time as a secondary goal, but if that's not the case, you could define your priorities in a similar way to the previous ones:
1: fewest battles
2: fewest turns per battle that's entered
3: fewest turns total
4: fastest time
These could all be called "arbitrary rules" of course, but I think having goals like "fewest turns per battle" is more defensible than arbitrary restrictions like "not allowed to use use skill X" or "not allowed to equip item Y" or "not allowed to press more than one button at the same time".
In a way, these suggestions are similar to how we aim primarily for "best in-game time" in some Sonic games, with overall time a secondary goal.
Of course, the opportunity to demonstrate surprisingly-game-breaking stuff is diminished with rules like these, but if we know exactly what that stuff is and that we don't want to see it because it's boring, then I think it would be justified.
EDIT: But really, if someone can find a way to make this game not boring to watch, that would probably be the biggest accomplishment right there and everything else could follow...
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Aqfaq wrote:
Do you know how or where it happened exactly?
Actually I think it was at that place where you have to flip a switch on the back wall to open a floor gate on the left side of the screen to drop the bad guy (probably shouldn't have called him a guard) into the pit. I guess I got the whip timing incorrect and started a death sequence that somehow got interrupted.
I also remember some slight glitchiness about the bomb you can put together. Like if I blew up a room and entered it a little too early it would only be partially-exploded. But there might be some way of abusing the way you can press a button sequence to enter a cut scene that places the bomb almost anywhere.
Aqfaq wrote:
Possibly useless, unless someone can find out what is outside the visible screen area.
It looks potentially useful. At the very least you could take a path like this and then continue normally (I haven't timed out whether it's actually faster but I hope it is since it looks so much like it belongs in a TAS):
But it could be more useful than that if there's any way for the character to interact with anything or trigger a screen load after he goes offscreen.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I think savestates in Gens aren't exactly linked to the movie file, they only have to match up with the movie's filename (like "GAMENAME - MOVIENAME.gs1") so you could easily "re-link" them to a movie that works and then load the savestate in non-read-only mode, if any of the savestates still have valid movie data in them that is. You could also try the "Load State" menu option that lets you load any savestate file from a file open dialog.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Synced fine for me, but only after switching to the 2.00 BIOS. (I don't know if that BIOS does anything for a TAS besides make it start up slightly slower than the 1.10 BIOS.)
That's a funny bug. Since it lets you move so fast (the first part of it) I bet it would save time if only the checkpoints were placed differently enough that you could reach one. I remember seeing another bug like that much later where I got too close to a guard and somehow fell and pulled up through the floor at the same time, and was able to glitch-run around for a while until the game decided to bring up the death screen.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I'll look into it. For now you can try the Sega CD version, it can't have the same protection mechanism... On second thought, maybe that version is worse even though it works.
EDIT: Now there's an option to temporarily disable SRAM. (It's tempting to auto-disable it if the checksum matches Puggsy's, but something about that feels wrong so I haven't done it.) By the way, a bunch of other things on this page have already been dealt with (your other post, Ferret Warlord's posts, Highness', and gia's).
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
I think this is actually the first Mega Man game of any kind that I played. I remember it being really hard (Infinity Mijinion and his level were absolutely ridiculous although maybe that's because I beat him with X at the very beginning of the game... then there were the rooms made almost entirely of spikes and/or pits... some of the nightmare effects mixed with the levels in really unfair ways... Nightmare Mother was the last straw) so I look forward to seeing it get torn apart.
EDIT: fun and well-executed run, wish it showed more of the game but that's what some other category would be for.
Emulator Coder, Experienced Forum User, Published Author, Skilled player
(1301)
Joined: 12/21/2004
Posts: 2687
Twelvepack wrote:
If you could really luck manipulate perfectly, you could use uncertainty to allow the conditions to be met instantly.
I.E. every person on earth dies instantly because all of the electrons in their brains coincidentally ended up outside of their skulls.
Luck manipulate by doing what? If you are restricted to controlling only one person then is there really something a single person could do that propagates exactly such a quantum state to the entire rest of the world and does it faster than a more conventional method? Even from the perspective of the hypothetical TASer that has the ability to try it, it sounds ridiculously nightmarish to even think of attempting such a thing that would probably be too slow anyway. And if there is some way that's fast enough, that would really surprise me and the method would probably be quite interesting.
I guess there could be a "player controls X billion characters simultaneously" TAS but that's a whole different category and not really what was being considered.
Twelvepack wrote:
Better condition would be no luck manipulation, necause stupid things can happen given astronomical odds.
Even in regular TASes a "no luck manipulation" condition would be meaningless. Somehow I doubt it's valid to even call whatever it is "luck" in real life.
But it could be more useful than that if there's any way for the character to interact with anything or trigger a screen load after he goes offscreen.