my book has some good exercises, and I am on ch12 of ch23 over ½ way through. I hate to give up now.

Lists only make sense when you need O(1) insertion and deletion, something you don't get with vector (unless you do your own swap n pop).

pbivens67 said:
my book has some good exercises, and I am on ch12 of ch23 over ½ way through. I hate to give up now.

Your book is probably fine for learning the programming language. Probably not the best, but adequate.

You happen to be learning a container in the language that isn't used often, and is quite rare in games. It's not used often but it does have some uses. It's fine to learn about things that are seldom used.

Please guys, don't throw expert knowledge about how to write effective code for games in the thread.

The OP hasn't made the transition from hard-coded values to using stored data yet. Give the OP a chance to get used to having data structures first, before getting worried about O(1), performance, and more advanced tricks.

Alberth said:
The OP hasn't made the transition from hard-coded values to using stored data yet. Give the OP a chance to get used to having data structures first, before getting worried about O(1), performance, and more advanced tricks.

Yes!

But i wonder if learning about STL containers or algorithms is at all helpful to get there.
I mean, say we have a bunch of enemies and bullets in a Space Invaders game.
We could now discuss if it's better to store those things in vectors, lists, or just arrays. We could discuss what's easier to use, what's faster, etc.
But then we only dodge the first question, which should be:

How can i move from hard coded variables and magic numbers to data structures, so i can handle multiple objects of the same type, and so i can even add or delete some objects at runtime?

Likely we want to make Enemy and Bullet structs or classes, and we need to think what variables such struct needs to have.
I recommend to start using such structs or classes for pretty much everything. Anytime you want to declare a new variable for something, consider to wrap the variable, plus some others related to the problem, into a struct.
You may end up overusing data structures, but you shall also find obvious advantages. And after some time using data structures should become second nature.

Example:

You often show code like this:

glVertex(playerX, playerY, 0);
glVertex(playerX+10, playerY, 0);
glVertex(playerX+10, playerY+15, 0);
glVertex(playerX, playerY+15, 0);

I saw this really, really often. You write such code 10 times a day it feels. Always quite the same process. Drawing a rectangle.

So what you need to do is writing a Rectangle data structure containing variables such as left, top, width, height. Plus a function RenderRectangle(const Rectangle &rect).
You write such code into it's own files, so you can include and use them in multiple projects. Your projects now include more files, but it's much less code. Less code means you can manage more complexity than you could before using data structures.

But there is ofc. devils in details making this harder to adopt than it sounds.
E.g., you need to decide:
Should i use (left, top, width, height), or (left, top, right, bottom), or something else using a center?
Should i add texture coordinates as well? A texture id, colors? Should i make multiple structs or classes to support such variants, and if so should i use inheritance to prevent duplicated code again?

Such questions always come up, eventually late, and you may often regret decisions you have made earlier.
This sucks and only experience will help, but it's still much better to deal with that than writing similar code again and again and again.

Learn by doing.
I doubt a C++ book focusing on the language explains such basics at all, but they surely use some custom data structures in their examples. Pay attention and observe how their use of structs and classes causes much less code than you would have written.

I'll give reasonable [read “opinionated” ;) ] answers to some of the questions:

> Should i use (left, top, width, height), or (left, top, right, bottom), or something else using a center?

Either way is fine. I would start with whatever the graphics library expects, but I might change it in the future. (left, top, right, bottom) means you have to update four numbers instead of two to update the position, so probably not that one. I might also just use complex numbers for positions and use one of them for the center of the object, because that matches the way I think about 2D geometry, but this would probably confuse most beginners. Just do something that feels natural and write a comment being clear about your design decision.

> Should i add texture coordinates as well? A texture id, colors?

Make a struct with the information you need to render the rectangle, and add to it as needed.

> Should i make multiple structs or classes to support such variants, and if so should i use inheritance to prevent duplicated code again?

Probably not, and hell no. I would try to keep things simple by keeping all sprite rendering uniform: If something needs texturing in the game, probably everything needs texturing, and if it doesn't you can use a flat-color image as your texture. If this simplistic design breaks in the future, then we can think of more sophisticated solutions. Using inheritance and polymorphism is a neat trick in some situations, but it's too easy --and not only for beginners-- to end up going overboard and constructing some monumental hierarchical structure that ends up getting in the way of having the code be understandable (you'll have to open 10 files before you find a line of code that does something, as a friend of mine puts it). We went through a couple of decades where everything was "object oriented" and this problem was very common. To me it's as bad as spaghetti code from BASIC programmers in the 80s, with GOTO all over the place.

I figured out my problem, thx for all the help.