Aurora 3D Engine Availiable now

BlitzMax Forums/BlitzMax Programming/Aurora 3D Engine Availiable now

The forum is locked. These are the original blitzbasic.com forums, kept so they can still be read. No new topics, replies or edits can be made here. To join in, head over to the Blitz3D+ forums.

calm down Ant... c'mon now...

while chris is obviously trying to raise all sorts of negatives, i dunno what his goal is... i can see where he is coming from with his question...

lets stop and think for a second... everyone likes to call this and that an 'engine'... Blitz3D is and engine... DarkBASIC is and engine... BMax is anEngine, TV3D is an engine.. and so on...

but, really now... what is an engine... stop and think... in it's generic definition, an engine is something that you can turn on, and it does something when you press the throttle (or whatever)...

applying this simplified definition to game 'engines'... this is exactly why i see that none of the above mentioned as being any sort of engines at all... they can't be turned on... they can't do anything... as they are, they offer functional alternatives to an more complex and work intensive set of apis...

the only ones i've worked with so far, that i see as being actual game 'engines', are Torque and irrlicht (rendering engine)...

... and, accept it or not, you code examples above seem to indicate that Aurora is not in the same ball park as either... Aurora does appear to be more of a lib of functions, or a wrapper.

now this does not denegrate Aurora, or is not meant to bring it down at all... i think it will be a great tool for BMax...

take a look at the main game loop from your code examples above, then look at the main loop from the simple irrlicht hello world example...

	/*
	Ok, now we have set up the scene, lets draw everything:
	We run the device in a while() loop, until the device does not
	want to run any more. This would be when the user closed the window
	or pressed ALT+F4 in windows.
	*/
	while(device->run())
	{
		/*
		Anything can be drawn between a beginScene() and an endScene()
		call. The beginScene clears the screen with a color and also the
		depth buffer if wanted. Then we let the Scene Manager and the
		GUI Environment draw their content. With the endScene() call
		everything is presented on the screen.
		*/
		driver->beginScene(true, true, SColor(255,100,101,140));

		smgr->drawAll();
		guienv->drawAll();

		driver->endScene();
	}


can you see here the 'engine' here... the irrlicht device is the engine, and albeit, while it's only a rendering engine, it does quite a bit of work managing the components that are coded in and now are part of the engine by the developer... it's a true engine...

once the irrlicht device is 'turned on', it is running...

there is no Aurora device to turn on... Aurora doesn't appear to manage any aspect of the game code... in fact, the coder has to write whatever 'engine' he/she needs, using the Aurora functions and datatypes provided...

i'm assuming that OGRE is doing something under all this, but i don't know enough about OGRE to comment on it...

if Aurora were a game, and it exposed functionality for extending itself and modifying itself, then it would be more correctly termed an engine... at least that's how i see things...

correct me if i am wrong here... i'm by no means an expert on this sorta stuff... but at the very least lets take it easy on each other...

but what we have here is a good thing... Aurora is a big plus for BMaxers... isn't it...

Ant, you've gotta rise above all this... you've gotta learn that the customer, or potential customer, is always right... regardless... at any rate, this is too good to get bogged down in childish food fighting...

everyone take a time out :)

--Mike