Posts for DeHackEd

1 2
8 9 10
32 33
Posted: 2/16/2008 3:13 AM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Please link against the Lua DLL. Add-ons require access back to the main Lua library, and you can't get that if it's linked statically into the EXE. Nothing on Luaforge will work if you build Lua into the EXE itself, wreaking the screen shot and image overlay functionality. Plus I had ideas for the network library. My changelog says "split the DLL from the EXE" for a reason in 0.04. Statically linking the library back in ruins the whole idea of addons. In the grand scheme of things, you want the DLL.
Posted: 2/15/2008 8:57 PM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Where's the Lua51.dll? You need it.
Posted: 2/15/2008 11:09 AM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
To gocha: I knew I forgot something about 0x7e0000... I just couldn't remember what... ugh, I do that kind of thing a LOT To Dromiceius: I accidentally zipped up the wrong EXE when making the 7z. It was replaced with a fixed one. Something went wrong in a recompile of the EXE. Just redownload. Or use improvement 12...
Posted: 2/14/2008 10:03 PM
Post subject: Re: LUA bot scripting
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Halamantariel wrote:
DeHackEd: I think this bot is a good example of an alternate usage of lua scripting that isn't just for gui displays. You might want to take an in-depth look at this ;)
Umm.. I DID kinda plan for that possibility. That's why you have the savestate engine at your disposal and the ability to push your own buttons. The GUI didn't come until the third release.
Posted: 2/14/2008 10:00 PM
(Edited: 2/14/2008 11:31 PM)
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Sorry about the long delay.
  • Source code. Windows users are encouraged to build using Makefile.mingw because you're on your own any other way. Linux users should build as usual. Some assembly required.
  • The memory.register function is finally written!
  • gui code expanded. You might want to look into this one.
  • Binary functions added For Your Convenience (tm)
  • If you accidentally send a script running unchecked, you will be prompted to kill it.
  • The signed version of the memory functions now exist
  • Windows EXE will load external libs now. As a side effect, there's now a lua51.dll pulled out of the main EXE because it's needed.
I think that covers it. Version 0.04 windows EXE Edit: EXE replaced with a fixed version. Lua DLL will cause a crash otherwise. I previously fixed this bug, then zipped up the wrong EXE. Stupid me.
Posted: 2/10/2008 1:34 AM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Naohiro19 wrote:
It quoted it from windef.h as follows. 
<omit reason="brevity" />
?? Huh?
Posted: 2/9/2008 2:25 PM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
DAS (basically, keyboard autorepeat for left/right movement) and ARE (delay between pieces) both shrink over time. ARE shrinks for the difficulty increase, DAS shrinks to make up for the need to get autorepeat working before a piece locks down which happens faster over time. Past level 300, a strange thing occurs. Normally DAS < ARE so "pre-charging" autorepeat is not a problem. At 300 and beyond, DAS > ARE so in order to maintain a charged DAS state, I must abuse TGM2's input code. Most of those pieces were dropped on a single autorepeat charge as far as the game is concerned. The actual execution of this is not a problem - I need only make sure I release left or right for exactly 1 frame to for lockdown. Now, MAME's savestate code automatically unpauses after saving or loaded a state. Comments in the source code imply that actions needed to be executed after a state save/load only occur while emulation runs, hence the unpause. I corrected for this by executing a frame-advance instead. Unfortunately this wreaks havoc for inputs since any save/load state will cause the controller to have no buttons pressed for the immediately following frame. Past level 300, I had to either change this behaviour or give up my precious DAS charge. I chose the former, and desyncs began. I have plans though. It's just not going to be happy.
Posted: 2/8/2008 9:57 PM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Okay then. I'll add it. memory.read{byte,word}signed will return a number in the range of -32768 to 32767 or -128 to 127 as the case may be. Added to the API.
Posted: 2/8/2008 11:01 AM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
snes9x's memory algorithm only provides unsigned numbers. If you want to convert to negative, subtract 256 or 65536 from the number as appropriate for the data size. Eg: -1 will be reported as 255 for a 8 bit value, and 255-256=-1. Of course, the number must be >= 128 or >= 32768 before you can apply this. Do you still want it provided via the interface anyways? It's not that it's hard, only that it's unnecessary.
Posted: 2/8/2008 3:06 AM
Post subject: MAME: TGM2 Death mode TAS
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
I wanted to post this since I finally put it on youtube. I beat rerecording support into MAME 0.106 (the version that ships with most linux distros), added TGM2 support, and ripped loose. Muahahahaha. Unfortunately it's not entirely sync stable. As you'll see. Still, it's a step in the right direction.
Posted: 2/6/2008 1:28 AM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
I'm preparing to release a new version. Changes:
  • Will include source code, and Linux version will compile and work. Some assembly required.
  • Windows version will successfully load 3rd party libraries, such as those listed at luaforge.
  • Screen shot support, provided you install the GD library and use it.
  • Transparent drawing over the GUI display.
Anything else requested? These updates are listed in the API as requiring 0.04 or later (which doesn't exist yet)
Posted: 2/4/2008 2:37 AM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
I thought that's what that thing in the Help menu was for. Give it a look. And if it's not, I don't know how to help you. (Besides, that just takes away half the point of a scriptable emulator)
Posted: 2/4/2008 1:30 AM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Fix a memory leak. Otherwise, pressing load-state will eat about 730 KB of memory. Yeah that sucks. No other changes.
Posted: 2/3/2008 5:07 PM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
New version, 0.03 New features/changes:
  • GUI code! Draw on the screen!
  • snes9x.speedmode now works properly
  • Emulator should follow the spec on the API doc now.
  • Order of memory.write*() parameters was incorrect in previous versions.
  • Misc bugfixes
Known Issues:
  • Possible crash when a script exits normally. Reported by DK64_MASTER, not reproducible by me.
  • memory.register remains good and broke
The sample scripts are no longer included in the ZIP as the list has been growing. Now they're online.
Posted: 2/3/2008 1:27 AM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
I have no idea what I'm doing when I modify the windows GUI code. That one's going to be put off. The GUI code is up and working, and I've updated the API spec. I could release an updated version right now if I wanted to. GUI functions are draw pixel, draw line, draw box (outline only) and write text anywhere. Edit: would eliminating this one frame drawing delay be worth doing if it made scripts just that little bit more complicated? I can allow you to specify a function to be called just before the image is drawn, allowing the updated state to be viewed and the images drawn.
Posted: 2/2/2008 8:43 PM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Getting input into the script is technically a problem for me since I have no experience with prorgamming into windows at this level. I'd basically need to make new input buttons to go with the normal SNES controllers. But it can read the normal gamepad. If there's a button that normally does nothing (eg. Select) then you can read it as a secret script command. I'll see if I can just extend the snes9x input code as is to support additional buttons.
Posted: 2/2/2008 1:41 PM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
upthorn wrote:
multiple calls to C from LUA, which would presumably incur a performance hit.
Technically speaking yeah, but Lua is pretty fast. It also makes the C code conform pretty close to the actual Lua internal format for function calls. All in all, I don't think it would be a significant hit for any situation where images going on screen would be important (user viewing, AVI encoding) Still, it's a good idea to include, and colour should be added as well...
Posted: 2/2/2008 4:00 AM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
You have access to the IO library in Lua. Have one script monitor a movie and save stats to a file. Then have a second load the stats. The IO code in Lua can be a bit confusing though. :/
Posted: 2/2/2008 3:13 AM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
In an attempt to spark interest, I'll ask the general public: What features should a scripting language in an emulator support (ie. what should I add)? Would there be interest in adding this to the NES, N64, or other emulators? I don't think it would be very hard. My own suggestion would be to support drawing on the screen. If coordinates are calculated by a script, they could be rendered visually. gui.drawpixel(x,y) and gui.drawline(x1,y1,x2,y2) would be simple enough.
Posted: 1/31/2008 8:47 PM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
The short version is that the resource file still runs through the C preprocessor. All those VS_* macros are converted to integers from windows header files. The resource compiler doesn't process them directly. Except the ones that were missed because the headers didn't pull in all the necesseties, or they were defined conditionally with #ifdefs. I had to manually #include <commctrl.h> and even then some files needed tweaking to import everything I need. The C preprocessor can be manually invoked, so that helped immensely. That aside, it builds just fine under mingw.
Posted: 1/31/2008 1:31 AM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Updates! Bugs fixed:
  • Speed is now sane during script execution
  • Scripts exitting normally no longer give a Lua error on shutdown
  • Savestate functions work well enough to meet the specification set in the API docs
  • No longer depends on FMOD.dll
  • Less spam to stdout.txt (whoops!)
Known issues:
  • C:\Windows\Temp might get filled with anonymous savestates if shutdown of snes9x is not clean.
  • movie.record and playback not working
  • Joypad code believed correct but not tested
Link Edit: Turns out I didn't fix the speed bug as well as I had thought. If your version still exhibits high speed when a script runs, redownload. I've also renamed the executable to snes9x_lua.exe by request so as to not conflict with other emulators.
Posted: 1/29/2008 11:20 PM
(Edited: 2/24/2008 1:52 AM)
Post subject: Lua scripting in snes9x (looking good!)
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
For the hell of it, I added Lua scripting to the latest (as of when I posted this first) snes9x from gocha's modified snes9x (currently improvement 11 beta 17 (I think)). Latest version (0.06) Previous version (0.05) Sample scripts API (keep an eye on the version numbers!) I will be offering some tech support and scripting assistance for anyone who asks in this thread. Moderation note: this post was split from the thread by gocha.
Posted: 1/29/2008 5:21 PM
(Edited: 1/29/2008 7:41 PM)
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Could I get some help compiling the source code? I've managed to compile pretty much everything with mingw except the resource file. I'm getting syntax errors on line 210. All other errors I've managed to repair. Mostly C++ spec variations between gcc updates. Edit: Never mind. Header file issues resolved. Preprocessor's fault.
Posted: 1/21/2008 11:15 PM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
Pop it into the ROM directory, then choose to refresh the list.
Posted: 1/21/2008 11:14 PM
Quote
DeHackEd
Emulator Coder, Experienced Forum User, Published Author, Site Developer, Former player
Joined: 11/6/2004
Posts: 833
The way I see it, what's in question is the fact that the site displays the wrong time. Technically speaking. While the loss of a few seconds over time might be seen as bad, as far as I see it doesn't cause any serious confusion. All movies are off by a small factor, but it's a constant. It's not as if applying the new calculation might cause an old movie to suddenly become faster and a new movie to suddenly become slower, thus negating obsoletion for speed. As for the discussion regarding lag, it means that all other things being equal (which they are not but let's go with it) FCEU would cause games to tend to lag more than an otherwise identical play in Famtasia which runs at exactly 60 fps. All my most recent FCEU-based AVIs have the correct framerate of 60.0998.
1 2
8 9 10
32 33