• 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
RoundPotato

many potatersssss

20 posts in this topic

If you can't figure out how to get boost to work, consider upgrading your compiler. Threading support is now part of the standard library as of C++11. std::thread is largely based on boost::thread and will work out of the box with a C++11 compiler. 

0

Share this post


Link to post
Share on other sites

The purpose of the build process is not to produce source files. The source files already exist and can be found in the libs/ directory of the boost tarball. The purpose of the build process is to produce the static and dynamic libraries for boost with the tool chain specified. Building with MSVC produces MSVC libraries and building with gcc produces gcc libraries. You can't share the libraries between these two compilers for the same reason that you can't share any other C++ object file between them: the ABIs and object formats are incompatible.

2

Share this post


Link to post
Share on other sites

There is no such thing as "typical" way to compile source cross-platform.  You act like this is some simple thing where you copy the source into a folder and viola, it builds.  That's not how truly powerful and low-level cross-platform C and C++ work.  There are cross-platform considerations like processor architecture, pointer size, presence of math coprocessors, etc.  And then there are platform differences related to software, which libraries are present, which versions, which other tools, etc.  There are so many such little details that large, ongoing and complex projects exist solely to deal with these issues - such as gnu autoconf and the dozens of different dependency management systems out there.

 

When someone goes to create something like a THREADING library that works on multiple platforms correctly, what they are really doing is wrapping up dozens of DIFFERENT underlying platform specific APIs, with HUNDREDS of different variations, into something that is as close to a consistent API as possible given those underlying platform's differences.  To this day, there is no such thing as a library that does this perfectly on all platforms ... no matter how you install, configure, compile and use it ... and you act like this should be some "simple" / "standard" thing that requires no thought to use.  C and C++ are NOT like Java, nor .Net, nor Perl or any other newer, higher level language.  They don't hide all the differences of each platform under some some simple common wrapper that makes you able to not care what compiler / tool-chain you are using .. because they expose those differences to you, the programmer.

 

C / C++ standards do not in any way dictate how libraries, projects, builds, etc. are created, loaded, or organized.  They don't dictate a file format, they don't dictate even a linking feature set.  The only thing C / C++ dictate is how to understand SOURCE CODE.  But in the real world, source code depends on platforms and libraries to be useful, and all of this stuff is different on a Mac, onLinux, on Windows 32, on Windows 64 ... and different yet again for various versions and or tools within those larger labels.

 

You have to pick a platform, pick a language, pick a tool-chain and LEARN IT.  Don't assume that every other platform, language or tool-chain should be the same ... learn one, use it ... and learn another someday if you want to.  And don't assume it doesn't take work to learn something.

 

On a separate note, using boost this year is no longer necessary due to C++11, but is probably not a bad idea since it was well supported even before C++11, but within a few years it will simple fade out of existance as everyone migrates to the standard implementation.  The reason this is so is that each compiler vendor (gcc, Visual Studio, Intel, etc.) wants their compiler to make the best and most performant code, and so they will be tweaking the implementations on their platforms ... and also, the whole point of a standard is to unify everyone's code to 1 version.  And while there are custom libraries for special cases of EVERYTHING, when was the last time you thought to look for or learn an alternate to the C++ standard IO library, or template library, or math library?  NEVER.  Because it would be a complete waste of your time for 99.9% of all imaginable cases.

2

Share this post


Link to post
Share on other sites


I tested it under dev-c++

Dev-C++ is long dead, a quick search shows the last update was in 2005 and that there are several hundred known major bugs.
 

There are many free alternatives out there.  Visual C++ Express Edition, Code::Blocks, clang, and more. These are current compilers that are maintained and support the updates to the c++ language.

 

All of those compilers support threading out of the box since the new C++ standard includes a threading library.

 

Just as a side note but dev C++ latest stabel is from this year, someone took the project over in 2011. That being said you might stil be better off with a newer compiler as C++11 support will be better in those.

0

Share this post


Link to post
Share on other sites

Some things that might help...

 

Regardless of IDE you use, you can get a decent build of g++ for Windows from here which supports the latest standard.

You need to make sure you are compiling with -std=c++0x or -std=c++11 in order to access the newer functionality.

 

I recommend modern C++ pretty much for better smart pointers to handle the threads (i.e custom deleters for shared_ptr) however, I find that pthreads on UNIX and pthreads-win32 for Windows to be perfectly usable and portable between almost any C++ compiler on any platform.

 

Also... you can still have a server listen and action connections without threads by using a polling type system (via poll(2) or select(2)). The only thing you will need to pull in threads for is if you want the same program to act as a server and a client (i.e to connect to its own server (i.e like Quake 3)).

 

Tbh, you shouldnt really need boost at all for this. Very similar to when people keep suggesting jquery to javascript developers for menial tasks, God kills a lovely fluffy kitten each time. (Sometimes boost *is* useful, in which case the kittens life is forfeit but that time is not now ;)

Edited by Karsten_
0

Share this post


Link to post
Share on other sites

boost.threads provides an interface much like what you'd expect of the C++ Standard Template Library, which make it a good choice for people who like the conventions used by STL.

However, many game development frameworks (including SDL and SFML) already include functions to create and use new threads.

In reality, most thread APIs are more-or-less equivalent in terms of actual utility. If you're already using a library that includes it, or has a first-party extension library for it, I'd simply use their interface.

0

Share this post


Link to post
Share on other sites

Thank you for taking your time to answer.

 

I was going to ask about how is that the case until I re-read SiCrane's post a few times and "googled" "ABI". It seems it cannot be as I expected it to be due to different implementations of an application binary interface for each compiler even on the same OS, correct ?

 

So to confirm I cannot test it in an efficient and fast way between OSs and compilers, the solution would be to compile the library for each compiler and for each OS ?

 

 

 

 

P.S I "act that it is simple" because I do not possess enough knowledge of the low-level interworking and nothing is left but to imagine it from what I know. sleep.png

 

Yes, every compiler compiles different, the assembly code is not (without luck) the same, else there would only be one right?

 

Sometimes code might work for more than 1 OS, but sometimes code that works on win-7 doesn't work on win xp, due to WIN API changes or things none wants to know. You better choose an updated IDE and a OS you want to test your code on.

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