Something between versions 2.1 RC3 and 2.2 beta was changed so that the controller profile (CPF) files don't always list in the "Load Profile" or "Save Profile" dialogues.

Enter "*.*" or "*.CPF" to forcefully display all CPF files in the directory.

This was just originally reported here.
http://forum.pj64-emu.com/showthread.php?t=2661&page=2

its already in the source tracker.

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

This.
http://sourceforge.net/tracker/?func=det...id=1083335

Yeah, that sounds like it. I'm starting to remember having this issue looking for MPK files now as well all of a sudden.

its unfortunate that Rabiddeity has totally disappeared.

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

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.)

(07-21-2011 02:45 PM)Squall Leonhart Wrote:  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.

those files are only required for builds rabid made with VC2005

VC2008 and 2010 are msvc8 and msvc9 respectively

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

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.

no, thats just pj64's fault.

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

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. :/

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.

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

*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.

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.

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

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.

^^ you got lattest dx runtimes?

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.

you need to install msvc 10, you can't just copy paste dll's.

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

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. http://www.microsoft.com/download/en/det...px?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.

---

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.

lol

VBA-M | NGOHQ | Post Impact Productions | TNHW | XBCD 0.2.7

OH YEAH!



This is how controller plugins should be made.
(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