Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Moonkis

Member Since 10 Apr 2011
Offline Last Active Aug 04 2014 02:44 PM

Posts I've Made

In Topic: Problem defining a new 'new' macro

02 February 2014 - 05:53 AM

Since you write that you are on VS2012 and also that you are under a deadline, the effort of writing and debugging your own crude tracker that only works in limited cases doesn't make much sense.

Microsoft's runtime libraries include many useful tools, including the debug memory heap. Suggested reading. You get access to much of it simply by using the _DEBUG compile time option, which is the default for Visual Studio's debug builds. A few of the features require a tiny bit of extra work, but it is both debugged and documented, making it generally better than fumbling your way through by experimentation.

There are some more comprehensive external libraries for memory tracking, but they usually require much more work, including re-compiling all your linked-to libraries from source and other burdensome tasks.

I know there are tons of better, more well established methods. In this case I wanted to learn something. I'm not to found of getting tons of suggestions telling me I can avoid learning anything by just using a library. Don't get me wrong, I appreciate the effort of others, but when everyone says; "Just use <insert lib> instead", It get on my nerves.

However, I got my code to work under circumstances the only problem was I didn't know exactly why it worked or why it didn't work. I actually got the code to work as intended with a single .h and .cpp file.

I put the "#define new new(__FILE__,__LINE__) at the end of the header and right after all the includes in my .cpp file I added #undef new
I haven't ran into any problems with this yet and I'm quite happy with the result.

In the future I guess I should make it clear from the very beginning if I'm interested in alternative solutions or not, in this case I wanted to understand the raw code of it all. 

 

#define DEBUG_NEW new

#define new DEBUG_NEW(__FILE__,__LINE__)

Most articles had something similar:
 

#define DEBUG_NEW new(__FILE__,__LINE__)
#define new DEBUG_NEW

This didn't even remotely work for some reason.


In Topic: Problem defining a new 'new' macro

31 January 2014 - 12:46 PM

To be blunt, this is just a silly way to do things these days.

Even if you get it to work, it'll half the time just give you the file/line of some template code and won't be remotely helpful in tracking down a lot of allocations.

You can rather efficiently look up the callstack and get the return address of the function calling new. Store that. You can take it a step further and store the addresses of the last 5 (or more) call frames. During debug dump commands, you can use the symbol database functions (they differ between OS) to make those address to the file, line, and function name they're located at. All only in debug builds, naturally.

As a bonus, this works with proper C++11 idioms where you barely ever even call operator new yourself.

This can be further combined with a memory context system. This would allow you to not just track that some allocation came from a particular file but allow you to easily print in-game memory reports like seeing which allocations are graphics-related or physics-related or whatnot without needing to make every allocation call tagged. Something like:
 

void render(... stuff ...) {
  MemoryScope("Graphics", [&]{
    // any allocations in this block or any function called by this block are now tagged as belonging to Graphics,
    // no matter what file they're in, unless another MemoryScope is entered.
  });
}
You can use a macro and a scoped local variable if you prefer that syntax over the lambda one. I prefer the explicitness, but that's just me.

 

I'm sure there is tons of better ways, and I do appreciate the effort in showing me another way. However I'm not looking for an alternative way right now, this is for a small project  on a deadline. Also I'd love to actually know why this isn't working!

So far I have gotten it to work in two ways:
 

  • Write all the code inside the header and add #define new new(__FILE__,__LINE__), this however dosen't work if two headerfiles includes the memoryleak header even if it's inside a header-guard. The compiler compains of already used function symbols.
  • Sepperate the leak code into a .h and .cpp, wrap it around another header and add the macro last.

 

I'm trying to figure out WHY my first attempt isn't working, and how to "properly" do it.


In Topic: Problem defining a new 'new' macro

31 January 2014 - 09:10 AM

That is a great resource, but it doesn't explain my problem unfortunatly :/


In Topic: [C++/SFML] ECS - How to deal with the entities?

10 December 2013 - 02:45 PM

So I'm currently necroing this thread because I'm back again, desperately trying to wrap my head around ECS! I did read all the way until the last post, so I'm aware of what have been said, although some is a bit fuzzy.

The root of my problems with ECS is basically the entities themselves! How to store them, how to "kill" them and how to make sure that old entity id's are validated as "alive" if they have been reused. I'm stuck here and I'v been reading source like crazy and googling like there is no tomorrow. Most of the code i find are either very cluttered or quite "heavy", making it hard to get a good overview of the system, they aren't simple so to speak.

I have gained some more insight on templates since last time, and "typeid(T).name()" have served me well in various tasks. However the root of my problem with the ECS problem still exists. The entities.

My current naive implementation is basically that each entity is an "unsigned long long" and that the "World" has a

std::map< unsigned long long, std::map< std::string, Component* > > componentBag;

that keeps components associated with objects. I can imagine it's rather ineffective and as one might guess I'm not recycling any old entity id's

I turn to you guys, In hope of getting a throughout and careful explanation on how to deal with entities and how to invalidate and recycle. Preferably some mentions of the association of components. 

I know it's a lot to ask, but hopefully someone might be able to answer my request :)


In Topic: [C++/SFML] ECS - How to deal with the entities?

08 October 2013 - 05:20 AM

The reason I ask is because: What if you have a homing missile targeting an entity. The homing missile would need to know whether or not the target is still valid. Running a isValid(Entity e) every frame might be quite expensive considering there is a lot of entities. But I guess the object could subscribe to an "onDeletion" event for that or something similar.

Thanks a lot! I will try to implement this ASAP. I feel that ECS plays so nicely along with OOP.


PARTNERS