Their goal is to show whos the better player at a particular game right? but the point im getting at is why do you need to prove to somebody that your better or faster at a computer game then they are, if not to inflate your ego.
The components (buttons etc.) are sometimes not big enough to show the whole text. Example: "Frame number", "ADD", "DEL".
Have you checked the program with large fonts (> 96 dpi)? Delphi 5 programs seem to have some issues with that, but I found a workaround...
Truncated wrote:
- Contents of window are not shown while dragging the scrolling bar.
That's unfortunately a limitation of the TStringGrid component (and one of the reasons why I use a generic TListView in my editor). Of course one can develop his own components, which also has its drawbacks... :|
Turambar wrote:
Make the program cross-platform from the beginning.
Do you know of a Linux compiler that can compile Delphi code? FreePascal claims that...
Well, my progress was very slow in the last time. I just couldn't find the needed time to continue the run as I did in the last month because of a much more busy life now. I'm still in Brinstar and have alot of problems to clear which require too much testing. [...]
ok, I've done my lazy run that's rather shoddy but definitely gets the job done, you can grab it here.
here is the patch you need to run this smv, for a headered rom.
more or less the only route possible, at least that I'm aware of.
For me the patch is not fun to play, but fun to watch! Thanks Atma. I liked the grappling beam action. :)
Damn that's one long video though...
EDIT: Wow, you get half an hour for the exit sequence! o_0
Still desyncs. :/
Btw. there seems to be a problem: when I scan the patched ROM with NSRT, it shows no internal name. Scanning with vSNES reveals that the internal ROM header has been moved by +512 bytes!
That's exactly the reason why headers should be removed from ROMs...
>Re-record count and Frame count will be handled by the program itself.
I guess you don't want to keep people from lowering the number of rerecords. That's fine I guess.
I've added an SMV editor to my savestate editor vSNES.
It's not as powerful as a hex editor (you can't move large amounts of frames around), but maybe it's still useful for some people.
I hope this is the right place to ask...
Does anybody know if the format of the controller data in a SMV file still follows the description in the FAQ?
Eg. A and B seem to be swapped, haven't checked for the other keys yet.
The controller data's format as it appears in a hex editor is as follows:
0001 = Right
0002 = Left
0004 = Down
0008 = Up
0010 = Start
0020 = Select
0040 = Y
0080 = B
1000 = R
2000 = L
4000 = X
8000 = A
EDIT: Nevermind, I figured it out.
Bit0 = undefined?
Bit1 = undefined?
Bit2 = undefined?
Bit3 = undefined?
Bit4 = R
Bit5 = L
Bit6 = X
Bit7 = A
Bit8 = >
Bit9 = <
Bit10 = v
Bit11 = ^
Bit12 = S (Start)
Bit13 = s (Select)
Bit14 = Y
Bit15 = B
39000 - 40000 - I seem to remember someone shooting as they went through the door and the beam appearing in the next room. Could this allow more arm pumping in these rooms?
40000 - I've never seen this trick, myself, but if it worked, it would probably allow for a couple more arm pumps.
See Terimakasih's run at frame 39150. He's shooting ("x" key on the pad) and the beam goes with him through the door.
With the right timing it can also happen at full speed.
The SNES game uses HDMA to transfer some bytes to the SPC700 while the screen is drawn. HDMA support is not perfect in most emulators, and the CPU-to-SPC synchronization even more so. bsnes (and maybe SNEeSE) should be able to emulate it correctly, but they don't even have savestate support yet...
