Jump to content

  • Log In with Google      Sign In   
  • Create Account


kilah

Member Since 08 Apr 2010
Offline Last Active Jul 11 2014 01:07 PM
-----

Posts I've Made

In Topic: What is your longest C++ macro

12 December 2011 - 08:22 PM

ApochPIQ is the best approach from my point of view. Aggresive inlined function may fail to fit the code within instruction cache, compiler is quite clever on this thought.. The best initial approach, if your macro is extensively used within another function, is to create a function near your caller, and use it in a straight manner. Iniline function hint is most likely good to use on small code functions (that generate small amount of ASM code), or functions that are not used extensively within another caller, not a 27 lines behemoth, from my point of view. Of course that would require both profiling and see asm code generated from the macro in each case.

In Topic: C++ class question

04 December 2011 - 01:37 PM

The underneath problem lies on "local variables". You must ensure that your variable lifetime is guaranteed after your function X has returned, so glVertex3fv input is correct. Therefore you must ensure the variable lifetime is bigger than what your local stack funciton offers. The mean and way you ensure that... is your decision. You could instance an array, you can pass a memory address of your data, etc.

Cheers.

In Topic: C++ class question

04 December 2011 - 01:23 PM


No, but you can write a function that does that


I've tried making a function like this:

float* Vec3::get()
{
	float ret[3] = {x,y,z};
	return ret;
}

but it still counts as one argument. Am I close at all?


What you are looking for there is:
// x,y and z must be contiguous in memory. In short: have them all three together in your class.
float* Vec3::get()
{
    return &this->x;
}

glVertex3fv(vec.get());
But SirCane solution may be more elegant depending on your point of view.

In Topic: I spent high school in front of my computer

03 December 2011 - 05:04 AM

I guess swiftcoder point was more about "nostalgia from your childhood" is really valuable later on. But what I think he misses is that any memory will do. Personally I have fond memories about me playing basketball in my junior year, aswell as me playing monkey island when I was 10. Anything will do, as long as you enjoy it. The point I think he is completely right about is that fitness at younger ages, specially at puberty, is important for the rest of your life (by no means this means you have to give out on learning whatever you enjoy, but you should balance it).

Cheers

P.S: You can chase redheads even after high school, no big deal about that!

In Topic: Advanced Memory Management

29 November 2011 - 02:14 PM


So over the course of the years, one finds it imperative that if he wants to improve performance, he must write his own memory management system.


Can someone elaborate on this? I understand that for games 10 years ago this could be considered imperative but I don't see how this would make that much of a different for modern games. Memory isn't (or shouldn't be) newed and deleted excessively every frame and it seems like most games these days are GPU bound. I would guess that energy spent on parallelization would have a bigger performance impact.

Is there something I'm missing? Are there any benchmarks showing significant performance increase in a game based on a custom memory management system?


Depends on many things. For instance fragmentation created by uncontrolled heap calls may turn out to be a problem on some platforms, other problems may benefit from memory pools due to their allocating strategy. Therefore a custom allocator to solve those problems may be a solution. I say "it may" because it is problem specific (ie: specific linked list allocator that keeps data contiguous) and platform specific( ie: performance gain from replacing heap allocation on a OS system like Windows to your custom allocator may turn out to be a harder problem to solve than what you think, for a general purpose allocation strategy). General allocators are quite doing their job, that's why it may not be worthy to replace them.

And definitely the almighty hint: do not optimize until you profile.

Cheers.



PARTNERS