Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Mar 2006
Offline Last Active Today, 09:31 AM

#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?

#5174811 Destructor in vector called too often

Posted by Aardvajk on 19 August 2014 - 01:39 PM

When the debugger fails, there is nothing better than a shedload of std::cout << _LINE_. Think you really need a solid grasp on exactly what the program flow is doing here.

Sean quite right of course. A smart pointer can do all this for you.

#5174227 I have this collision detection concept I want to discuss

Posted by Aardvajk on 17 August 2014 - 12:29 AM

To put it another way, sometimes the desire to believe you have invented something useful can blind you to a simpler solution.

#5174055 I have this collision detection concept I want to discuss

Posted by Aardvajk on 16 August 2014 - 02:18 AM

I feel like whatever I say no one will understand. There is literally nothing else like this that has been attempted or if it has it isn't very well know. 


Well, sorry, I have no idea what you mean and if you can't find a way to express it better, its hard to discuss it. Maybe others more familiar with the isometric domain can make better sense of this.


I would say though that given that the isometric part really only applies to rendering (and translating mouse input back to world positions) and you need a 3D representation of your world to allow the behaviour you are asking for, I'm not really sure what difference it being an isometric view makes to the mechanics of collision detection.

#5174053 Mesh collision pushout resource?

Posted by Aardvajk on 16 August 2014 - 02:04 AM

Hmm, I'm trying to understand what the issues with edges and capsules are, since most 3D platform games use a capsule as the main collision shape. My controller uses a base capsule shape, but then does a variety of raycasts to modify the behaviour.


Maybe you can augment the Unity character controller with some raycasting to get the behaviour you are looking for?

#5172491 Would you judge some of my work please

Posted by Aardvajk on 09 August 2014 - 12:59 PM

Thanks for the advise, I think its a kind of dyslexic thing.

With respect, this kind of thing is conceptual and nothing to do with dyslexia.

This is to do with understanding core concepts about when and when not to use dynamically allocated memory.

My concern is you do yourself no favours by dismissing this kind of misunderstanding as something beyond your control. But none of my business really. Good luck.

#5172330 Would you judge some of my work please

Posted by Aardvajk on 08 August 2014 - 12:20 PM

In VecInterpolateMidPoint, why are you dynamically allocating those vectors? Just use normal stack variables. You can still pass them to the D3DX method using the address-of operator:


/* ... */

D3DXVec3Lerp(V_LERP, &vA, &vB, s);

Or, if the second two params aren't modfiied (i.e. are const D3DXVECTOR3*)

D3DXVec3Lerp(V_LERP, &p, &p1, s);

I suspect you might be thinking you need to allocate because these methods take pointers. Not so, its just D3DX is a C interface so pointers are used.


Unnecessary dynamic allocation will bite you eventually when you forget to delete it via one of many possible paths out of a function.