PopMatrix PushMatrix implementation

Monkey Forums/Monkey Beginners/PopMatrix PushMatrix implementation

ziggy(Posted 2014) [#1]
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?

skid(Posted 2014) [#2]
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.

ziggy(Posted 2014) [#3]
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.

skid(Posted 2014) [#4]
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.

marksibly(Posted 2014) [#5]
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!

muddy_shoes(Posted 2014) [#6]
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.

ziggy(Posted 2014) [#7]
@muddy_shoes; That's what I was testing right now.

Nobuyuki(Posted 2014) [#8]
I always wondered the exact reasoning behind the stack limit, and now I know.

ziggy(Posted 2014) [#9]
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.

Nobuyuki(Posted 2014) [#10]
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.

Gerry Quinn(Posted 2014) [#11]
One fix to that would be to add a SetCapacity( capacity:Int ) and/or a New( startingCapacity:Int ) method to monkey.Stack

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.

ziggy(Posted 2014) [#12]
Lovely fix in the repo. Thanks!