Registriert: Di Sep 06, 2005 18:34 Beiträge: 362 Wohnort: Hamburg
Hi …
I don't know anything about what's out there in the delphi world, but i would just use some more advanced math library that knows about vectors, matrices and/or quaternions. If you are looking for something like the matrix stack I don't know of any library, at least for C/C++. But it's very simple to implement such a stack yourself.
There is one math lib I know about, that's specifically for OpenGL: http://glm.g-truc.net/ It's C++, but maybe you are lucky and there exist Delphi bindings.
_________________ Der Mensch hat neben dem Trieb der Fortpflanzung und dem zu essen und zu trinken zwei Leidenschaften: Krach zu machen und nicht zuzuhören. (Kurt Tucholsky)
Schwabbeldiwapp, hier kommt die Grütze. (Der Quästor)
Did you take a look at TStack's source code? I don't have any Delphi around, so I can not. I assume that they also use an array internally similar to your approach. So you don't have any memory allocation per frame, as the the array gets preallocated.
On a sidenote: If Delphi had a good memory manager with good pooling allocations of small objects would not hurt at all. I recall that there is a recommended replacement memory manager, although I forgot it's name. And then you might try that GC memory manager which can be used in C if allocations are a major concern to you.
_________________ "Für kein Tier wird so viel gearbeitet wie für die Katz'."
Its an extended TList basically (In Delphi 6 Anyway). So as it requires a pointer to be sent to it, memory would need to be allocated each time a matrix is added and freed when its removed(A TList doesn't allocate memory for each item you add to the list, just the core dynamic array for holding the pointers to each item).
FastMM was integrated into the latter versions of Delphi(>= Delphi 2006), replacing Borlands. Its meant to be faster in most situations. Its at least good for debugging memory leaks.
Oh. I was under the impression that if the capacity was reached, TList would allocate more memory than needed for a single pointer so it would not have to do that again for the next few additions.
_________________ "Für kein Tier wird so viel gearbeitet wie für die Katz'."
Well the array at the core of the TList does work like that. But its only allocating space for the actual pointer, not the data it points to. If you want to store Integer numbers it would be fine as you could just set the Pointers own data to your number.
Registriert: So Sep 26, 2010 12:54 Beiträge: 238 Wohnort: wieder in Berlin
Programmiersprache: Englisch
- weird indentation - add a constructor where you can pass a capacity already, just like with TList - in that case your Stack will never reallocmem and thus no "performance loss" when pushing/popping (the default capacity could be 128*Sizeof(TMatrix) or something like that) you wont have this big stacks anyways, FFP was limited there too - TMatrixList => TMatrixArray - even tho TObject.Destroy is quite empty, inherited Destroy should be added to your TOTStack.Destroy dtor - no need for the optional All parameter in Clear, just Clear everything, when you need a new stack, just instantiate a new one - you could add a compiler switch for the behaviour when Pull is called too many times, rather throw an exception than just returning or like there Exit (but that could be a compiler switch) - plural of matrix is matrices
I have never seen the point in having multiple space or tabbed indentation. Its easy to read code that has 1 space indentation.
phlegmatiker hat geschrieben:
- add a constructor where you can pass a capacity already, just like with TList - in that case your Stack will never reallocmem and thus no "performance loss" when pushing/popping
Delphi 6's TList doesn't even have a constructor. You would only have a performance loss if an insane amount of push's were done without any pulls, but you would only get that during a single frame and initialising it with a lowish value won't help.
For reference there is an additional once off ~0.0015307649 milliseconds for the 13 reallocmem's on my pc (For your suggested 128 initial size), so its not going to make any real difference on performance to allocate 128 from the beginning.
phlegmatiker hat geschrieben:
- even tho TObject.Destroy is quite empty, inherited Destroy should be added to your TOTStack.Destroy dtor
I don't see the point in that. You would only need to inherit if the base class changed from a TObject to something else. Its the same with create, its empty in a TObject as well.
Personally i am use to looking in the constructor and destructor to make sure it has inheritance if i change the base class of an object to one which has something in the constructor/destructor. Its something everyone should do, no one should rely on someone adding inheritance into the constructor/destructor when it wasn't needed at the time it was written.
phlegmatiker hat geschrieben:
- no need for the optional All parameter in Clear, just Clear everything, when you need a new stack, just instantiate a new one
I call clear each frame to make sure that the stack is "empty" each frame(Allows Pushing/Pulling errors in code to not cause the stack to constantly allocate more spaces). Freeing everything each frame would defeat the purpose of reallocating the memory only when it needs more capacity.
phlegmatiker hat geschrieben:
- plural of matrix is matrices
I'm not aiming for a spelling contest medal, so that can stay.
P.S I have updated the TOT_Stack code posted above.
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
phlegmatiker has a valid point about indentation. If you want your code to be reused or even reviewed, it's not your opinion which is relevant, but the opinion and taste of the broader public. I for myself drop other peoples code if it looks not well maintained. Not having a nice (i.e. readable to most people) indentation scheme is one of the things which look like not well maintained. Same goes for calling the inherited constructor/destructor always. It's just a matter of good style to do so, because it avoids another source of mistakes. I found myself quite often hunting issues with uninitialized fields or memleaks which were related to that, although I usually take well care about that (sidenote: it's a bug that the FP compiler doesn't warn you on that one, but w/e).
regards, Horazont
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Which version of Delphi do you use, Stucuk? Delphi6 or something not quite as ancient? More up-to-date versions of Delphi (and FPC) have generic lists and also stacks (probably) so you don't have to do to your compiler's job.
_________________ "Für kein Tier wird so viel gearbeitet wie für die Katz'."
Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.