How to export Setup
Monkey Targets Forums/Desktop/How to export Setup
| ||
| I'm using Monkey X Studio since yesterday and want to "export" the game I've made with it for Windows (glfw). So I built the Game in Release Configuration, took the .exe and the data Folder and created an InnoSetup setup for it. When someone else installed and started the game, the error message "OpenAL32.dll is missing" appeared. "The Application was unable to start correctly (0xc000007b). Click OK to close the Application". Do you have any idea how I can fix this issue and export a setup for windows? Luca |
| ||
| The error is due to the lack of a proper OpenAL implementation being present. You simply need to get the OpenAL installer. From what I remember Monkey came with it before, but I can't really find it at this point. Not sure what's up with the OpenAL.org website, but here's the official BRL-hosted redist, alternatively, here's the download for the Creative Labs (Free/Original) implementation. You shouldn't have any problems redistributing that. Though partially outdated (Newer versions of Monkey require a newer version of MSVC when not using MinGW) compared to your local documentation, this page could be useful. That's from the official documentation, and it points to the previously linked OpenAL redistributable. Here's a list of similar threads: * "OPENAL DLL ISSUE - GLFW3" * "OPENAL INSTALLER OR DLL." OpenAL has been a bit of an issue implementation-wise. OpenAL Soft is technically the most up to date version, and potentially what you should use. The version I noted before is what Monkey came/comes with, and is free to use as you please. If you're interested in OpenAL, the Wikipedia page may help. As far as Linux and OS X go, I'm not necessarily the guy to ask, but I imagine you can get OpenAL Soft or a similar implementation working on those platforms. |
| ||
| Yes include the oal.exe as part of the installation process. You will find it in the targets glfw directory. This executable is 32bit only and was release by Creative Labs. If you need a 64bit version then you will have to build and use the OpenAL-Soft version. With OpenAL-Soft you can build both the 32bit and 64bit versions, but the both must have the name OpenAL32 and be installed in the correct directories for system wide use. I should point out that other third party software expects to use the Creative Labs OpenAL API, so it's best to install OpenAL-Soft in the same location as the application that is using it. Remember: You will of course need to include the OpenAL license with your application. Edit: As far as Linux and OS X go, Linux will have OpenAL in the distributions repositories. Apple use their own implementation of OpenAL and will come pre-installed with their OS's. |
| ||
| @dawlane: That does explain how I was able to get Monkey running without a redist the last time I tried building for Linux and OS X. |
| ||
| The real fun bit for Linux is making packages for distribution, as it requires some knowledge of the system, the package manager files, some sh/bash scripting and where to puts various system files and icons. There are some tools to aid in this process, but at some point you will have to jump through hoops to get things working. Most OS X stuff comes as app bundles and distributed in dmg images (see Disk Utility and it's documentation) . There should be plenty of tutorials on making custom versions. The other tool for OS X is installer, again there should be plenty of tutorials on this. |
| ||
| @Immutable: A late answer. OS X usually has the development files installed. Apple have their own implementation of OpenAL. With Linux the package is OpenAL-Soft. Now depending on what you install; it could end up getting installed as a dependency for another package. |
| ||
| can he not just throw the dll into his game folder and be done with it ? does he NEED to include the full openAL-Soft installer? |
| ||
| There is nothing stopping anyone from doing that. But would it not be a waste of disk space if you had twenty applications all requiring OpenAL and every one had it's own personal copy in it's root directory? An installer that just installs one copy that can be used by all makes more sense to me. |
| ||
| @dawlane: There's plenty of situations (Especially on Windows) where you will need to ship DLLs with the executable. The two biggest issues that come to mind are ABI compatibility and user-permissions. Ideally, you would install it on the system properly, but in practice, you're shipping with your executable. Thankfully, portals like Steam have made this easier, though. On Steam, they just automate running the redist-installers before first launching the game. Too bad Microsoft doesn't understand how to properly distribute their binaries. I've had so many versions of DirectX's runtimes, DotNET's runtimes, and MSVC's runtimes. Now, this is understandable to some extent, compatibility and all, but if the vast majority of my installed programs are DLLs, and nothing else, something's wrong. The fact is, none of the existing platforms has an ideal package manager for dependencies. Linux has the closest working one, but there's still plenty of issues with it. At this point everybody, even the C++ standards committee is trying to fix this. Sadly, it's turning out like that one XKCD comic. |
| ||
| @Immutable: I can see the reason for those issues. The point I was trying to make was having the exact same library installed multiple times. As for Windows, well the file system is a complete mess and no one with over all control of what goes where. Linux has a file hierarchy standard of what is meant to go where and the control is down to the administrators of the vendor repositories, but not all Linux distributions follow this standard and vendors have no control over third party software. The package building tools usually give warnings when some thing is non compliant. The Linux package manager is the closest because of who controls the main repositories and the fact that the software on them is effectively locked down and with the usual security updates to work with that particular version. This in turn is why the systems happen to be more reliable as long as you stick to using one of the fixed (i.e. Long Term Support) versions. You tend to get people that download the latest release not realising that it's basically a testing branch and complain about it crashing. |
   |