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

C++ - do you use STL in your game?

33 posts in this topic

Direct, idiom free translation:
[code]

#include <vector>
#include <cstdio>
#include <cstdlib>

int main()
{
std::vector<int> numbers;

for(unsigned i = 0 ; i < 20 ; ++i)
{
numbers.push_back(std::rand() % 50);
}

for (unsigned i = 0; i < numbers.size(); i++)
{
std::printf("List[%i] = %i\n", i, numbers[i]);
}

for (unsigned i = 0; i < numbers.size(); i++)
{
if (numbers[i] % 2 == 0)
{
numbers.erase(numbers.begin() + i);
i--;
}
}

for (unsigned i = 0; i < numbers.size(); i++)
{
std::printf("List[%i] = %i\n", i, numbers[i]);
}
}
[/code]
0

Share this post


Link to post
Share on other sites
[quote name='rip-off' timestamp='1337006302' post='4940091']
[quote]



[left][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][background=rgb(250,251,252)]Your original posts said one should not use lists at all, not that vectors are usually better.[/background][/size][/font][/color][/left]

[/quote]
Please quote where I said that.
[/quote]

[quote name='rip-off' timestamp='1336996225' post='4940024']
[quote]
... your linked lists, trees, etc., rather than just using LinkedList<MyClass> (or whatever the STL syntax is).
[/quote]
If you're worried about performance, you should strongly consider not using linked lists at all.[/quote]

(My apologies if I misinterpreted what that first quote meant.) Edited by mdwh
0

Share this post


Link to post
Share on other sites
I fundamentally disagree with your characterisation of the words I said. I believe "strongly consider not using lists" more closely matches "vectors are usually better" than "not use lists at all". That is what I meant, and that is what the words actually mean, as I understand.
0

Share this post


Link to post
Share on other sites
[size=3][font=arial,helvetica,sans-serif]Which is better...that part of Standard C++ formerly known as STL or your own?[/font][/size]

[size=3][font=arial,helvetica,sans-serif]This is a common query and I doubt anyone has the definitive answer because what was once known as STL covers quite a wide range of concepts. Likely any one individual has only a very limited use for and knowledge of a subset of it, even if that's a large subset. I don't think it's possible for anyone to really be an expert across the entire STL because I doubt any single person has used every single feature.

It's important to understand this...because people should expect quite a varying range of opinions and you need to consider the subset of functionality that is relevant to your own work. For game development, we’re really only talking about a few specific types of containers that are relevant to run time. Tools are fair game for a much wider range of needs.

Once upon a time, at least to settle this query for my own purposes I considered the subset that I would use normally, discarding concepts I would never use and features I would never really be interested in during my life as a game developer. I looked deeply into the implementations I was interested in and tried to see if I could improve on them performance wise.

What I found was that most implementations were quite well developed and were quite efficient - at least as much as they could be. There was very little room for direct optimization, which wasn’t even worth the effort. For the optimizations that were possible...typically they'd be related to the deployment/use and as such would also be necessary if you were to take the ‘rolling your own’ containers option anyway or the optimizations were possible only by removing features to allow corner cutting.

The latter were more interesting to me because clear performance (and memory) wins were easy and possible via this route. This should surprise no one though…because the outcome of removing features is a more specialized case and as we all know, specialized cases will generally be more performant than generic ones. I actually don’t find too much fault with STL for being generic and flexible either – that’s kind of the point of it. I should also add that programming IMHO is often about making trade off decisions and sometimes generic/flexible is just a better choice anyway.

Unfortunately, this result did give me the excuse I needed to continue using and maintaining my own containers because I don’t need to give clock cycles away anyway. However, before the haters applaud I will also add that while such exercises do provide measurable gains at the instruction level please bear in mind that the % of time your program counter is iterating over such instructions is very minimal. The gains you’ll see to your frame rate by such techniques are often not going to be as noticeable.

I should also add that while I do use my own containers, that wasn’t an excuse for me to throw STL containers away. I still use them actually, particularly in code that I share with others or in code that needs to be more flexible.

A TL/DR version, which is also roughly the takeaway from my own research[/font][/size][list]
[*][size=3][font=arial,helvetica,sans-serif]In rolling your own it’s easy to make performance gains, but you’re not really optimizing STL – you’re removing features and making something else. Apples and oranges don’t really compare.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]I did make some memory gains too, as I briefly hint at above. [/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]The more features you add, the more the gap will close on any gains you made - the more pointless having your own will be.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]If you can live without those features the performance gains are worth it at the instruction level.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]The same performance gains have limited worth overall, largely due the time your program counter is in these so called problem areas. Or…there should be bigger fish to fry when you look at your performance profile.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]It is possibly worth using your own to gain maximum performance for your run time regardless (as I say above…why thrown cycles away).[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]Rolling your own is an interesting exercise, particularly if you do look at the existing implementations. You’ll learn a lot about them and I think make wiser decisions for having that knowledge.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]Rolling your own with the intention of supporting all the same features is pointless. Things will exist in your version for the same reason they exist in vendor versions, which have already been optimized as they are. You really will be reinventing the wheel here and you’ll do that via creating a less optimal wheel at least in the first instance.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]Where you don’t need performance, the only possible need to use your own might be for reasons of consistency and not using two different types of containers.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]It’s my opinion that your tools/pipeline and generally your higher level code are better off using STL/standard C++ library containers though. Why?…[/font][/size]
[list]
[*][size=3][font=arial,helvetica,sans-serif]They are more flexible and this sort of code generally needs to have that benefit[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]The same code will be more maintainable due to using something more flexible[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]Because they are standard and everyone should know them. Not everyone will be aware of the nuances of your own version, even if it’s a version shared amongst several people.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]The advantage of the alternative has no place here.[/font][/size]
[/list]
[/list]
[size=3][font=arial,helvetica,sans-serif]YMMV of course.[/font][/size] Edited by freakchild
1

Share this post


Link to post
Share on other sites
traits and algorithms only (in particular sort). The generic containers are more or less banned, though a bitset has managed to make its way into our codebase since its such a pain to write one that scales up into the hundreds of bits.
0

Share this post


Link to post
Share on other sites
[quote name='Promit' timestamp='1339638444' post='4949011']
The biggest rule of thumb is this: [b]If you have to ask, you should use STL.[/b]
[/quote]
Quoted for emphasis; that is an [i]excellent[/i] guideline.
2

Share this post


Link to post
Share on other sites
I don't ever use the STL, period. Not even when time is tight and I just "need to get it done". But then again I am a die-hard [url="http://en.wikipedia.org/wiki/Common_Lisp"]Lisper[/url], so... take it for a grain of salt. Edited by Conoktra
-2

Share this post


Link to post
Share on other sites
@Conoktra: that's not really helpful in a discussion that specified C++ up-front. Obviously users of other languages won't be using the C++ Standard Library; if one is available they might however be well advised to use the standard library of their language of choice, for the same reasons given in favour of the C++SL in this topic.
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