Quantcast
Channel: Cemetech
Viewing all articles
Browse latest Browse all 75338

Casio Prizm/FX Development & Programming :: RE: Useful Prizm Routines

$
0
0
Author: Tari
Posted: 22 Dec 2012 04:24:23 pm (GMT -5)

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.
_________________


Ask questions the smart way· タリ


Viewing all articles
Browse latest Browse all 75338

Trending Articles