Game would not run on Windows 7..

Monkey Targets Forums/Desktop/Game would not run on Windows 7..

Paul - Taiphoz(Posted 2015) [#1]
Sup peeps.. so I poped over to my mothers to show my brother what I'm working on, I built a Windows GLFW2 target build and threw it onto a usb pen..

Thing is when I get over there and tried to fire it up it failed to run, the process kicks off but then gets stuck, nothing appears to run and the process was damn near impossible to force close which was odd as well.

I though it might be OpenAl so I three the dll in with the exe and still no joy.

Any thoughts?

His PC is Windows 7 32bit, Mine is Windows 10 64bit, I was under the impression that monkey builds 32bit exe's so that would not have been the issue would it ?


k.o.g.(Posted 2015) [#2]
You have also no information with an Debug Build? Started over Commandline?


DruggedBunny(Posted 2015) [#3]
Does it works on your PC when run from the USB pen, as opposed to running from Monkey?


dawlane(Posted 2015) [#4]
His PC is Windows 7 32bit, Mine is Windows 10 64bit, I was under the impression that monkey builds 32bit exe's so that would not have been the issue would it ?
The trans compiler executes what ever native compiler you have chosen, so if you have installed the 64bit version of TDM it will compile code into a 64bit executable unless you edit the makefile and add the m32 option to both CPPFLAGS and LDFLAGS. And then the OS would fire up a message dialogue telling you that it's the wrong OS.

DruggedBunny maybe onto something. I've seen this when I tried to run a Monkey app on a NAS. The application will run, but cannot find it's media and throws an exception that you cannot see if you have built it in release mode. It gives the impression that the application has just hung. It could be a file permission thing, so copy over the files to the local hard drive.


Paul - Taiphoz(Posted 2015) [#5]
I was running it from his Desktop I moved it off the pen, I also had no error messages bar one saying that the file did not have an application associated with it, I think that's what it said I think I'm building 64bit out of sheer habit I always pick 64bit when the option exists so I think that's probably the cause..

Dawlane could you go into a little more detail on how to build for 32bit I think it would be wise of me to build both when I or if I ever release this so it would be good information to know, plus it will let me test the theory next time I'm over at my brothers.


DruggedBunny(Posted 2015) [#6]
Yeah, just noticed in versions.txt that using 64-bit gcc produces 64-bit apps! I have believed all along that it was somehow building 32-bit!


dawlane(Posted 2015) [#7]
I believe Mark included TDM-32 with the free version and I'm sure that the Visual Studio solution is still set to produce 32bit executables. And I think that using Ziggy's set up tools in Jungle, download TDM-32 and uses the Creative OpenAL installer, so no need for adding the -m32 switch as it defaults to building 32bit binaries. If you installed OpenAL using the Creative installer, then if you had built your application with TDM-64, it wouldn't be able to link to it with OpenAL with it being a 32bit DLL; you would get a OpenAL DLL not found error here. The solution would be to recompile using the -m32 switch or download either the OpenAL-Soft pre compiled Widows binaries or the source code and build it yourself as a 64bit DLL. There are a few people that swear that OpenAL-Soft is a hell of a lot faster than the Creative version. Another thing that can be an issue with using a GCC compiler are the OpenAL LIB files that you find in the target templates. GCC should complain about these being incompatible binaries. They should be for the Microsoft tool chain.

As mentioned. Use a debug build and try executing from the command line on the end users machine to see if there are any problems.

You will find the GCC Makefile in two locations for both glfw targets. You just add the -m32 switch to CPPFLAGS and LDFLAGS Makefile variables.
The primary location to make changes is in the targets\glfw\template\gcc_winnt Makefile. Open it up in word pad as using note pad may have problems with the CR/LF making it unreadable.
And you will find a copy in the projects .build(version)\glfw\gcc_winnt
But making changes to your projects .build Makefile requires that you locate and remove all the intermediate object files before recompiling with any changes. If you make the changes to the target template Makefile all you do is just delete the projects .build directory.