Recommended Posts

I''ve a projectile object class that delegates a sprite object as a visual representation. So far i have sprite object drawing itself. However there are limitation when this becomes less practical. What is the ideal strategy for drawing things to screen? Should objects draw to a memory space that is passed to them or should I have a drawable object collection class that draws everyone?

0

Share this post

Link to post

Share on other sites

sprites can be shared by various objects, they can share textures, have the same render states (no transparency, same kind of transparency, some texture transform, gouraud shading on corners of the quad, multi-texturing, ect...), so it''s better to have a render manager to handle them and sort them accordingly, to improve efficiency.

each objects adds itself to the renderer, with different settings (quad with a texture index, texture coord, transparency settings, angle, z-order, vertices, vertex colors for gouraud shading), and when you finished adding quads, the renderer would sort them in a priority queue, and render them, batching them in large dynamic buffers as much as possible.

obviously, you don''t HAVE to do it, but you can run in nasty rendering bugs, especially if using transparency, unless you can be sure to render stuff in the right order (background layers, objects, bullets, particle effects, HUD, ...).

you can make the decision transparent in the code. In each objects'' render function, setup a quad, and pass it to the renderer. Then it can either render it immediately, or cache it, when you feel like implenmenting it.

0

Share this post

Link to post

Share on other sites

I have what i call a "polling system". All my objects that need graphics load their own resources and inherit from PollingObject class. That class has a virtual Poll( int time ) function. Polling Objects register themselves with the PollingEngine which sorts them in layers. When the game loop runs, it does something like PollingEngine->Cycle() and loops through each PollingObject in each layer (background, sprites, foreground, etc.) Poll()ing each one, and they all take care of whatever time-based operations they need to perform, including but not limited to blitting themselves onto the screen. The PollingEngine just makes sure they all get called in the right order. When objects die, they unregister from the engine.

So i''m not saying it''s the best idea, but i have each sprite-sorta-class load it''s own data and blit itself the way it wants to. But that works for *my* game. If you plan to have lots of repetative graphics, it may pay off to have a resource manager. My game has lots graphics unique to particular objects, so i''ve gone the "distributed" route.

All with the same buffer? Or did you manage to do it all with filling up the buffer and then just one call to DrawIndexedPrimitive() for the whole buffer? That would mean using software transformations right?

0

Share this post

Link to post

Share on other sites

software transform, that''s right. but for sprites, that should be negigeable, compared to the efficiency you get by batching them into one primitive buffer. transform the object''s sprite into a quad, and add the quad to a list.