Author: Spenceboy98
Posted: 22 Dec 2012 04:38:39 pm (GMT -5)
So, you're saying I should make a new one with the link you sent me?
Posted: 22 Dec 2012 04:38:39 pm (GMT -5)
| Tari wrote: |
| As someone noted in your source, this is recursive so it may require a lot of stack. I estimate its stack frame (including the parameter area) is 6 words, so 24 bytes per recurse. Worse-case memory needs there are just under two megabytes: 384 pixels * 216 pixels * 24 bytes/pixel = 1990656 byte-pixels (that's a silly unit). So if you're trying to fill a large region a bad situation is a crash (because you fill all of the available RAM), and the worst-case situation is silent corruption of your .data section (overflowing the stack but not RAM, since the stack and .data grow from opposite directions in the same memory region). Basically, I wouldn't trust this to be robust, and I believe direct VRAM access would be appreciably faster than Bdisp_GetPoint_VRAM. There's no trivial way to convert this into a tail-recursive variant of the same algorithm, but there are indeed fixed-memory algorithms for flood-filling which would probably not be appreciably slower. |
So, you're saying I should make a new one with the link you sent me?