Tech Help Corner

[Penaz91]

If there is something related to the world of game development of coding that I can help with, feel free to leave your question here! I'll try to help as much as possible!

[abreathingcorpse]

Hi Penaz, this isn't actual Game Development related but, while learning C++ I've encountered a Code Example that I've been struggling with for a couple of days now. Thought perhaps you could help me understand it better. It's from tutorialspoint for Operator Overloading. I know that this could be somewhat advanced but still, I'd like to understand it.
I played around with the code here.
I think that I get the idea of most of it, except for a couple of questions:

• Why does the index increase?
• What the heck is (Obj*)0 (I'm guessing this one will be similar to Unix's /dev/null?)

[Penaz91]

However, both i and j do increase. It looks like you have to define the static variables first, though.

You can modify i and j because those are "static fields". They're property of the class itself (thus shared between all instances of the class), not the single instance that is created. (I may be wrong, I'm digging through my old memories!)

I personally always suggest initializing variables (giving them an initial value) or you may end up having unintended behaviours spawning from your programs (on the book there's the "clearing the screen" section with a figure that graphically shows what happens with uninitialized/uncleared memory).

I have one more question now. Why does the -> operator call the f() & g() functions?

I don't think I fully understand the question, but I'll try to pinpoint some common things that may help anyway.

If not overrode, the pointer->method() syntax is equivalent to *pointer.method() (dereference the pointer and call the method). I don't see explicit calls to f() or g().

I've said that (Obj*)0 is functionally equivalent to nullptr but that's actually a massive oversemplification.

(Obj*)0 is still treated as a pointer to Obj, thus you can call any of its methods (but there may be undefined behaviour, in this case you should be safe because f() and g() make calls to static fields - shared between all classes and initialized).

About the last output (and as a consequence, i still being 10): you've hit the difference between the prefix increment operator and the postfix one.

• Prefix (++i) operator increments the value of i, then returns it.
• Postfix (i++) operator does the opposite, it's the equivalent of putting the current value in a temporary variable, increasing i and then returning the temporary variable.

This simple snippet of code should show how it works:

#include <iostream>

int main(int argc, char *argv[])
{
    int a = 10;  // a is 10
    int b = a++; //b is 10, but a will be 11
    std::cout << a << std::endl;
    std::cout << b << std::endl;
}

[abreathingcorpse]

You can modify i and j because those are "static fields". They're property of the class itself (thus shared between all instances of the class), not the single instance that is created. (I may be wrong, I'm digging through my old memories!)

A constant function being able to modify a static member kinda makes sense on my mind because of semantics.

(Obj*)0 is still treated as a pointer to Obj, thus you can call any of its methods

Aah! I see!

If not overrode, the pointer->method() syntax is equivalent to *pointer.method() (dereference the pointer and call the method). I don't see explicit calls to f() or g().

Exactly! The -> operator has been overloaded. and should simply return oc.a[index]. I recall that the -> operator can be used in structs to access members of a class [ref].
However, when the ++ operator gets overloaded one needs to actually define a ++ like behavior within like the oc.a[++index].

In my mind it should work like sp->.f() or sp->->f().
That is, we should require either the . to access a member of the class or an extra -> (not overroaded by the SmartPointer class) operator.
I realize this is not how it works but, perhaps you can understand my confusion better now.

And thank you again, as always!

[Penaz91]

I see what you mean now. That's because sp->f() is essentially (sp.operator->())->f(). [ref]

I don't know enough to say how it works at a low level, but it seems that operator-> gets "passed down" until a member f() is found.

[abreathingcorpse]

I see what you mean now. That's because sp->f() is essentially (sp.operator->())->f(). [ref]

Mindblown! I read this but, at the time I couldn't understand it fully. Thank you, Penaz you are a great teacher!

[Penaz91]

I try my best. Glad that things are somewhat cleared up!

[abreathingcorpse]

I think that I was finally able to understand CRTP.
At least at a first level of understanding.

However, the following example generated a new issue that bugs me.

struct Apple:public Equality<Apple>{
  Apple(int s): size{s}{};
  int size;
};

I understand the struct Apple:public Equality<Apple> but, what about the rest?

Apple(int s): size{s}{} resembles a Class Constructor, while int size resembles, I don't know, a public or private member of a class.

However, the object is defined like so Apple apple1{5};. Which kind of goes against my understanding of how constructors should work. In other words, they are using {} instead of regular (). I also couldn't find anything on the struct section.

I feel like I'm close but, not sure what I'm missing.

[Penaz91]

You're really close, and you're having the right hunch about things. Let me explain a bit more clearly (hopefully!)

Apple(int s): size{s}{} Can look a bit more complex than it actually is, first of all, let's rewrite it in a different form:

Apple(int s): size{s}{
    // Empty Body
}

This helps us distinguishing the body of the constructor from the initialization list (the part after the colon : size{s}). As just stated : size{s} is an "initialization list", it's a more efficient (both in code quantity and speed) way to initialize members of a class, in this case it means that int size will be initialized with the parameter s. Thus it's the faster equivalent of this:

Apple(int s){
    size = s;
}

Now let's get to the usage of braces instead of brackets: that is the new "List initialization" that has been introduced in C++11 ref. In the cases you brought up, it's equivalent to using normal initialization with parentheses.

Hopefully this helps a bit!

[abreathingcorpse]

The refenrece read seems a little too complex for me with my current knowledge but, your explanation was awesome. Thank you very much.

[abreathingcorpse]

Hey Penaz,
The SFML Vertex Array Docs state the following:

SFML provides simple classes for the most common 2D entities. And while more complex entities can easily be created from these building blocks, it isn't always the most efficient solution. For example, you'll reach the limits of your graphics card very quickly if you draw a large number of sprites. The reason is that performance depends in large part on the number of calls to the draw function. Indeed, each call involves setting a set of OpenGL states, resetting matrices, changing textures, etc. All of this is required even when simply drawing two triangles (a sprite). This is far from optimal for your graphics card: Today's GPUs are designed to process large batches of triangles, typically several thousand to millions.
To fill this gap, SFML provides a lower-level mechanism to draw things: Vertex arrays. As a matter of fact, vertex arrays are used internally by all other SFML classes. They allow for a more flexible definition of 2D entities, containing as many triangles as you need. They even allow drawing points or lines.

I figured, since you have your bubblewrap project you might know.

Am I to understand that if I draw a bunch of sprites or Shapes on the RenderWindow then one calls the draw method for each and everyone of them but, when one uses a VertexArray then one may call the draw function once?
Which saves a lot of runtime.

And then it proceeds to show a couple of examples, which are the TileMap and the Particle System.
So, if one didn't use this TileMap, for instance, then one would need to call draw() x amount of times, where x is the size of the map.

Not sure if I'm reading/understanding this right.

[Penaz91]

Essentially a VertexArray allows you to replace Sprites with a more lightweight structure (it's an instance of the so-called "Flyweight Pattern", in a way). Instead of having 10 000 sprite tiles, each with their own image and coordinates, you replace that with an array of coordinates pointing to a single texture (the so-called "sprite atlas" or "spritesheet") and coordinates where such tiles will be drawn.

Instead of drawing each single sprite, you pass the entire VertexArray to a single draw call and save a lot of state checking, matrices etc...

I'm going to put some comments in the bubblewrap project to make things a bit clearer too, hopefully it helps. (I will need them anyway the next time I go check my source code!)

[abreathingcorpse]

Instead of having 10 000 sprite tiles, each with their own image and coordinates, you replace that with an array of coordinates pointing to a single texture (the so-called "sprite atlas" or "spritesheet") and coordinates where such tiles will be drawn.

Aah! So that's how the spritesheet from RPG Maker XP worked!
So you need the coordinates of where everything will be drawn on the map/window as well as the coordinates from what will it print/take from the spritesheet, which is the source.

Instead of drawing each single sprite, you pass the entire VertexArray to a single draw call and save a lot of state checking, matrices etc...

I guess that it does work how I thought it would. Thanks!

I'm going to put some comments in the bubblewrap project to make things a bit clearer too, hopefully it helps. (I will need them anyway the next time I go check my source code!)

Amazing man! I have't opened your project yet, since I didn't even understand the TileMap nor the Particle System examples from the tutorial but, if you are willing to put an effort into making it more readable, then I'm willing to put some effort into understanding your code. Thank you man, your work has really inspired me.

[Penaz91]

I edited the project and added some comments. Hopefully it helps a bit. Feel free to open a discussion over there if anything is not clear!

[abreathingcorpse]

Hey Penaz, hope that you are doing good.

I'm trying to create a prototype, though I'm having trouble implementing a hexmap.
I was able to produce the following:

By creating a CircleShape hexagon, applying it into a RenderTexture then I've applied said RenderTexture with setRepeated(true) into a Sprite, which is finally printed into the RenderWindow. Hope I made sense there.

So, the problem is that's not how hexmaps work. Since by doing it this way, some hexagons are joined by vertices instead of the edges.
Do you happen to have a good source for me to read and understand this problem better? If not, I'll see if I can figure this one out.

[abreathingcorpse]

C++ is a complex language, but luckily it's essentially backwards-compatible all the way to the beginning. Which means that any book you choose will work, you will just miss the newest tools.
I personally suggest anything newer than C++11 due to the presence of unique_ptr and shared_ptr which make things A LOT easier when it comes to dealing with pointers (they're the so-called "smart pointers")

According to this, the book does have shared_ptr, unique_ptr, and weak_ptr. Just ordered it, YOLO.

Let me know whenever there's a new version. I'll make sure to read it and let you know what I think.

[abreathingcorpse]

Hey man! I've already got the book.
I've only just read the Preface. Didn't feel like I learned anything new except for better std::cin usage. Guess it's something.
One has got to start somewhere.

I tried refactoring my code once again. I feel like going back and fort between the prototype and the book would be the best way to go.

I've encountered the following issue, you might have the answer to this.
I have a matrix of Vector2f. One may manipulate this easily from within the main() however.
How could one pass a matrix as an argument to a function and how could one return this?

If it's not as straightforward, I'm pretty sure that I'll encounter this in the book eventually.

[Penaz91]

Hello there!
There are two main ways that come to mind, which are "pass by value" and "pass by reference (or pointer)".

Considering you're working with a matrix, I will assume you're working with pointers, which brings us to the "pass by reference" method.

In this case you're not passing the entire matrix to a function, but merely the pointer to where such matrix is located in memory and you can edit it from the function itself, thus the "caller function" will see the edited matrix after your function is called.

Sometimes this is called using "side effects" in C++, which can be dangerous if abused (you can have void functions modifying values, which is not great).

Here's a quick example:

#include <iostream>

/**
 * @brief Takes a pointer to a number and increments it via side-effect
 *
 * @param num Pointer to the number to edit
 */
void edit_number(int* num){
    *num = *num + 1;
}

int main(int argc, char *argv[])
{
    // We create a new integer on the heap, this will return a pointer
    int* x = new int(5);
    // We print it
    std::cout << "This is a number " << *x << std::endl;
    // Now we call the editing function, look at its signature: it's void, thus it has no return value
    // it will work purely on the pointer
    edit_number(x);
    // Now the number has been incremented
    std::cout << "This is the new number " << *x << std::endl;
}

Working with pointers works with arrays (and thus matrices) too, since array[i] is usually a shortcut for *(array+i), this example should help:

#include <iostream>

int main(int argc, char *argv[])
{
    int x[5] = {1,2,3,4,5};
    std::cout << x[2] << std::endl;
    std::cout << *(x+2) << std::endl;
}

Hopefully this helps a bit, let me know if something is not clear and I'll try to help as much as possible!

[abreathingcorpse]

Hello Penaz,

I was able to Refactor the code about three days ago. Forgot to let you know.
Thank you very much, your explanation was very helpful.

[Penaz91]

I'm glad my explanation helped you!