Funtion

If you are a new Irrlicht Engine user, and have a newbie-question, this is the forum for you. You may also post general programming questions here.
M4UNOT
Posts: 39
Joined: Sat Jun 26, 2010 3:06 pm
Location: Germany

back

Post by M4UNOT »

Virion, thanks for the kind words . greenya nice trick but i hate macros

Sudi no hell brother just peace...

and DtD i will try to follow you're advice

:roll:
Virion
Competition winner
Posts: 2148
Joined: Mon Dec 18, 2006 5:04 am

Post by Virion »

but i'm sure you can't really program an entire game using C-style API. so its quite pointless. my advice is spend time on doing your game or whatever project than re-wrapping the whole Irrlicht.
M4UNOT
Posts: 39
Joined: Sat Jun 26, 2010 3:06 pm
Location: Germany

%

Post by M4UNOT »

I am almost approx. 9% done with it but I will try to follow your advice my friend :wink:




small example of what i'm doing


befor: device->setWindowCaption(L"text...");


And now: WN(device, "text..");

Code: Select all


void WN(IrrlichtDevice * Device , char * Text) 
{ 

if (Device != 0) 
{
int size = strlen(Text);

wchar_t unicode_string[30];

size_t length = 0;

length = mbstowcs_s(&length, unicode_string, Text, size+1);

Device->setWindowCaption(unicode_string);
}

} 

Frank Dodd
Posts: 208
Joined: Sun Apr 02, 2006 9:20 pm

Post by Frank Dodd »

Virion wrote:but i'm sure you can't really program an entire game using C-style API. so its quite pointless.
I nearly spat my coffee on my keyboard when I read that. Unlike footballers as C gets older it stays just as fast and functional as it ever was :)

Wrapping Irrlicht in a C interface carefully actually adds very little overhead into your program.
Virion wrote:my advice is spend time on doing your game or whatever project than re-wrapping the whole Irrlicht.
Right my coffee can stay in my mouth this time. I would entirely agree that unless you have a good reason for wrapping the code (e.g: you need to access it from a language or tool that does not support C++ mangled DLLs) you would be better off sticking with C++, avoiding any overhead (no matter how small) and saving time on your project.

If you decide to continue producing a wrapper some pieces of advice I would offer from my own experience are to use consistent function names that are close to the irrlicht names for example I would use setWindowCaption its nice and descriptive, pass parameters in consistent ways and pass parameters in a manner that does not increase the overhead by reformatting the parameters once inside the wrapper function.

Whatever you decide M4UNOT good luck with your project.
M4UNOT
Posts: 39
Joined: Sat Jun 26, 2010 3:06 pm
Location: Germany

thaNKS

Post by M4UNOT »

Frank Dodd, thanks for the kind words - you're awesome.
DtD
Posts: 264
Joined: Mon Aug 11, 2008 7:05 am
Location: Kansas
Contact:

Post by DtD »

Macros are a good thing to hate ;) they can cause very cryptic issues if done incorrectly. (But don't diss them too much, they can also be very useful for making readable code, for example, this is a file from our game engine: http://pastebin.com/xR3gW1qb without macros that would be a huge mess.)

Also, like Frank said, "WN(device, "text..");" doesn't actually tell you anything about what the function does, for all we know it means "Window Notifty" and it displays a message box belonging to the specified device with that text. Have you discovered code completion yet? It will make typing those long function names much less tiring. (EG: You would just type device->setW and hit Ctrl+Space and the IDE does the rest.)

Also, also: All of that string conversion stuff is a dangerous game, you should avoid converting values unless it is necessary (EG: You get user input as a string and you need a float, or some library uses unsigned ints when another needs a float.)
greenya
Posts: 1012
Joined: Sun Jan 21, 2007 1:46 pm
Location: Ukraine
Contact:

Post by greenya »

DtD wrote:... they can also be very useful for making readable code, for example, this is a file from our game engine: http://pastebin.com/xR3gW1qb without macros that would be a huge mess.)
Have looked on that code.
IMHO, this is not good style of usage, because that macro is only usable at that file, even more -- only inside a method because it uses particular name of variable ("as") and does particular call on it ("RegisterEnumValue"). It should be defined -> used -> undefined (right at the place where it actually used; and should be visible only where it has meaning).

for example:

Code: Select all

...
#define _BIND_KEY(key) as->RegisterEnumValue("EKEY_CODE",#key,irr:: ## key)
_BIND_KEY(KEY_NUMPAD8)+
...
_BIND_KEY(KEY_OEM_CLEAR);
#undef _BIND_KEY
...
Pluses:
+ when somebody include your file, he will not get _BIND_KEY macro in global namespace;
+ same macro name can be reused many times even in single file or function; (on MS VS2008 compiler, when you redefining existing macro you getting proper warning)
DtD
Posts: 264
Joined: Mon Aug 11, 2008 7:05 am
Location: Kansas
Contact:

Post by DtD »

Well, that macro was only meant to be used in that cpp file, a macro is good for something that is needed to be done and done again that should be integrated before the compiler actually compiles.
Post Reply