headkaze

Okay MC64 has been updated to use the latest toolchain. I did have an issue compiling a 32-bit version on my 64-bit machine "png2bdc.exe" crashes. I've looked this up and it appears to be a problem that doesn't relate to MC64 (more info) Also MC64 will now detect how many cores you have and if you're running 64-bit and set the options for you. So default options to compile for your PC should be fine.

Go into the Edit->Options->Settings tab you will see "Show Date/Time". The reason its like this is because when you release a theme some people may like to have the Date/Time. So you need to place it somewhere even if you don't show it.

There is currently no way to customize the selector bar like this, although you can create a custom one using the Theme Editor's Selector Bar Editor. Sorry this is not possible I don't think you can customize this. Really the Theme Editor only adds features that are customizable in GameEx aswell.

I don't have GameEx setup on my Win7 machine yet.. if you want to test it download DInputBlockTest.zip and run RawInput.exe, DInput7.exe and DInput8.exe .. launch GameEx trying to block space bar (VK 0x20).. if no output goes to the console then it's successfully blocked it.

Do you have any specific details on the updates needed to make it work?

Yeah it depends on how the app is reading key input. I did find that even with DInput8 it sometimes has some issues blocking input too, not sure why (could just be a permission issue there or the same problem I can't remember). If a game uses Raw Input to read input (like MAME) there are no problems. The main problem seems to be with DInput7. So anyway the key blocking in VJoy should work for some games.. I should probably change the docs to say that. I know it was bold of me to say that Vista and Win7 contains a bug, but I did have the evidence to back that statement

I researched this quite a bit and I'll post the results here. You will have the same problems with GameEx blocking certain games in Vista and Win7. The problem seems to be version checking code in DirectInput... So in other words because of this version checking bug it's using a low-level hook which is inserted above all other keyboard hooks so you can't block input. When it uses Raw Input processing in XP as it should you can successfully block input. The conclusions we made is the only way to fix this would be to install the global keyhook after the game is launched or hack the DInput dll's to always get a version number of 5 from GetVersion/GetVersionEx.

Can you please post your GameEx log file after the crash occurs?

You can use a util like this to send a WM_CLOSE message which should close most apps gracefully.

Well actually I had planned to make XLaunch before VJoy and then realised it was pointless unless there was a 64-bit driver for the KeyToJoy. Also SF IV came out and it only supported one keyboard so that was another driving force originally. Then just as I finished VJoy another solution appeared, and then just as I decided to release VJoy "free for non-commercial use" I find the programmer of PPJoy who orignally said he wasn't going to continue development released a 64-bit version of PPJoy. So really it's been alot of bad luck. I spent several weeks writing VJoy, and even nearly lost my PC in the process with a nasty blue screen on bootup. Since drivers are written in kernal mode they don't crash - they BSOD. So then I smartly moved to using a Virtual Machine for all my testing. Then I had to write the JoyToKey app.. well it was alot of work so I wanted to see if there was commercial interest which is how the drivers got signed by Ultimarc. In the end though with all the bad luck I just decided to release it and hope there was some commercial application down the line. In the end it got released for the benefit of the community so I'm happy if people get some use out of it!

There is a program I was working on called "XLaunch" which was going to be able to convert any type of input to any other type of input. It orignally used PPJoy but obviously now would make use of my own drivers. Unfortunately now that I'm working on my next game with Flash (this time for the iPhone) I don't see me finding much time to finish it. I think XPAdder would be nice to add support that XLaunch and VJoy were aiming for. One program for all your input translation needs. Going from joystick to keyboard is easy, but writing drivers to go the other way is not. Anyway one day I might finish it, who knows?

It does more or less do what PPJoy's KeyToJoy functionality but it has some advantages even though a new version of PPJoy has been released recently with 64-bit support. - VJoy has signed drivers - It has a much nicer program that runs in the icon tray - It supports key blocking (although unfortunately Vista and Win7 contains a bug that makes this not work) - No more having this unsightly floating app that you have to try and hide and kill off later - No annoying virtual joysticks to setup and install - you get two of them ready to go If you want parallel port to joystick support you will need to get PPJoy instead. BTW Coding drivers is a PITA!

VJoy Virtual Joystick is a driver and icon tray application for converting keystrokes into joystick input. It supports two virtual joysticks as well as command line control. It has signed drivers and supports 64-bit systems such as Vista and Windows 7. Visit VJoy Website VJoy Virtual Joystick Driver v1.2 released! - 2 Joysticks - 8 Axes with a range of -32768 to 32767 - 32 Buttons - 4 POV's VJoy SDK v1.2 is now available for using VJoy in your own applications. There are many real world applications using VJoy right now such as a Steel Batallion Controller, replacing axes for Flight Simulator, head tracking, using Wiimotes and Kinect to control games or even to interface with robots. Some of the things people are using VJoy for are pretty amazing! Check out the new VJoy SDK v1.2 which includes source code to control the drivers in languages such as C++, C#, VB.NET, Delphi and VB6. Download VJoy SDK v1.2

You can try ControlsDat

I quite like the XBMC skins.. why doesn't someone make a skin for GameEx like that?

Try moving a few Roms to a local drive and see how fast it returns then.

No, GameEx plays .flv videos fine. You just need the right codecs installed. I recommend the Vista Codec Pack

This must be a custom path being set as this profile defaults to WorkingPath=[DEFAULTEMUPATH]\Project64 Do you get the following prompt when you import an Emulator (see attached pic)? It allows you to set the defaults of where your emulators will download and set your paths to match. If not you can open GameEx\CONFIG\GameEx.ini and make sure the following values are set [SetupWizard] EmuPath1=C:\Emulators AssetPath1=C:\Assets RomPath1=C:\Roms DefaultPathPrompt=True DownloadDatabasePrompt=True DownloadEmulatorPrompt=True You should always have it prompt you to set your default paths if you intend on changing them between emulators. So do not take the tick off "Always Show".

It's not really that long when you consider how fickle Windows can be about changing between apps/windows. But there are some things you can try. First of all some anti-virus software can slow processes down as they scan on the fly so you can try disabling it and see if it improves things. Another thing to try is download Process Monitor and have a look at exactly what is going on. I don't remember GameEx taking long to exit a game but it may just be designed to wait for things such as changing resolution (even though you don't change resolution GameEx has no way of knowing so probably waits just incase). On top of that it has to reinitialize itself and that would understandably take a bit of time.

Thanks for the report this bug has been fixed and will be in the next release

Hey DJ Infinity. Yeah I will update this soon. Looks like they are using a 64 bit GCC compiler now. So I will probably replace the Microsoft one.

I normally recommend the Vista Codec Pack. Uninstall any current codec packs before installing. It includes ffdshow with it.

If you think it needs one then leave it in. The only time I've experienced problems is when I set it to go fullscreen but didn't specify a width and height it would crash. I just want to avoid using wrappers if possible because we may have problems in the future depending on them. If it's an AutoHotkey script then please have the source included aswell.

Yeah but why not just edit the ini file manually in the download and leave it at that? Having a loader do it seems pointless to me. It just adds an unnecessary step. Moreover it's easier to edit the WorkingPath of a config than it is to re-distribute a new loader if future versions of NullDC change the command-line. Please if possible can we avoid using a loader? I've seen it been done without the need for one.

Will check it out when I get a chance. BTW I thought NullDC didn't need a loader? I would really prefer it if we can avoid loaders if we don't need them.