fonctions de sprite gcc4ti

[Michael0x18]

Interesting. I tried the second one, and it works. A bit earlier, I figured out that since the 68K uses big endian, we can't do 1<<offset; it needs to be 1<<(size-offset).

Thank you yet again! I think I'm going to use the new one because it seems to be a little faster.

[Lionel Debroux]

A bit earlier, I figured out that since the 68K uses big endian, we can't do 1<<offset; it needs to be 1<<(size-offset).

Oh yeah, I missed that too. You could also shift right a 0x8000 value for a short, 0x80 for a byte.

I think I'm going to use the new one because it seems to be a little faster.

The byte-sized version should indeed be marginally faster if the compiler produces a btst instruction, but not that much.
If the pixel test function is used at few call sites (say, less than 5), you should consider declaring it "inline", so as to avoid the overhead of passing arguments into the appropriate registers (or worse, on the stack, if you didn't use the -mregparm=5 compiler flag), calling into a subroutine, returning from that subroutine, and possibly adjusting the stack pointer at some point if the default stack-based calling convention is being used.

In ExtGraph, pixel operations are macros because it yields much, much better speed optimization, and sometimes size optimization as well.

[Michael0x18]

True. It's called eight times within the same function. I'll declare it inline/convert it to a macro and see.

[Lionel Debroux]

An inline function buys you type checking and other niceties that macros can't bring, so you should keep using a function

[Michael0x18]

Okay. Got it. (And thank you yet again!)