Builtins are provided, but may not be used. I was testing a bit, and floor(1.5) got optimized to a constant load, while inhibiting optimizations plus moving data sources around got it to emit a call to the library function (all other options being the same).

Isn't that a good thing? What does double a = 1.5; floor(a); do?

Yes, it's good. But the point is that we cannot guarantee the builtins will be used, so there needs to be a library implementation for it to fall back to.

Wouldn't this return the wrong result for integral negative x values? That was part of the complexity of my code.

Oh, so it would. Back to the drawing board (though I begin to suspect, then, that yours is about as good as it can get without weird bit manipulations).

Here's my full featured menu-system routine. It requires some other functions and data structures. Full documentation available in my example package. Description also available here

To get every required function, read the documentation. They are included in menu.hpp in the package
Data structures:

Code:


Config:

Code:

For example you can display more than 2 tabs on the same page, if you set a low value to MENU_TAB_WIDTH or a longer than 2 character long text in the upper left corner by changing MENU_TAB_INDENT. If its needed, you can transform this constants to function arguments with the same name.
If a label is longer than it's space then the rest of the string is not shown.


Function:

Code:



Params:

int menu(struct Tmenu *mymenu, unsigned char selected_page, unsigned char selected_tab)
mymenu: the structure, which contains the menu system (pages, tabs and items)
selected_page: the function draws this page
selected_tab: the function draws this tab of the selected page
return value: returns the ID of the selected menu item, or -1 if [EXIT] was pressed

Example initialization of a menu object (this is the copy of the Geometry plugin's menu system):

Code:


Controls:

Press keys UP and DOWN to select items
Press keys LEFT and RIGHT to jump to the next or the previous tab
Press EXE to select an item
Press EXIT to close the menu without selecting an item
Press your pre-defined keys to jump to page

Notices:

This function uses SaveVRAM_1(). So your previously saved VRAM data will be overwritten.
This function uses CopySpriteMasked2bitR() which is different from CopySpriteMasked2bit() and CopySpriteMaskedNbit()
This function uses sys_memset() and PrintCXY(). They might not be in your libfxcg. You can download the newest version from here: https://github.com/Jonimoose/libfxcg

May I recommend that you make a page in the Useful Routines section of WikiPrizm for this excellent set of documentation? Great job!

Yes, I thought about that. I've sent you a PM

FOr Bust-a-Move, I used a sprite sheet for the launcher, because I didn't wanted to encode a lot of sprites.
So I made a Copy-Sprite derivated function who takes "angle" of the launcher, and choosing the right launcher.

With some modifications, It could become a "choose a sprite from a grid and display it" function...


Code:

I was worried that that would incur some significant CPU overhead and hence slow down the program, but after reading it throug ha few times I must say that I can't find a flaw in that that would make it slower than drawing a sprite from a converted sprite.

Really? I thought that the maths inlcued in the routine would make the routine slower...

They will, but an add and a multiply, performed once per pixel, and for a sprite drawn only once per frame, the addition is negligible.

Aaaaand the cleared routine, usable for 'any' sprite sheets... ('any' because if the sprite sheet is cut, the sprite will be messed up)

Code:

Written based on a request from gbl08ma, this routine replaces every pixel with a given color inside a rectangular area with another color. One particularly useful potential application: change the background (or foreground) color on text or other complex shapes/sprites. Please tell me if you spot any problems.


Code:

I was looking for Triangle routines and I modified one and got this:


Here is the routine:

Code:

Here is a FloodFill routine I ported from this website: http://cboard.cprogramming.com/brief-history-cprogramming-com/9676-floodfill-algorithm.html

Here is mine:

Code:

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?

It would be a good idea to avoid memory corruption with big fills, since you have much less space for the stack than you would on a desktop.

I could put a border around the screen so that it doesn't go on forever and ever.