Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Mar 2006
Online Last Active Today, 09:39 AM

#5198430 Do i have to make basic games again after break in gamedev?

Posted by Aardvajk on 15 December 2014 - 04:20 PM

If I say start from scratch, are you pleased or disappointed? If I say pick up where you left off, are you pleased or disappointed?


Do whichever one makes you pleased :)

#5198398 Minimalist Programming Environment

Posted by Aardvajk on 15 December 2014 - 02:20 PM

Nothing wrong with wanting minimal if you aren't billing your time. Went through a big phase of that myself.

I second QtCreator if you can tear yourself away from the command line. Doesn't feel bloaty at all and can be set up to work with VC compiler.

I use it for all my non-Qt projects too now and love it. I was a big fan of VS before but I've not had VS installed for years now.

Nothing against VS of course. I was forced by my job to get into QCr and just found I preferred the light weight feel.

#5197805 Is there a better way for putting game logic in beginContact

Posted by Aardvajk on 12 December 2014 - 10:31 AM

Just to expand on the last comment, you can also look at the slope of the current floor and do a bit of trig to work out the minimum distance from the base of the capsule to the floor to consider the player on the ground.

The distance along a ray from the middle of the base of a capsule to the floor is longer the more sloped the floor is.


I wrote a journal entry about this a while back. Its proven a useful technique when locking a capsule character controller to the floor so I hope it is of some interest:



#5197410 "defer": is this silly / broken?

Posted by Aardvajk on 10 December 2014 - 11:26 AM

I was a but facetious actually. Sorry. Was quite unnecessary.

I personally dislike any kind of trickery to try to "extend" C++. It always seems to end in tears.

But if this is useful in a project where a concern isn't the future comprehension of other programmers, it is an interesting use of lamdas and templates.

#5196823 Why is math transformation taxing to most CPUs?

Posted by Aardvajk on 07 December 2014 - 01:40 PM

I think in the context of point 1), point 2) reveals a certain lack of understanding of the role of GPUs on the part of the author.

Matrix transforms for tracking object positions on the CPU for, for example, culling or physics would not run into the millions per frame unless you had a world with a very large number of objects in it.

#5196481 NULL vs nullptr

Posted by Aardvajk on 05 December 2014 - 01:23 PM

Ambiguous overloads are harder to avoid with overloaded operators. Consider ostream <<. Has to have both int and pointer overloads.

I was under the impression from a Microsoft interview with one of the VC developers that nullptr was required to allow perfect forwarding to work with varadic templates.

#5180245 Preprocessor query

Posted by Aardvajk on 14 September 2014 - 09:28 AM

Got it working a treat, thanks.

#define _lock_flag_helper_final(a, b) flag_lock_object _flag_lock_object_##b(a)
#define _lock_flag_helper(a, b) _lock_flag_helper_final(a, b)
#define lock_flag(a) _lock_flag_helper(a, __COUNTER__)

#5179060 std::unique_ptr issues

Posted by Aardvajk on 09 September 2014 - 05:34 AM

I came across something similar recently and found adding a blank destructor to the owning class, with its body defined in the .cpp after the inclusion of the full header meant I could just forward define the type in the header and declare one of these templated pointers. As soon as I remove the destructor from the .cpp and let the compiler auto-generate it or have it stubbed as an inline empty destructor, the warning comes back.

So yes, it is to do with when the compiler generates the destruction code. The full class needs to be visible at that point, but (on GCC at least) if you have a (possibly empty) destructor in the .cpp that seems to fix it.

Not sure if this is fully defined behaviour or not though.

Really its like this:

class B;

class A
    ~A(){ delete b; }

    B *b;
Clearly not going to work as b is undefined at the point of the delete.

class B;

class A

    B *b;

// cpp
#include "B.h"

A::~A(){ delete b; }
Is clearly fine. The fact you are using template smart pointers is kind of irrelevant really.

#5178672 GOTO, why are you adverse to using it

Posted by Aardvajk on 07 September 2014 - 06:48 AM

The example Alvaro provided me is, to my mind, an example if a badly designed method. That double level loop would better suit it's own function, with a return instead of a break. It is highly unlikely that you will only search the deck once in a program and the flow would be far easier to understand.

Goto seems to me to be a symptom of the wider problem of not breaking methods down into cleaner, more focused parts.

#5176236 Declaring std::String Causing Segfault

Posted by Aardvajk on 26 August 2014 - 11:28 AM

No you aren't. There is nothing in the posted code that would segfault (your using std::string is redundant but that is all).

Something is screwy with your machine or installation. Are you maybe building a 64 bit app for 32 bit windows? Does the program not segfault if you remove the string stuff and just cout a string literal?

#5175511 So... C++14 is done :O

Posted by Aardvajk on 22 August 2014 - 10:55 AM

A good example of a change is the addition of . I rarely if ever use int or short anymore, its now all uint16_t or int64_t. I know what I'm getting and I know their limits. I can use them without tons of asserts to std::numeric_limits. Apart from little-big endian issues, which only really crops up when serializing data, they are portable.

And your code is thus non-portable to a platform with a different native word size. Cuts both ways.

Is this of any practical relevance? Do you know of any platforms where those types are not available? Any platform that matters? I mean, maybe there is a washing machine somewhere that won't be able to run my game, but I can live with that.

No, of course not. Just making the point that portability is a more subtle issue than using <cstdint> and certainly not something that would be helped by a standard implementation of the standard library. My actually meaningful comments were made in my previous response but seems the original poster of this idea chose instead to focus on this and no longer wishes to discuss it.

#5175447 DeltaTime and acceleration

Posted by Aardvajk on 22 August 2014 - 05:27 AM

Hum ok, i'll see. And if I don't wan to fix the timestep, wich is the case in many games ?


This was the case in at least one mainstream game I heard of (I think it was Quake 2) and as a result, there became a known exploit that players on faster computers could jump higher and further, which became an issue in multiplayer.


I'm not sure why you think a fixed time step is not the case in "many games"? Where are you getting that from? This isn't something you can tell from playing a game (other than deducing its absence as the cause of bugs).


Fix your physics timestep. Seriously. There are no good reasons not to and many good reasons to do so.

#5175426 So... C++14 is done :O

Posted by Aardvajk on 22 August 2014 - 01:38 AM

My feeling is that if the committee can't write clean, efficient, proper C++ code, how they hell are we supposed to be able to?  If the committee can't write a simple vector implementation, then they need to get back to the drawing board and figure out why they cannot, rather than just pass the buck onto the vendors.


I'm pretty sure the reason the guys on the committee don't enforce and author a standard library implementation isn't because they aren't capable of writing it.


It would be silly if they said "This is the standard library code that MUST be supplied for this to be a standards compliant C++ installation". For a start, that would stop individuals or groups coming up with internal improvements to the standard library which don't affect the interface. It also means that a compiler vendor would not be able to take advantage of their own compiler specific features under the hood of the standard library which they are free to do as long as the interface is presented and it all behaves "as if".


I'm not really sure what you think the advantages to what you are proposing are, but there are a raft of disadvantages.

#5175217 Destructor in vector called too often

Posted by Aardvajk on 21 August 2014 - 03:48 AM

Just a thought, but try changing the optimization settings. At work we've found some bugs in GCC (reported) using -O3 and had to manually add the flags -O3 adds minus the one that was causing the issue.

#5175122 Destructor in vector called too often

Posted by Aardvajk on 20 August 2014 - 03:36 PM

I just tested your code with GCC 4.7.2 (Windows)

AttributeDeclartion() called.
AttributeDeclartion() called.
AttributeDeclartion(const AttributeDeclaration& decl) called with this: 8595680
and decl: 2686698.
AttributeDeclartion(const AttributeDeclaration& decl) called with this: 8595681
and decl: 2686699.
~AttributeDeclartion() called with this: 2686699.
~AttributeDeclartion() called with this: 2686698.
Initializing vector done.
~AttributeDeclartion() called with this: 8595680.
~AttributeDeclartion() called with this: 8595681.
Press <RETURN> to close this window...

So no duplicate destruction of the same object in there.


So perhaps this is a bug with initializer lists in VC, I dunno. Are you seeing the destructor message with the same value for "this" more than once in your output?