It seems to be a language less for things that needs to work with individual bits and more for just working with numbers in general. Unfortunately, manipulating bits is often a concern when dealing with quite a few games, which makes me think lua isn't the ideal language, but the bitwise functions that were added is proof enough that we can change the language a bit to fit our needs.
It's ironic that even though one of Lua's main selling points is its speed, the low-level operators are missing. Of course, it is extensible by design, which as you'd probably guess, is how we're expected to get around that shortcoming. There's also interesting stuff in the higher-level syntax, though the applications there seem mainly AI-oriented. All things considered, I think I prefer Lua over more obvious choices.
In any case, Lua was probably picked for the ease with which C programs can expose their functions to the interpreter.
But I was thinking about putting a single statement over multiple lines!
I misread, sorry. Yeah, you probably can't do that.
I think I just added some convenience for when I try to continue.
First, I cleaned up my getwall a little...
function getwall(tx, ty) -- Expects input by tile
-- Returns a number from 0 to 3, identifying collision data for given tile
-- 0 is open space, 1 is solid wall, 2 and 3 are types of destructible
-- Has knowledge of location and range of wall array.
addr = 0x6000
tx = tx%64
ty = ty%30
if tx > 31 then -- horizontal scroll uses two different arrays
tx = tx - 32
addr = addr + 0x100
end
addr = addr + math.floor( tx/4 ) + ty*8
return AND( 3 * 4^(tx%4) , memory.readbyte(addr) ) /4^( tx%4 )
end -- Bitmask Target Byte RightShift
Next, I created another function...
function PosTile(px, py) -- Expects input by pixel
-- Returns the tile position for given screen coordinates.
-- Keep in mind in vertical scrollers, ty is often negative.
-- Has knowledge of scrolling type and stage position
sp = memory.readbyte(0x0044)
if memory.readbyte(0x0041) == 0 then -- horizontal scrolling
sp = sp + memory.readbyte(0x0045)*256
tx = math.floor( (px+sp)/8 )
ty = math.floor( py /8 )+4
return tx, ty
elseif memory.readbyte(0x0041) == 1 then -- vertical scrolling
sp = sp + memory.readbyte(0x0045)*240
tx = math.floor( px /8 )
ty = math.floor( (py-sp)/8 )
return tx, ty
end
return "nil" -- It shouldn't fall out to here.
end
Then I did stuff with them:
while true do
for pl=0, 1 do
plX = memory.readbyte(0x035C+pl) + memory.readbyte(0x0064+pl)/256
plY = memory.readbyte(0x0337+pl) + memory.readbyte(0x0062+pl)/256
plS = memory.readbyte(0x0070+pl)/4 + 1.25
for x=-2, 2 do
for y=-2, 2 do
if getwall(PosTile(plX+x*plS , plY+y*plS)) == 0 then
color="green"
else
color="red"
end
gui.drawbox(187+x*4+pl*28, 215+y*4, 189+x*4+pl*28, 217+y*4, color)
end
end
end
FCEU.frameadvance()
end
I have my own personal terrain radar. It tells me if I were to move 1 or 2 frames in some direction, whether my position will intersect with a wall. We can adjust a few values to change scanning radius or where the boxes are located.
I see something about that gui.register() function. I'm wondering how it is to be used... Having the small green/red boxes show up when it's important and not a frame after it's importance should help things a bit.
After looking through the code, I don't see where you define the variables x and y. I also copied the functions getwall and Postile to the same lua-script file. Perhaps I'm doing something wrong somewhere.
If I can get your script to work, I can try to help you get gui.register to work. Basically, to get it to work on your script (script), simply change
(script)
to
while true do
local function displayer()
(script)
end
gui.register(displayer)
FCEU.frameadvance()
end
This way, all commands inside the function displayer will execute on that very frame, so if you replace (script) with a gui.drawbox, it will not be 1 frame behind.
Hopefully that helped some.
Strange... Works fine here. I copied and pasted the entire three segments into a new file and that works without problems.
Made more strange considering I'm using x and y on a previous statement, here:
if getwall(PosTile(plX+x*plS , plY+y*plS)) == 0 then
If it fails on the drawbox because of x or y, then it should have failed earlier, when I make the call to PosTile.
Additionally, the for loops use x and y. The drawbox is within the for loops. This just adds further questions. Why is it failing on you, and not me? Why that statement, and not the previous one that uses some of the same values?
Basically, to get it to work on your script (script), simply change (script) to [a function, and call it through gui.register().]
I was thinking about testing a few of my own ideas, but after you said this, I tried it and it works. Thanks. I made sure to keep the main while loop and frame advance outside the newly made function. Should be easier to spot where I can safely go without first crashing into things now.
Psycho twin ships, go! I finally beat the first stage.
The answer is that it won't save a single frame if I put my ships on the far right of the screen. After the "auto-pilot" takes over, it's takes a fixed number of frames for the next level to load regardless of where the ships happened to be positioned.
Now, what is the question that fits the above answer?
Yes, it's good to know that I haven't completely forgot this game. I'll be making slow progress, but progress should exist. Also, there are a few places where lazymode took over, but I don't feel like going back to them.
I wonder how many other Bosses and mid-level Bosses the Force (Shield) as a weapon trick helps with.
If I had to guess, all of them. The level 2 boss? Sure, the fact it's inside the boss a ways is no problem. The level 5 boss? Who knows, but if possible, sure would be fun watching the ship dive recklessly into the boss in spite of its clear defenses.
I'll be making attempts to Force-kill every boss and mini-boss, partly because it saves on lag-causing shots and, of course, it's a one-hit kill. And I can "store" up to four of these Force -- A player can have one active and collect another 6 power-ups in preparation to create another, and I have two players.
So close! It was only the dragons head i think is eyes were glowing and it was on NES. Anyway thx Zurreco, your fast! :)
One-Year-Necrobump to say that the game is almost definitely Life Force/Salamander.
I tried to register quite some time ago to answer this question, but the registration never went through, so I sort of forgot about it, but it seems that it ended up working after all, just very, very delayed.
I was playing it when I was young. It's a Nes or SNES game.
It was a puzzle game and if I remember correctly, you had to push a "puck" into a hole.
Also I remember that when you finished a level, there was a "loading screen" which had heart, inverted heart, and some other image which cover the entire screen.
Do you know what game it is ? It would be nice if someone know that game :P
Thanks !
This reminds me of Fun House, but no loading screens in that.
This is my completed TAS in Salamander. In this run, I use only speed upgrades and dodge enemies and projectiles. Be sure that controller U+D/L+R is turned on.
This movie can only work correctly in TAS Editor, not in Play Movie in FCEUX, because it desyncs from stage 2, whether it is exported as FM2 or kept as-is as FM3.
Movie file: User movie #41311504568918546
Encoded video: https://youtu.be/_KpMXQ1XjlU
Oh, this game. Has it really been 7 years since my last post here?
I have a run uploaded to Microstorage that I suggest viewing, assuming it still syncs in the latest FCEUX for the most part. In fact, look over this topic for information you might want to know.
As for your playaround, thanks for your attempt. I do have a few criticisms, after briefly looking over the first level.
Salamander/Life Force has the possibility of two players. With just the one ship, there's only one player-controlled thing to look at. In addition, Salamander lets you have three Options following the two players, giving more objects to fool around with (although between the two players, you won't have enough power-ups for the Options after going for maximum speed-ups, so these glowy things are for later levels).
Very little of the environment was considered. Well, okay. You obviously fly in ways that you don't crash into stuff, but I don't mean merely surviving. There is little consideration made in "acting out" with the various objects and terrain. Shooting out curious patterns in the terrain that can break might be nice to see, but you just sit still and shoot a straight line forward.
Combining the two points, a second player can give a little better storytelling in that there is something else to interact with. Making it look like the lone player impaled itself on a spike ("acting out" by playing with a particular hitbox) might be a little fun. Having a player look like they rammed the second player onto said spike after stealing a power-up adds much more to the visuals.
Playarounds are tricky things. I think this game is suited for it, but it's going to take some careful thinking to make it look like you gave character to what is otherwise just a pair of ships flying around. I hope to see more, but I know full well the difficulties of getting it done.
Oh, this game. Has it really been 7 years since my last post here?
I have a run uploaded to Microstorage that I suggest viewing, assuming it still syncs in the latest FCEUX for the most part. In fact, look over this topic for information you might want to know.
As for your playaround, thanks for your attempt. I do have a few criticisms, after briefly looking over the first level.
Salamander/Life Force has the possibility of two players. With just the one ship, there's only one player-controlled thing to look at. In addition, Salamander lets you have three Options following the two players, giving more objects to fool around with (although between the two players, you won't have enough power-ups for the Options after going for maximum speed-ups, so these glowy things are for later levels).
Very little of the environment was considered. Well, okay. You obviously fly in ways that you don't crash into stuff, but I don't mean merely surviving. There is little consideration made in "acting out" with the various objects and terrain. Shooting out curious patterns in the terrain that can break might be nice to see, but you just sit still and shoot a straight line forward.
Combining the two points, a second player can give a little better storytelling in that there is something else to interact with. Making it look like the lone player impaled itself on a spike ("acting out" by playing with a particular hitbox) might be a little fun. Having a player look like they rammed the second player onto said spike after stealing a power-up adds much more to the visuals.
Playarounds are tricky things. I think this game is suited for it, but it's going to take some careful thinking to make it look like you gave character to what is otherwise just a pair of ships flying around. I hope to see more, but I know full well the difficulties of getting it done.
Thank you so much for your opinions! When I am not busy in real life, I will try improving it. Or maybe having someone else improving it is better. :D
Uhhh,,, There is a TAS movie released on bilibili by 海原星。 But he didn't share his emulator's movie file. Just level-by-level videos. And it seems that the game isn't run on either FCEUX or BizHawk. Due to a wrong fps.
The movie plays with a high entertainment!
So here's the video links:
Area 1.Area 2.Area 3.Area 4.Area 5.Area 6.
Thank you for sharing this, Soig! It is encouraging to see a burgeoning gaming community on Bilibili. I have considered creating an account for months, but now seems like the right time. :)
