I seem to recall that after Live Force is cleared it restarts at a higher difficulty. [...]
[...] I seem to recall the the big yellow claws/hooks/thorns in the middle of level one are killable. [...]
--Salamander (J), places an x where stuff exists, no questions asked.
local ex, ey, eh = {}, {}, {}
function readword(a, b)
return memory.readbyte(a) + (memory.readbyte(b or a+1)*256)
end
while true do
for i=0, 15 do
ex[0]=memory.readbyte(0x035f+i)
ey[0]=memory.readbyte(0x033a+i)
eh[0]=memory.readbyte(0x042b+i) -- If non-zero, it probably exists.
if ex[0] > 0 and ex[0] < 248 and ey[0] > 0 and ey[0] < 223 and eh[0] > 0 then
gui.text(ex[0],ey[0],"x")
end
end
FCEU.frameadvance()
endThere's also one around at least the top hand (dunno if there's one near the bottom hand too) just before entering the blue section of level 1.
But first, I really should complete the input all the way through the first stage. I'm still wishing I had multi-track recording, but I'll run with one player and manually edit in the other player...
Again, I'm not sure what sort of help I need. Maybe a script that lets me know what directions I can take without blowing up on the terrain would be a start. I don't have many useful addresses, but if you need me to find something, I'll go look.
...Waitaminute, didn't the windows build of FCEUX already have this feature?
Can't say I've succeeded at discovering tile or collision data in RAM before, though it would be indispensable for some bots I've been meaning to write. I've already got my own set of memory search functions, so I may conjure up a custom function to detect the memory structure(s) we're interested in. That should be interesting, if not altogether useful.
I'm not aware of this. I've looked through a few things, but never saw anything about it. Since I apparently can't find this, I probably would need to be pointed exactly to where it is.
At least, that's basically what I think... May be worth screwing around with this to confirm whether or not I'm right...
for i = 0, 100 do FCEU.frameadvance() end --avoid messing up the boot sequence
while true do
for i = 0, 0x1e9 do
memory.writebyte(0x6000+i, 1)
memory.writebyte(0x2080+i, i) --lol.
end
FCEU.frameadvance()
endEr, what is PPU Memory and how is it different from NES Memory? I'm guessing primarily graphical stuff happens in the PPU Memory...?
Well, I overwrote the entire 0x6000 0x61E9 region with zeroes, and couldn't hit the terrain anywhere in the level, including the brain at the end. Setting it to 1 would logically make every 4th tile deadly, and sure enough, I can keep the ship in a tiny invisible column of safety before being crushed against the side of the screen. Your findings seem to be correct.
0x0043 - Stage sub-position
0x0044 - Stage position
0x0045 - Stage position * 256
0x0041 - 0 = side view 1 = top-down view ... I think...
0x035C - 1P X-pos 0x0064 - 1P subX
0x0337 - 1P Y-pos 0x0062 - 1P subY
0x035D - 2P X-pos 0x0065 - 2P subX
0x0338 - 2P Y-pos 0x0063 - 2P subY
0x0070 - 1P speed Each speed up is +1/4 pixel/frame
0x0071 - 2P speed At 0 speed, movement at 5/4 px/frThe next piece of fun coding to do is to multiply each byte by 2, OR it with the original value, and AND it with 0xAA every frame. All terrain should be shot away with one shot, while the open space remains open... Theoretically. But putting in destructible terrain where there shouldn't be any... How will the game react? Probably normally, just with more destructive bullets than you thought possible.
There seems to be some spots within the range 6000 to 61E9 that aren't used. Or at least, not by the terrain. It also seems to switch between two sets of addresses, both within the range I specify. 0x6028 to 0x60EF, and 0x6128 to 0x61EF. On the other hand... There's the top-down view. That needs more width. In which case, it uses a larger range from 0x6000 to 0x60EF and 0x6100 to 0x61EF.
I'm starting to get deeper into lua scripting. I have successfully created an array of dots that scroll along with the screen. Problem is, the dots have no significance, and will utterly fail to look good in stages 2, 4, and 6. Point is, I'm farther in lua scripts than before. I'll try creating a script that dots out where the terrain is. I'd like the practice.
--Salamander (J), draws a single green pixel where there exists a wall.
--FatRatKnight
local sp, temp, addr, nx, ny = {}, {}, {}, {}, {}
function getwall(x, y) -- Expects input by tile, not by pixel
-- Function reads the target address. Silly numbers are clipped to within range.
addr = 0x6000
nx = x%64
ny = y%30
if nx > 31 then -- horizontal scroll uses two different arrays
nx = nx - 32
addr = addr + 0x100
end
return AND( 3 * 4^(nx%4) , memory.readbyte(addr + math.floor( nx/4 ) + ny*8) )/4^(nx%4)
-- Bitmask Calculate Address Location rightshift
end
while true do
for x=0, 31 do
for y=0, 24 do
if memory.readbyte(0x0041) == 0 then -- horizontal scrolling
sp = memory.readbyte(0x0044) + memory.readbyte(0x0045)*256
if getwall(math.floor((sp+4)/8) + x , y+4) ~= 0 then
temp = 7 - (( sp + 4 ) % 8)
gui.drawpixel(x*8+temp, y*8+4, "green")
end
elseif memory.readbyte(0x0041) == 1 then -- vertical scrolling
sp = memory.readbyte(0x0044) + memory.readbyte(0x0045)*240
if getwall( x , y - math.floor((sp+4)/8) ) ~= 0 then
temp = ( sp + 4 ) % 8
gui.drawpixel(x*8+4, y*8+temp, "green")
end
end -- if; horizontal/vertical scrolling
end -- y-loop
end -- x-loop
FCEU.frameadvance()
endDrawing boxes shouldn't be hard to implement, hopefully. Checking player's position to see if it would overlap with a wall would be a neat trick to do.
There are, in fact, no bitwise operators. Lua itself doesn't even have AND, OR, etc. DeHackEd added those to Snes9x himself, and it wouldn't be difficult to add shift functions.
You can use semicolons to put multiple statements on one line... possibly with some caveats.
If you've found where the game stores hitbox coordinates, a call to gui.drawbox() is all you need, IIRC.