2D Draw - pass pointer to video driver in draw() function?

[Ulf]

I've been having difficulty deciding how to use the video driver when drawing 2D objects.

I could pass a pointer to the video driver, to the constructor of every sprite/tile and the object will be able to keep the pointer and draw itself using the pointer. I don't know if that is wrong/bad, I haven't really thought about how many sprites will be active but it's for a game engine so some games could have many many small sprites.
Is it bad design to store a pointer like that for every object?

Or..

I could just keep one pointer to the video driver in the main game engine class and pass the video driver to the objects in the draw functions.

Or..

I could store a few pointers to the video driver. One for each manager that would use it. For example, if you had a separate sprite manager, background manager etc..

What is better design? and what kind of differences in performance would I be looking at? More/Less memory, faster/slower?

Code: Select all

inline void Draw(const irr::video::IVideoDriver*	pVideoDriver,
				 const irr::core::position2di		ptDest,
				 const irr::core::recti*			clipRect = (irr::core::recti*)NULL,
				 bool								bTrans = false)
{
	Draw(pVideoDriver, ptDest.X, ptDest.Y, clipRect, bTrans);
}

Is it best to just pass a pointer in the draw function?

Will one way make it more or less dependent on the other files in the game engine?

I just thought, if you can pass the pointer when you draw then you could use different video drivers at will (that is if/when irrlicht can draw textures to multiple video drivers), but even so you could just provide a setVideoDriver function instead.

[wITTus]

You may read a few books about design, or you'll stumble into this kind of problem again and again. For the performance I'd say that using a code profiler is the best way to go.

[Ulf]

You may read a few books about design, or you'll stumble into this kind of problem again and again.

Ok. But that's not really the problem. I know various ways I could design it, I just thought it might be an obvious answer to some experienced programmers.
The choice of storing thousands of pointers to the same irrlicht device, or passing that pointer every time draw is called.

At first I thought the easiest way was for every sprite to keep a pointer to video driver. Later I looked at the way Irrlicht loads textures and started doing it more like that, where you have to use a different class to load and draw textures.

Guess I'll just have do it and learn by my design faults.
Anyway, I decided to keep one (or just as many as required) pointer to the video driver and pass it in the draw functions for now.
Seems to be better design choice to me!

For the performance I'd say that using a code profiler is the best way to go.

Ok thanks. I'll look into that, one day.

*EDIT*
I thought of one more option.
I could draw the sprites from the sprite manager, so the sprites won't need to draw themselves by passing them pointer to video driver.
Instead, the sprite manager will use a getTexture function to retrieve the texture from the sprite, then draw the texture.

Damn! I don't know, the more I think the less I know what I'll do!

[bitplane]

Anyway, I decided to keep one (or just as many as required) pointer to the video driver and pass it in the draw functions for now.
Seems to be better design choice to me!

Yeah that's the best choice. When designing an object try to only include parts which belong to that object. The game engine owns the video driver, tiles may own their position and their material but they should know nothing of the driver.

[Ulf]

Yeah that's the best choice. When designing an object try to only include parts which belong to that object. The game engine owns the video driver, tiles may own their position and their material but they should know nothing of the driver.

Aaaahhhh. Relief. Thanks bitplane. I just needed someone intelligent to get to the point.

So going from my quote (edited in previous post)

I thought of one more option.
I could draw the sprites from the sprite manager, so the sprites won't need to draw themselves by passing them pointer to video driver.
Instead, the sprite manager will use a getTexture function to retrieve the texture from the sprite, then draw the texture.

Would you say don't pass a pointer? Just make the game engine or Sprite manager do drawing.It just have to get the texture from the object and draw it.

*EDIT* It's sort of the same thing, either pass the driver or get the texture.
But it's starting to make more sense to me to just draw it from where the driver is rather than passing the driver JUST SO the object can draw itself.

[Ulf]

By the way, I don't yet get how the grab and drop texture thing works.

Code: Select all

{
	// Create the texture for the CBackground
	irr::video::ITexture* pTexture = getTexture(textureFileName);

	//! Make sure the texture loaded, return NULL if not.
	if (!pTexture)
		return (CBackground*)NULL;

	//! Create a CBackground with the loaded texture. 
	CBackground* background = new CBackground(m_pVideoDriver, textureFileName, rcViewport, ptVelocity, baBoundsAction, fParallaxDistance);

	return background;
}

Code: Select all

irr::video::ITexture* getTexture(const irr::c8* textureFileName)
{
	//! if no video driver set, return NULL.
	if (!m_pVideoDriver)
		return (irr::video::ITexture*)NULL;

	// Return the texture for the CBackground
	return m_pVideoDriver->getTexture(textureFileName);
}

Do I need to drop the texture anywhere in that code?
I create a background with the texture and return the background (which has pointer to the texture).