#1  
Old 31st October 2011, 03:55 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Red face A small input plugin I wrote

Out of the motive of self-entertainment I wanted to pursue writing a standalone source file not using any compiler directives, forward-compatible C code, and only what seems to be all five of the functions truly needed for the plugin to both initialize in emulation and to handle user input towards a game.

Since I've cut so much crap out of it after exploring the methods of others who wrote controller plugins, I feel it's been reduced down to a very small code that might be of interest to other people who want to play around with building controller plugins. There's a mirror of the source for zilmar's basic keyboard plugin somewhere on Zophar's domain if people prefer that.

http://db.tt/dsLcYuiY

It supports only controller 1 and only the keyboard (no DirectInput device code to accept other devices). One of the things I want to do is play around across other linkers and compilers to remove the MSVCRT dependency since it's apparently not needed, and I might replace the linear execution / switch statement method for the key down and release functions with the array structure access method that zilmar used.

I included a pre-compiled version, but again for some minor reasons I don't feel it's perfect for its purpose. If anyone has suggestions for a better keyboard layout they really prefer or comments on the readability of the source code XD I'm interested.

It should work perfectly with NetPlay, too, and no switching back-and-forth between your keyboard and some other device to play the game when using an online chat feature either.
Reply With Quote
  #2  
Old 31st October 2011, 04:22 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Default

lol, I fixed the init on pj64 v1.0-v1.6 and then broke it again just before uploading

Should still work on 1.7 though. Also it no longer inits on Mupen64 somehow...after the 5000 times I've seen it init now that I actually upload it it doesn't. Once I remove more of that dependency code though it should be easy to isolate what to do tomorrow. It also doesn't load in Apollo yet. Works fine in: 1964, Project64 1.7, and I forgot another one I tested it worked.

[edit] and legacy thank-yous go out to a Mr. Retul Amora for his original support tests

Last edited by HatCat; 12th November 2011 at 03:47 AM.
Reply With Quote
  #3  
Old 11th November 2011, 08:02 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,256
Cool Update

...And that makes it funny!

All of these weeks, I have spent wrestling with the MinGW compiler system command-line interface. So many days gone by trying to get a lower-level commands script working to compile the plugin using automation. The result of course was more control over the binary and lower file size than when using it through the Dev-C++ IDE. The link to download is still the same: http://db.tt/dsLcYuiY.
New file: sysinput.cmd is Windows command file (or possibly DOS batch file) to run all the MinGW binutils and libexec to compile and link the DLL, if the DLL and SYSINPUT.C source files are put in %MinGW%/sysinput.

Changes that I can remember offhand.
  • Re-installed the MinGW compiler system to all up-to-date, very recent versions this month...this increased the plugin size by half a kilobyte. (Smaller file size doesn't always mean execution times aren't slower.)
  • Mysterious bulk in plugin size from 7.5 KB to 10 KB. I think I got so frustrated finally getting the command-line, more low-level method of accessing the MinGW binutils working that I forgot to go back to the optimizations I was doing before, to get the size down again. I can make more direct parameter passes later.
  • Source code is a little more friendly with comments now, explains a couple more things I didn't know about before.
  • Optimized to use strcpy() instead of sprintf() for labeling the plugin name "System Input" in the emulator. After reading more online about differences between sprintf (more variable with supported data types), memcpy or other alternatives (null-terminated check or string buffer overflow prevention), and some excess variant of strcpy() that N-Rage used in his source, I realized that strcpy (no overflow check, char-type support only) was the risky method just right for zilmar's forced plugin system, that guarantees that no hazards can errupt from strcpy anyway, shortly before looking back at Hack's SDL input plugin source at the coincidence he was using it as well.
  • added the zilmar-spec function exports RomClosed() and RomOpen()...dummy implementations so that AQZ's NetPlay Input Plugin will show this plugin in the list...once a DllConfig() function is also added, which I refused to do for some reasons. So currently the NetPlay input plugin still won't support this plugin anyway.
  • [edit] oh yeah lol and I was wrong, mempak support does function if the emulator is configured to search for mempak save file...seems to work for gauntlets 64 at least, removed some text and questions from the manual TXT for reasons like this

To-do later...return to original command-line settings methods to get the size down again, add an extra key for lowering the control stick range/sensitivity down to 25%, probably rewrite the control stick away from the switch statements for the rest of the buttons, possibly replace both switch statements with something less efficient but smaller for plugin size? in a separate version to test

Now since I felt awful I couldn't remove at least one of the dependencies and/or get the plugin size down to a nice 4,096-byte release, I released some other candy versions to test.
http://db.tt/nWBDqS6U

Files in this archive:
  • sysinput_1964only.dll -- removed both the MSVCRT and KERNEL32.DLL dependencies...plugin is completely dependency free and standalone from any Windows system files and down to a small 4 KB DLL file, problem is that I had to remove the strcpy() function and that no emulators will list the plugin except 1964. (It will bitch at first but let you select the no-name plugin anyway in the options.)
  • sysinput_kernel32.dll -- removed only the MSVCRT dependency and preserved the DLL execution entry point so that KERNEL32 could still be linked, using the Microsoft compiler system. (I seem to be forced to have both MSVCRT and KERNEL32 when using the better-optimized, public domain and free MinGW compiler system.) I think MSVCRT was around since Windows 95 (in some cases?) or slightly before WinNT which used KERNEL32, but KERNEL32 is still more standardized a Windows-specific operating system file. (MSVCRT is kind of cross-platform...other OSes supply it in the system.)
  • sysinput_mupen64only.dll -- Rewrote the plugin to use zilmar's 1.1 specifications instead of the standard 1.0 specifications that every emulator supports. Currently only Mupen64 will load this plugin; I don't know why Project64 won't remove it. Maybe zilmar un-published the 1.1 version of his specs at some point. Also, the damned Enter key / START button won't work on MUPEN in this version, for some reason.
  • sysinput_nocrtendlib.dll -- Hacked compiler setup on MinGW where the standard dllcrt and crtend binaries were not linked. I can't remember what use this was for lol...just more debugging I guess for people's different systems. On some emulators it will fail to load, others crash the emulator, others it might actually work.
  • sysinput_noentry.dll -- removed the KERNEL32 system dependency and used the /NOENTRY linker command in Microsoft's compiler system. (Only this and sysinput_kernel32.dll were linked by Microsoft's LINK.EXE.) Microsoft's calls a DLL executable image without an entry point (a common standard of 99% of executable programs) a "resource-only DLL", well it worked for this simple emulator plugin here. I think there was one emulator this plugin failed to load on? But if so I forget which one.
  • sysinput_old.dll -- the previous public release where the _DllMainCRTStartup definition I forced at the end of the code caused it to crash or fail on emulators except for Project64 1.7 and 1964.

There was a way I got the plugin to only load on Project64 and not the emulators as well, but it's been too many days for me to recall. I'm not really interested in that, but using hacks instead of natural modifications should make the task all the easier for those interested in the source.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 12:45 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.