Jump to content
Visual Boy Advance-M
Iconoclast

File Listing in Version 2.2 Beta

Recommended Posts

Oh yeah, hadn't found a thing about that or what specifically happened.

 

I couldn't tell if he himself owns the randomwisdom.com blog or domain, but apparently that has still been updated about monthly with blog posting. Otherwise it's as if he stopped updating period ever since he transferred the discussion from EmuTalk. (And the idiots there still never bothered renaming his thread.)

Share this post


Link to post
Share on other sites

its unfortunate that Rabiddeity has totally disappeared.

 

Indeed. Seems there was more than a few changes between his 2.1 RC3 publication and the 2.2 beta patch.

 

I was working on efficiently organizing an emulator package with a forced plugins set. In the process, I've found that the MSVCP70, MSVCR70, and MSVCP80 libraries are no longer needed; maybe at some point the read-me can be updated with this and the files that actually are needed as rabiddeity had maintained. I just didn't want to upgrade to a plugin I thought was going to rely on a shitload of installation xD.

Share this post


Link to post
Share on other sites

Ah alright; that explains it.

 

Maybe this newer branching of runtimes is what's causing versions after 2.1 RC3 (builds by rabiddeity, before 2.2 beta and final) to take about 8 seconds to open the configuration dialogue on whatever emulator on my system. I forget if I ever did do that DirectX installation lol.

Share this post


Link to post
Share on other sites

It doesn't happen on 1964, but it happens on Project64 1.7 and Mupen64++ beta. 2.1 RC3 and below don't have the issue on any of the three emulators, so IDK what 1964's doing that's so special. :/

Share this post


Link to post
Share on other sites

hence why its not the plugins fault. the emulator hangs while loading the runtime for some reason.

 

i expect if it they were built with MSVC10 (like 1964 is) it would open instantly as the emulator loads the modules.

Share this post


Link to post
Share on other sites

*sigh* Ah well. It's a damned shame so many people had to team up to kill off the good days of Mupen64 and Project64. Now they'll never be updated to support plugins that are called upon for import using more modern run-times (the MSVC10).

 

Well, while I'm archiving the NetPlay Mupen64++ I guess I'd best be off bundling 2.1 since it's just for NetPlay atm. Changing controls during a game would result in that 8-second wait due to the outdated compilation of the emulator which would be annoying.

Share this post


Link to post
Share on other sites

Iconoclast, i've done some more testing and this is actually not an msvc issue either,

 

In fact, its the project64 beta protection stalling the plugin init.

Share this post


Link to post
Share on other sites

Yeah I remember it taking quite a long time to load on the beta Project64, though I remember it also being slower to load than other plugins on other emulators as well.

 

Shame I can't figure how to test it now, though. I seem to have all the necessary Microsoft redistributables installed and no missing libraries but still can't seem to get the plugin to initialize now on Windows 7 x64. 2.1 RC3 still works.

Share this post


Link to post
Share on other sites

Attachment.


Seems both of the parent import functions for MSVCP are unresolved C++ functions.

 

In MSVCR100 parent import functions there were a few unresolved C++ and three unresolved C but everything else resolved when called through MSVCP instead.

 

IDK what caused it. Microsoft gave me all the installers, not some foreign site.

Share this post


Link to post
Share on other sites

Not this time dammit. Like I said I used the installers to get all the runtimes, since I have Windows 7 x64.

 

Problem is I used the 64-bit support T_T.

Go here for x86-32. :Dhttp://www.microsoft.com/download/en/details.aspx?id=5555

 

Ironically, when I checked using the 32-bit version of Dependency Walker, it showed that I only have the 64-bit versions of MSVCR100 and MSVCP100 installed, not the 32-bit versions. So that's the problem. :D


Heh, I don't know if auto-merged double-posts will show up as new, but here goes.

 

So yeah I'm still noticing here that the plugin initialization is slowest on the beta system for Project64, with the protection scheming liable, though I still notice that entering the DllConfig() function is slow only for this particular version of the plugin. Initializing the plugin in this specific way, is what's slower on all the emulators and particular to this version only.

Share this post


Link to post
Share on other sites

OH YEAH!

 

nodepend.png

 

This is how controller plugins should be made. :D

(just kidding)

 

A 4-KB DLL that supports everything to do with N64 controller emu !! :eek:

(just kidding)

 

Backwards compatible with Pajama64, 1985, Fukken64Plus, on Windows 3.1!

(just kidding)

 

heh, well semi-jk about all of that anyway

 

Still who cares. Keyboard-only support and all, it still beats the shit out of having to use this bloated DirectX crap.

 

you can delete mah post nao xD

Share this post


Link to post
Share on other sites

Slower, bloated, and useful for features that aren't even needed.

 

Yeah, sure does beat operating-system-level functions. :P

 

 

 

It's crap.

 

Even the x86 size of this plugin is so small xD; it only does like, two instructions to update the controller signal in the game. N-Rage probably *= 200's the FPS with a bunch of god-damned API calls, not that anybody would notice the speed difference nowadays. :)

Share this post


Link to post
Share on other sites
WM doesn't support controls other than mouse and keyboard' date='[/quote']

 

1215-cool-story-bro-flashing-cool-story-bro-image.gif

 

so stfu.

 

The-answer-is-no.jpg

 

While DirectInput forms a part of the DirectX library, it has not been significantly revised since DirectX 8 (2001–2002). Microsoft recommends that new applications make use of the Windows message loop for keyboard and mouse input instead of DirectInput (as indicated in the Meltdown 2005 slideshow[1]), and to use XInput instead of DirectInput for Xbox 360 controllers.

 

In other words, MS says, WM > DirectX :)

 

unless you're using one of those exotic, funky non-keyboard controllers anyway :/

 

Why would anyone use anything else? The keyboard is natively supported by standard drivers and can be easily adaptable to.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×