PopMatrix PushMatrix implementation
Monkey Forums/Monkey Beginners/PopMatrix PushMatrix implementation
| ||
| Any reason why it's not using a Stack? It seems it's limited to 30 push/pop operations. Shouldn't a MatrixStack be used instead? |
| ||
| No, the current push implementation will from the looks complete in under 4 cpu cycles and creates zero garbage which is what you want for functions that are likely to be called thousands of times per frame. |
| ||
| Thousands of times per frame I honestly think it makes no sense to worry about the speed of calling it thousands of times per frame, and limit it to 32 nested oiperations. Woud a Stack of 6 floats arrays be noticeable slower? I'm running out of array index often when woking with my Gui system.EDIT: At last, it could dynamically resize the internal float array if required, and allow us to pre-resize it programatically if we want to prevent a chain of multiple slow resizes. EDIT2: I see I can roll my own MatrixStack (or similar) and it should not interfer with current implementation. So, if you think my request/question has no sense, just ignore it. |
| ||
| I don't disagree. I am finding it difficult to visualise a layout / use case that would require 8, let alone 32 deep transformation stack. |
| ||
| One of the initial motivations behind limiting the matrix stack size was to handle situations where users would forget to the pop the stack, in which case the stack would just quietly grow and grow until it blew up, probably leaving the user with little idea of what went wrong. But that was back when I wasn't sure if mojo graphics state should reset itself every OnRender or not. But it does (ie: stack is effectively Cleared before each OnRender), so I don't think this is really a valid concern any more and would be comfortable with using a proper matrix stack. Or at the very least, a bigger one! |
| ||
| I changed the mojo code to use a larger array of arrays as a matrix stack a while back. Made no odds in terms of speed for the most part and IIRC it was even a little faster in places due to being able to copy entire arrays with a single reference. The code was cleaner too. |
| ||
| @muddy_shoes; That's what I was testing right now. |
| ||
| I always wondered the exact reasoning behind the stack limit, and now I know. |
| ||
| I always wondered the exact reasoning behind the stack limit, and now I know. It's fun that at first sight, I thought it was sort of "I'll add a propper stack later" and, as it is working as it is for most games, then nobody came back later to it. Like it had a missing "TODO" or something like this. |
| ||
| I always figured it was faster to allocate the hard limit than to use Stack<T>'s reallocator. At small values, it does a lot of array resizing ops. |
| ||
| One fix to that would be to add a SetCapacity( capacity:Int ) and/or a New( startingCapacity:Int ) method to monkey.Stack So: matrixStack = New Stack< matrixInfo >( 30 ) This would allocate an array of 30 as now, but it would grow like a stack if more were needed. That said, if it were a standard stack and stack.Clear() were called at the start of a render, it would generally achieve its full size during the first frame, and require no reallocation thereafter. |
| ||
| Lovely fix in the repo. Thanks! |
   |