Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jun 2004
Offline Last Active Today, 03:21 AM

#5311373 Why do most people recommend Python

Posted by on 19 September 2016 - 03:49 AM

C++ is also great and definitely super useful. There are also loads of resources out there, but it has no real recommended best way of doing things. It's a multi paradigm language, where as most try to stick to a certain paradigm like OOP, functional, prototype based, purely procedural, ...

Different resources will constantly contradict each other. This is not a bad thing (in fact, I think it is a good thing), but it can be very confusing to beginners and adepts alike.


But ultimately it's up to you. No language will  make learning to program super easy, because it is hard and takes more than a lifetime to master. All the starting language can do is to move common pitfalls that cause frustration when learning out of the way. Even if a language manages to hide a certain complex topic away really way, at some point you'll need to tackle this topic. There's no escape, all abstractions are leaky! :)

#5311357 Why do most people recommend Python

Posted by on 19 September 2016 - 02:41 AM

People recommend Python because they hear other people recommend Python.


It's not a bad choice and it's available for free on pretty much every platform and there are tons of resources available.

I don't think closeness to spoken language is a good thing, it just leads to more confusion. Otherwise, everyone would recommend COBOL. :)


Personally, I prefer strongly typed languages and would recommend starting with C for system level programming or C# for application level programming.

They are also available for free on pretty much every platform and there are also tons of resources available.


I would not recommend Swift. It is not very well established and is still changing rapidly. It is really only useful in an Apple environment, and Apple wants to move its users as far away as possible from mainstream technology to keep their scent of exclusivity. Also, since it is still relatively new and not widespread at all, the number of resources at ones disposal are also limited.


However, as you correctly pointed out, ultimately all programming languages uses similar context, because they are abstractions of how computers work. So, if a language teaches you programming concepts and how computers work, it will be fine.

#5310487 GameObject class doesn't draw a image but a white box instead

Posted by on 12 September 2016 - 12:51 PM

Oh, I see. Did some more reading on it and I (finally ^^) understand. Thanks a lot for the help



#5310222 GameObject class doesn't draw a image but a white box instead

Posted by on 10 September 2016 - 03:47 AM

I think the fundamental confusion for you here is, that in C++ there's a difference between these two cases:

Case 1:

MyClass myObject = MyClass(12345); // calls the MyClass constructor

Case 2:

MyClass myObject; // calls the MyClass default constructor

myObject = MyClass(12345); // creates a temporary MyClass object, copies it into myObject and destroys the temporary again


When you write a constructor that initializes members in the body and not in the initializer list, like you did in MainMenuState, you have Case 2.

Besides being a bit inefficient this usually is no problem, unless MyClass cannot be copied safely, as is the case with sf::Texture.


For this reason, I discourage the use of the "initialization written as assignment" notation, so this situation can never arise:

Case 1:

MyClass myObject(12345); // calls the MyClass constructor

Case 2:

MyClass myObject; // calls the MyClass default constructor

myObject(12345); // compile error!


In additon the NonCopyable idiom I referred to earlier should be used to make it impossible to unintentionally copy objects of classes that can't be copied safely.


Here's a longer example illustration the issue, I've written and tested it here, so you can just paste and run it.

#include <iostream>

using namespace std;

class InternalTexture
    InternalTexture() : data(123456) { }
    int data;

class Texture
        : internal(new InternalTexture())
        cout << "Texture::ctor" << endl;
        cout << "Texture::dtor" << endl;
        delete internal;
    InternalTexture* internal;

class Sprite
        texture = Texture();
    Texture texture;

int main()
   // Case 1:
      cout << "Texture only:" << endl; 
      Texture texture = Texture();
      cout << "texture.internal = " << texture.internal->data << endl;
   // Case 2:
       cout << "Texture in sprite:" << endl;
       Sprite sprite;
       cout << "sprite.texture.internal = " << sprite.texture.internal->data << endl;
       // crash in Texture::dtor
   return 0;

InternalTexture can't be copied safely, so Case 2 will fail. This is what I think happens inside sf::Texture, although the implementation there is more sophisticated as it knows that it refers to an invalid "InternalTexture" and handles it by that dreaded white square.


You can try to fix Case 2 be doing one or more of these:

1) Fix "Texture", by correctly applying the "rule of 3" (look it up) and implementing copy constructor and copy assignment operator

2) Fix "Texture" by making it "uncopyable" by making copy constructor and copy assignment operator private (NonCopyable idiom)

3) Fix "Sprite" by correctly using initializer lists to initialize its members. Note that Sprite would need to be fixed by applying 1 or 2 as well.

4) Make everything way more complicated (and fun!) by learning about C++ 11 move semantics


I hope that helps!

#5309408 GameObject class doesn't draw a image but a white box instead

Posted by on 04 September 2016 - 12:40 PM

The code looks complete now and you replaced inheritance with composition, great!


What struck me when reading it is, that you copy the Sprite once in the GameObject constructor. Here you should really use initialization lists when initializing members in a constructor, and that might also be the cause of the issue.


Here's how to initialize a member without making an extra copy:

GameObject::GameObject(std::string m_texturePath, float m_x, float m_y)
	: _sprite(m_texturePath, m_x, m_y);

I don't know much about SFML, so I took a quick peek at the documentation. Google took me here: http://www.sfml-dev.org/tutorials/2.0/graphics-sprite.php


Curiously it has a section talking about the "white rectangle problem", which tells you that you have to manage the lifetime of sf::Texture instances very carefully. That's not very beginner friendly, but I'm sure they had their reasons. Unfortunately it seems that they didn't put any measures in place to stop people from committing this mistake.


So, given the fact that you (probably unintentional) copy both the sprite and the texture around, it is unlikely that their internal state is still consistent. The above code snippet should fix that.


Bonus info: If you have a class that can't be copied safely, like your Sprite class, you can emply the non copyable idiom to get the compiler to tell you if you do it by mistake:



I hope that helps!

#5309395 GameObject class doesn't draw a image but a white box instead

Posted by on 04 September 2016 - 10:02 AM

Let my start of by concurring with the previous posters about your apparent architectural choices.


Now on to the thing you actually asked about. Unfortunately, the code you provided is incomplete and misses details needed to accurately diagnose the problem.


A stab in the dark:

The constructor sets the position of the sprite, the Create method does not. I can't determine what the default position is, but it might just be off screen...


Some questions that might help with the diagnosis (if you don't want to post all the relevant source code):

Where is "_created" initialized?

How is the GameObject you call Create on created?

Does GameObject have a default constructor?

What does it do?


Some general hints:

Pass non trivial objects like std::string by const reference and not by value.

Checking m_x and m_y for NULL seems confusing. It's will just check if their value is equal to 0.0f.


I hope that helps!

#5300561 c++: replace word in char array?

Posted by on 13 July 2016 - 10:08 AM

Sounds like a homework assignment to me, so I'll try to be vague.


If you are not allowed to use existing helper functions, you have to implement your own.


To solve this you need 3 functions:

1) find the length of a string, like strlen

2) find a string inside a string, like strstr

3) copy a part of one string to another, like strncpy


If you are stuck with the interface you described and have to work with that one char array given, you'll need to be extra careful not to stomp over input you still need.


I hope that helps.

#5281063 how could unlimited speed and ram simplify game code?

Posted by on 13 March 2016 - 12:17 PM

Maybe frame the question in another way: Many programmers, gameplay or otherwise already act as if there was more performance and memory than there actually is. A tiny group of programmers then have the ungrateful, but often fun job to bridge between perceived reality and apparent reality. These programmers would not be needed anymore. ;)

#5279519 Class 'Virtual' question

Posted by on 04 March 2016 - 12:46 PM

Yes you can!!

Indeed, that's a case of B hiding something it inherits from A. It's not good practice because it can be rather confusing. Some compilers will emit a warning.

#5279439 Class 'Virtual' question

Posted by on 04 March 2016 - 04:19 AM

You are mixing up nomenclature here, making your question hard to answer.

So let's get that out of the way by making two definitions:
Type: a class, struct or simple type (int, float,...) definition
Instance: a named, usable instance of a type

Now the answer:
Types can be derived from other types, and when that happens, members can be added, overridden and hidden, but never renamed or removed.

Instances are of exactly one type and contain exactly what is defined by the type definition, not more, not less.

I hope that helps!

#5277271 make c++ more like glsl

Posted by on 21 February 2016 - 05:50 AM

Here's a long discussion on that topic with a couple of possible solutions.




But the bottom line is that there is no good way to do it in C++ without extending the language.

#5253257 C++ Question About Objects

Posted by on 21 September 2015 - 01:51 AM

Hello, you're mixing up a couple of things.

Firstly, you want to do stuff on the same line. This is easier than you think:

Level level; level.Load("level1");

Tadaa! However, in general, it is more readable to use shorter lines, especially since debuggers usually work on a per line basis. So, stepping through the line above will likely be quite awkward.


Secondly, you're talking about new, constructors and destructors.

Let me try to untangle this a bit.


Whether you use "new" or not, an objects constructor and destructor will still be run (if it has any). So they don't have anything to do with the use of "new".


Instead, "new" will change where the object will life and therefore influence it's lifetime.

In short, without "new", the object will live until the current scope ends (at the next "}"). With "new", the object will live until "delete" is called on it.

For a more detailed explanation, this looks to be fairly comprehensive:



For the sake of completeness, here's how the above example would work with "new", again as a single line.:

Level* level = new Level(); level->load("level1");

I hope that helps!

#5249673 Why there no "Religion" Simulators?

Posted by on 30 August 2015 - 02:44 AM

I think Civilization V does a good job at exploring the global impact of religions. Another example would be Black & White, showing religions effect on primitive cultures.


On a personal level, many RPGs explore various aspect of the religious lifestyle. For example Leliana's or Cassandra's story in the Dragon Age series, especially part 3.


In addition, there are many games that deal with aspects of religion via satire, which can be very entertaining indeed.


I don't think it would work as core gameplay element though.

#5249579 Screen space scissor rect of a cube

Posted by on 29 August 2015 - 09:05 AM

Stencil buffers are not an option because stencil testing is done after the pixel shader is executed and since the execution of the pixel shader takes a relatively long time, this would not increase performance.


Nope, stencil ops (like depth ops) are done before the pixel shader is run, unless the pixel shader contains stencil or depth instructions itself (which is not very common). Maybe you mistake it with alpha test, which is indeed run after the pixel shader, because it depends on whatever the pixel shader outputs.

#5249554 Screen space scissor rect of a cube

Posted by on 29 August 2015 - 06:36 AM

I think the correct way to handle the camera inside cube problem is to dissect the cube using the near clip plane, before transforming it. But the result is no longer a cube, so it's not very straight forward.


But why don't you just build geometry of the cube and render it using your post processing shader? This way the GPU / driver takes care of all that complicated clipping business. If you turn culling off, it will work even when the cube intersects with the near clip plane. If that, for some reason, won't work, you can still render the cube with an empty shader and write to the stencil buffer and you basically have what you did before, but faster, easier and more exact.


I hope that helps!