Irrlicht Easy Using

Post those lines of code you feel like sharing or find what you require for your project here; or simply use them as tutorials.
Post Reply
aktlakfh1777
Posts: 17
Joined: Sun Dec 21, 2008 1:40 am

Irrlicht Easy Using

Post by aktlakfh1777 »

i was thought about this.

Code: Select all

// FILE : _irrlicht.h
#ifndef EASYIRR
#define EASYIRR
	#include <irrlicht.h>
	#ifdef _IRR_WINDOWS_
	#pragma comment(lib, "Irrlicht.lib")
	#pragma comment(linker, "/subsystem:windows /ENTRY:mainCRTStartup")
	#endif

	/* NAME SPACES ON IRRLICHT*/
	using namespace irr;
	using namespace core;
	using namespace scene;
	using namespace video;
	using namespace io;
	using namespace gui;

	class _Irrlicht
	{
	private:
	public:
		IVideoDriver* _driver;
		ISceneManager* _smgr;
		IGUIEnvironment* _guienv;
		IrrlichtDevice* _device;

		_Irrlicht(int x, int y)
		{
			// Create Device
			this->_device=createDevice(video::EDT_DIRECT3D9,dimension2d<s32>(x,y),16,false,false,false,0);
			this->_driver=this->_device->getVideoDriver();
			this->_smgr=this->_device->getSceneManager();
			this->_guienv=this->_device->getGUIEnvironment();
		}
	};
#endif
very easy.

it can use like this.

Code: Select all

#include "_irrlicht.h"
void main()
{
	// Irrlicht Initizing
	_Irrlicht *ir=new _Irrlicht(800,600);
	while(ir->_device->run())
	{
		ir->_driver->beginScene(true, true, SColor(0,100,100,100));
		ir->_smgr->drawAll();
		ir->_guienv->drawAll();
		ir->_driver->endScene();
	}
}
It is very Simple!

if you must use "int main()", try this.

Code: Select all

#include "_irrlicht.h"
int main()
{
	// Irrlicht Initizing
	_Irrlicht *ir=new _Irrlicht(800,600);
	while(ir->_device->run())
	{
		ir->_driver->beginScene(true, true, SColor(0,100,100,100));
		ir->_smgr->drawAll();
		ir->_guienv->drawAll();
		ir->_driver->endScene();
	}
	ir->_device->drop();
	return 0;
}
Last edited by aktlakfh1777 on Sun Jul 26, 2009 8:11 am, edited 1 time in total.
hybrid
Admin
Posts: 14143
Joined: Wed Apr 19, 2006 9:20 pm
Location: Oldenburg(Oldb), Germany
Contact:

Post by hybrid »

Better make a singleton from your class, and avoid "using" in header files.
vitek
Bug Slayer
Posts: 3919
Joined: Mon Jan 16, 2006 10:52 am
Location: Corvallis, OR

Post by vitek »

You should also avoid using names that begin with an underscore followed by a capital letter or two underscores and a lowercase letter. Names that fit those conventions are reserved by the implementation, and could cause unexpected problems with your code.
randomMesh
Posts: 1186
Joined: Fri Dec 29, 2006 12:04 am

Post by randomMesh »

You should drop() the irrlicht device at the end of main(), to avoid a memory leak.

Btw:
main() must return int. Not void, not bool, not float. int. Just int, nothing but int, only int.
"Whoops..."
Dorth
Posts: 931
Joined: Sat May 26, 2007 11:03 pm

Post by Dorth »

void main() in any compiller accepting it will compile to return 0; I think it's really only relevant if you intend to use return code of you app and/or if you plan to port your code a lot. Else than that, it's an obsolete comment.
vitek
Bug Slayer
Posts: 3919
Joined: Mon Jan 16, 2006 10:52 am
Location: Corvallis, OR

Post by vitek »

randomMesh wrote:You should drop() the irrlicht device at the end of main(), to avoid a memory leak.
Actually, he should probably make a destructor for his _Irrlicht class that drops the device. He should also either delete ir at the end of main(), or make it a local variable instead of allocating the object on the free store.
Dorth wrote:void main() in any compiller accepting it will compile to return 0; I think it's really only relevant if you intend to use return code of you app and/or if you plan to port your code a lot. Else than that, it's an obsolete comment.
I think the point was that main() is required to return int. Here is the wording from the C++98 draft...
C++98 wrote: It shall have a return type of type int, but otherwise its type is implementation defined.
This sentence is the same in the latest draft of C++1x. I believe the wording for the C90 and C99 standards are also the same. Any program that provides an implementation of main() that does not meet this requirement is not a strictly conforming program, and the behavior of such a program is left undefined by the C++ standard. That means that it is up to the compiler vendor to decide what should happen. The code might work just fine, it might fail to compile, fail to link, crash, or e-mail pictures of you to failblog. If you wish to guarantee that your code will behave consistently on all freestanding conforming C++ compilers, you will avoid relying on such implementation specific behavior.

That said, you don't need to explicitly return a value from main(). If the program reaches the end of main() without hitting a return, it is required to behave as if main() had returned zero. This is a special case for the main() function.

Travis
vitek
Bug Slayer
Posts: 3919
Joined: Mon Jan 16, 2006 10:52 am
Location: Corvallis, OR

Post by vitek »

Dorth wrote:void main() in any compiller accepting it will compile to return 0;
The in any compiler accepting it is a very important qualifier.

Here is an example of a compiler that will not allow main() to return something other than int...

Code: Select all

Thank you for testing your code with Comeau C/C++!
Tell others about http://www.comeaucomputing.com/tryitout !

Your Comeau C/C++ test results are as follows:

Comeau C/C++ 4.3.0.1 (Aug 20 2002 15:39:28) for ONLINE_EVALUATION_BETA2
Copyright 1988-2002 Comeau Computing.  All rights reserved.
MODE:non-strict warnings C++

"ComeauTest.c", line 1: warning: return type of function "main" must be "int"
	So use int main() OR int main(int argc, char *argv[])
  void main ()
       ^


In non-strict mode, with -tused, Compile succeeded (but remember, the Comeau online compiler does not link).
Compiled with C++0x extensions DISabled.  
I'd guess that other compilers would at least warn if you enable warnings. According to the documentation for gcc ([1]), the -Wmain warning flag (enabled implicitly with -Wall) should cause the compiler to emit a warning when compiling such code. The microsoft compiler is documented to allow main() to have return type void ([2]), but only if microsoft extensions are enabled, and this is the default. Turning the extensions off should cause the code to fail to compile there also.

[1] http://tinyurl.com/yqahfb
[2] http://tinyurl.com/mzpskk

Travis
Dorth
Posts: 931
Joined: Sat May 26, 2007 11:03 pm

Post by Dorth »

I know that, and fine. But then, you should test your NULL to make sure they == 0, that a byte is > 7 bits and smaller than < 9 bits, that each other int is bigger than the previous one, since they are only required to be >= and so on and so forth. We use those everyday without even giving a thought that it might not be so, but the standard is actually pretty wide with "left to the compiller's interpretation" or "at least" etc. We take those for granted and the same, when porting or changing the behaviour of our compiller, we should wary that they stay true. main() is just the same...
vitek
Bug Slayer
Posts: 3919
Joined: Mon Jan 16, 2006 10:52 am
Location: Corvallis, OR

Post by vitek »

Dorth wrote:I know that, and fine.
But the OP might not know. When someone comes out and says that something doesn't matter, and it actually does, I feel compelled to point out the facts.

The point is that your code will be easier to maintain and port if it is standard conforming. As soon as you start writing code that depends on features not required by the standard, you start making maintenance and porting that more difficult.

Sometimes you need to rely on unspecified or implementation defined behavior, and I get that. But it really doesn't make a whole lot of sense to write this type of code unnecessarily.

Travis
Dorth
Posts: 931
Joined: Sat May 26, 2007 11:03 pm

Post by Dorth »

And somehow my original comment made that info disappear from this thread how? I only put it in context, as in, you know, everything else around it.Take too much time hammering things like those in anyone but a pro coder and he might miss out on some rather fundamental concepts in the meanwhile. The link randomMesh posted was and is valid, yet, so many other things need straightening out in the original post, do you really think that is the biggest matter?
vitek
Bug Slayer
Posts: 3919
Joined: Mon Jan 16, 2006 10:52 am
Location: Corvallis, OR

Post by vitek »

Dorth wrote:Take too much time hammering things like those in anyone but a pro coder and he might miss out on some rather fundamental concepts in the meanwhile.
Oh, so it is better to tell them that it isn't a problem when it actually is, or will be?
Dorth wrote:so many other things need straightening out in the original post, do you really think that is the biggest matter?
Agreed. Had someone else pointed out these issues and you 'corrected' them by saying that they aren't actually problems, I would have responded the same.
omar shaaban
Posts: 616
Joined: Wed Nov 01, 2006 6:26 pm
Location: Cairo,Egypt
Contact:

Post by omar shaaban »

well that is not the point here u all are correcting his programming mistakes he just pasted an idea in a form of a code he didn't check every single thing ,he didn't say the code is ready and it is perfect.
but again i would say yes by this way irrlicht would be easier but...... for you not me not someone else or maybe u set directx9 and 16 bit as default .
i use opengl so this class wont work for me , and some one else uses 32 bit so it wont work for him
and basically this code will help beginners although it doesn't save that much of a code and i thing writing more line or 2 wouldnt be a problem here since creating an irrlicht device isnt that complicated
Post Reply