guenter geiger wrote:
To get rid of that problem, some chances in GemBase.cpp have to be introduced. There are several possibilities:
- make gem_renderMess a virtual function and reimplement it in
part_render.cpp without the problematic gem_state message
drawback: virtual functions are slow
- provide some mechanism to suppress the message
(setting a flag in the GemBase class)
drawback: a bit hacky
- call continueRender at the end of every render() call
drawback: lots of work
and don't forget the simplest solution:
4) suppress the last continueRender() call <snip> if(i<(cnt-1)){ continueRender(state); glMatrixMode(GL_MODELVIEW); glPopMatrix(); } } } void part_render :: postrender(GemState*){ glMatrixMode(GL_MODELVIEW); glPopMatrix(); } </snip>
so the last particle is rendered by the normal GemBase-call. to restore the matrices, postrender() has to be added.
I have implemented the first version already, could commit it, but I want to hear what you think first.
if there is another good reason to make gem_renderMess() virtual, why not. (although i cannot think of one right now, there might be a future)
Guenter
mfg.as.r IOhannes