Improvements to libogc library

Add your suggestions for toolchain improvements here.
Post Reply
Rexhunter99
Posts: 23
Joined: Thu Sep 09, 2010 1:28 pm
Location: Australia
Contact:

Improvements to libogc library

Post by Rexhunter99 » Thu Oct 06, 2011 3:34 am

Hey all, mucking around with libogc at the moment and have found that the entirely c-style setup can be a little bothersome at times, it works perfectly fine of course, but there are some things that could benefit from C++ if the user is using the language.

For instance:

Code: Select all

#ifdef __cplusplus
class GXColor
{
public:
	uint8_t r,g,b,a;

	GXColor() {r=0; g=0; b=0; a=0;}
	GXColor( u8 R, u8 G, u8 B, u8 A) : r(A), g(G), b(B), a(A) {}
};
#else
typedef struct _gx_color {
 	u8 r;			/*!< Red color component. */
 	u8 g;			/*!< Green color component. */
 	u8 b;			/*!< Blue alpha component. */
	u8 a;			/*!< Alpha component. If a function does not use the alpha value, it is safely ignored. */
} GXColor;
#endif
That way C++ can get the added benefit of being able to define a color with the class constructor for GXColor. This removes a line or two from your own source with only the little bit of overhead from C++ classes.

I'm sure I'll find others... feel free to use these yourselves, after all, anyone can make them on their own XD

Note that GXColor is located in gx.h

Have a nice day.
Move over Mario... and cruise by Crash... Croc Rocks!
It's a serious adventure 3D platformer for all retro gamers to drool over =D

User avatar
vuurrobin
Posts: 222
Joined: Fri Jul 11, 2008 8:49 pm
Location: The Netherlands
Contact:

Re: Improvements to libogc library

Post by vuurrobin » Thu Oct 06, 2011 8:52 am

First of all, I doubt this would add any overhead in the program. The constructor would be inlined and would (probably) be the same as when it would be done manually.

Second of all, I don't think that the small benefit would be worth the trouble of maintaining this kind of code. Remember that every function that uses this would also have to be modified. That can quickly lead to ugly and hard to maintain code.

I think the best and easiest way would be to just add a function that takes the 4 parameters and returns a GXColor. If it would be inlined it (probably) wouldn't add any overhead either.

Code: Select all

static inline
GXColor makeGXColor(u8 R, u8 G, u8 B, u8 A)
{
	GXColor result;
	result.r = R;
	result.g = G;
	result.b = B;
	result.a = A;
	return result;
}
Then you can just use GXColor bla = makeGXColor(1, 2, 3, 0);

Rexhunter99
Posts: 23
Joined: Thu Sep 09, 2010 1:28 pm
Location: Australia
Contact:

Re: Improvements to libogc library

Post by Rexhunter99 » Thu Oct 06, 2011 10:04 am

Remember that every function that uses this would also have to be modified. That can quickly lead to ugly and hard to maintain code.
I put it into my own copy of gx.h and the test build went perfectly fine, all instances of GXColor passed through the make process with no errors or warnings and using the class constructor worked a breeze.

Begging your pardon, you were right. I just went and twiddled with it a little and realized that it wasn't passing the data on the way I thought it would at the time.
Lesson learned: Do not attempt to program anything while completing an overdue piece of course work.

Anyway, I personally find constructors more appealing for the handling of things like colors. They look so much cleaner than C-style Functions that do the same thing. But that's a personal preference.
Move over Mario... and cruise by Crash... Croc Rocks!
It's a serious adventure 3D platformer for all retro gamers to drool over =D

WinterMute
Site Admin
Posts: 1361
Joined: Tue Aug 09, 2005 3:21 am
Location: UK
Contact:

Re: Improvements to libogc library

Post by WinterMute » Thu Oct 06, 2011 1:38 pm

Modifying libogc headers locally is a pretty good way to make sure nobody else will be able to build your code ... don't do it. Put wrappers in your own code if you must .

I'm quite reluctant to add C++ code to the base libraries because it inevitably ends up requiring C++ to build anything and we have a lot of users who stick with C. Libraries written in C++ also need recompiled when we update gcc, whether they change or not.
Help keep devkitPro toolchains free, Donate today

devkitPro IRC support
Personal Blog

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest