Much faster RLE colorkey blit (thanks Xark and Mattias)
Visual C is gagging on the “inline” (surprise!) on line 241 of
SDL_RLEaccel.c, should be “inline” instead?
Is that what visual C calls it? I thought inline was a gcc:ism.
configure tests whether inline is supported and #defines “inline” accordingly,
but perhaps Visual C doesn’t use the configure script.
Oddly enough, begin_code.h contains some code defining inline instead:
/* If inlining isn’t supported, remove “inline”, turning static
inlined functions into static functions (resulting in code bloat
in all files which include the offending header files)
*/ #ifndef SDL_INLINE_OKAY #defineinline
We should settle for one of them (I suggest “inline”).
Visual C is gagging on the “inline” (surprise!) on line 241 of
SDL_RLEaccel.c, should be “inline” instead?
Perhaps, but it may be better to just remove it (I doubt all compilers
that SDL is compiled with support an inline extension).
The function in question is declared static and is only called from one
place, so you would hope the compiler would inline it automatically (for
an optimized build, anyway). Also its in the RLE encoder code, so isn’t
super speed critical.
I removed the inline from the final version of my patch, but Yorick
probably got it from an “almost final” version.
Take it easy,
KenOn Tue, 23 May 2000, Randi J. Relander wrote:
Perhaps, but it may be better to just remove it (I doubt all compilers
that SDL is compiled with support an inline extension).
The configure script takes care of that. It tries inline, inline and
__inline (in that order), resorting to #defining inline as empty if not
supported at all.
The function in question is declared static and is only called from one
place, so you would hope the compiler would inline it automatically (for
an optimized build, anyway). Also its in the RLE encoder code, so isn’t
super speed critical.
As you say, it’s not a big deal. However, sometimes you wish to give that
hint to the imperfect compiler of the day