foofightr
Speed/efficiency of pointer dereferencing
Engine->Renderer->FindEntity(id)->Remove();
Well, a class has to store its pointers (and variables of course). Modern compilers like VC align these to 16 (or even up to 128) Bytes
That's one point which determines speed ... though you cannot change anything about it ...
VC seems to even put those adresses in processor registers sometimes, so your first example would even be faster than the second...
If you're using DJGPP or VC Standard (Pro has better optimizing), you should use the second approach, perhaps together with the register keyword, if your function doesn't do heavy calculations.
-Markus-
Follow my progress: http://blog.nuclex-games.com/ or Twitter - Topics: Ogre3D, Blender, game architecture tips & code snippets.
From a legibility and maintenence standpoint, I think approach 2 is a winner also. Say someday you change the heirarchy so the location of D is moved. With approach 1, you have to change 3 lines of code. With approach 2, you only have to change the one line.
------------------
-vince
(I guess the general rule is to either leave code-level optimization (as opposed to design optimization) to the compiler or do it yourself entirely ).
/Niels
System->keyboard->readkey();
Specific driver instances would be loaded at the beginning of program execution. This framework would result in the game logic being entirely platform-independent, and the only part of the actual game code that should be non-platform-dependent would be the device driver implementations and possibly a configuration screen in the game.
Does this sound like a good framework, or would the virtual functions or something else slow down the game a great deal? Andre Lamothe says not to use "layers of software" in games, but I'm not sure if this system constitutes as the kind of "layer of software" that a game programmer should avoid. But isn't this basically how games like Unreal and Half-life (which have pluggable device drivers) work? It also seems like the easiest way to make a framework that's cross-platform, and one in which you can change drivers on-the-fly.
As for performance, Java is really quick, and getting faster with each new revision of the run-time systems.
The fact that JavaRTs can perform run-time code optimization means they are capable of adapting the code to the EXACT hardware on which it is running - Something you can't even hope for with C++... I wouldn't be suprised to see bechmarks in the not so distant future where Java outperformed C++.
/Niels
I've got a question about the efficiency of dereferencing pointers (well, I think "dereferencing" is the word I'm looking for). Here's my dilemma:
Say I've got four classes called A, B, C, and D. An instance of B called "b" is contained as a public member of A, an instance of C called "c" is contained in B, and so on. Let myMethod1..3 be member functions of the D class, and let a be an instance of the A class.
Now take this chunk of code:
a->b->c->d->myMethod1
a->b->c->d->myMethod2
a->b->c->d->myMethod3
My question is, will there be any speed difference between this code and manually caching the location of a->b->c->d beforehand, as follows:
D *dPointer = a->b->c->d
dPointer->myMethod1
dPointer->myMethod2
dPointer->myMethod3
So basically I'm wondering if the compiled program has to re-compute the location of a->b->c->d (by dereferencing a, then dereferencing b, then c, and then d) or not. Any help on this issue would be greatly appreciated.
Currently we support Win95/98 and Mac - we haven't had any problems that I know of with JNI on those two platforms. Dunno about any others...
Using your current method you can always add the JNI layer above your current C++ abstraction layer - this has some benefits. For instance you can write pure C++ test apps for the core engine. Debugging the native routines is a lot easier in an all-native environment.
------------------
-vince