• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
NumberXaero

3rd Party DLLs / 32bit64bit / Directories / Loading

9 posts in this topic

So I just got a debug x64 build to compile after building 64bit versions of all 3rd party libs. Im still running the 32bit exe mainly but now I have 64bit exe in the same dir.

The problem is I have a lot of debug/release/32bit/64bit dlls all sitting next to the exe's. Id like to move them to a sub dir in my working folder and spearate the 32bit and 64bit.

Also some libs like libpng spit out the same dll name for both 32bit and 64bit, so they cant be in the same folder. While some libs like physx have some dlls with _x64 _x86 appended, while others have matching 32bit 64bit names. Im not sure of a sane way to go about organizing this any suggestions?

0

Share this post


Link to post
Share on other sites

I structure my output directoy like this:

- *some general output name*

-- Debug

----x86

----x64

-- Release

----x86

----x64

 

This can easily be extended if you add more platforms and/or build configurations.

0

Share this post


Link to post
Share on other sites

Sorry should have been more specific, Im aware of the various output directories and how they work, but I dont run the exe's from their build directories, they get copied to the root of a content dir. In this folder my own DLLs load from a sub dir, my own dlls have names which differ between 32 and 64 bit, a specific build platform will load the correct dlls.

The problem is with the mounting number of 3rd party dlls which sit in the folder with my exe's, I like to load all of these from from folders in that same sub directory, Then the various dlls that have the same name for different builds could be in separate folders.

 

program.exe

program_x64.exe

3rdparty1.dll

3rdparty2.dll

3rdparty3.dll

subDir\subDir\<my dlls, my dlls 64>

 

what Id like

 

program.exe

program_x64.exe

subDir\subDir\<my dlls, my dlls 64>

subDir\subDir\32bit\<3rd party dlls>

subDir\subDir\64bit\<3rd party dlls>

 

Would I just build a list of the dlls I need and call LoadLibrary() from the specific folder? Is there a better way?

0

Share this post


Link to post
Share on other sites

Taking a different tack on the question --- WHY?

What specific reason do you have for shipping both 64-bit and 32-bit versions of a game?

One of them is going to be the primary platform, the one with all the tests, the one that people use, the one where you probe the nooks and crannies of the system to find all the bugs. The other one won't have the tests and will be full of all kinds of bugs.

Invariably you are going to come across some system specific bugs that are only manifest on 32 or 64 bit variants. Some code might do something funky with alignment, or it might encode a pointer as an int, or some other bugs are going to happen.

Do you have a specific reason to follow this course?

You have the cost of maintaining multiple branches, testing multiple branches, doing fixes on multiple branches, releasing multiple branches. Do you have a reason for incurring this cost?

For most games PC games right now the choice is either 32-bit because you can, or 64-bit because of good reasons. Trying to take both options is probably a bad decision without some very strong business case for it.


Assuming you have a reason, why do you need to do this dynamically? Either you install the 32 bit version or you install the 64 bit version. People are not going to change their operating system mid-game. You don't have cases where you want the 32-bit version of one library and the 64 bit version of another. "I'd like a 32-bit audio driver, a 64-bit graphics driver, and a 16-bit mouse driver". All or nothing. Either you have the 32-bit version of the game or the 64-bit version of the game.

 

Putting aside the fact that I never mentioned shipping both versions, long story short all the exporters and tools run the libs/dlls from the engine build, certain memory and stability benefits from moving to 64bit tools (3DS max 64/32 Maya 64/32) have created a requirement that I need 64bit everything, plus Id like to future proof, end of story.

 

Now in the case of something like lib png, which I build any way, I suppose I could change the name of the 64bit dll. But in the case of some pre-built binaries where

I dont have the source and they are packaged in folders "x86" "x64" etc. while using the same name Id like to load the correct one for the correct build.

 

Up to this point I havent had many 3rd party libs to deal with, If I need "libpng16.dll" I just put it in the exe's directory. But now I would simply like to sort things into sub folders. With the exception of my dlls, Ive never called load library on 3rd party dlls, theyve simply loaded from the exe's dir.

Now Id like to move them, and Im wondering whats the best way to go about it.

Edited by NumberXaero
0

Share this post


Link to post
Share on other sites

Up to this point I havent had many 3rd party libs to deal with, If I need "libpng16.dll" I just put it in the exe's directory. But now I would simply like to sort things into sub folders. With the exception of my dlls, Ive never called load library on 3rd party dlls, theyve simply loaded from the exe's dir.
Now Id like to move them, and Im wondering whats the best way to go about it.

Again, why not just statically link to them and screw the DLL hell?
What you have listed so far all have the ability to statically link to them.


L. Spiro
0

Share this post


Link to post
Share on other sites


But now I would simply like to sort things into sub folders. With the exception of my dlls, Ive never called load library on 3rd party dlls, theyve simply loaded from the exe's dir.
Now Id like to move them, and Im wondering whats the best way to go about it.


If you don't want to link statically, move your executables into separate subdirectories along with the bit-specific DLLs.

/app/bin32/*32.(exe,dll)
/app/bin64/*64.(exe/dll)

Then you can continue to link with the import libraries and the DLLs will be loaded automatically as normal. As for loading resources and your custom dlls, you can use the Win32 API to determine the directory in which the executable lives and use that as the base for finding the resource directories. Or, since you mentioned PhysFS, it provides a cross-platform way to do this. Look into PHSYFS_getBaseDir. Or, assuming you've configured PHSYFS to put the base directory (or the directory above it, which would be more appropriate in your case) on the search path, you can use the PHYSFS API to load the files and not worry about specifying the full path.


 
1

Share this post


Link to post
Share on other sites

I had the same issue recently. My solution: have batch files that copy all DLLs from a platform-specific subfolder to the executable folder (silently overwriting existing files). For example:

 

xcopy /Y bin/x64/*.dll bin/

 

In your case you'd have one for the 32 bit DLLs and one for the 64 bit DLLs. Run the batch file corresponding to the version you're testing either manually or automatically as a post-build event in Visual Studio.

0

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
Sign in to follow this  
Followers 0