Hi fellow coders, since everyone it seems are contributing to the
"Rift Diskmag" effort I thought I'd write a little tutor on
coding demo's OOP style. I'm no expert on the subject but I
thought I'd just share some of my ideas with you. You know the
drill if you're pc blows up it's prob. you're fault and not mine.
Demos in C++ are you mad, too much overhead...
( sighed the foolish man ) Overhead is not the issue, most
compilers these days have a fielday when it comes to c++
Well consider the following
If you have a nice standard interface for you're demos and you
have more than one person working on the demo and parts then OOP
is the way to go.
example.
The person who coded the demo engine does'nt know how the groups
members coded their parts but since we're using the a OOP model
he doesn't need to know or care. All that matters is that the
coders know how to interface with the demo and follow the rules
set down but the engine coder.
Let's have a closer look.
--part.h-- class Part { public: virtual void init() = 0; virtual void loop() = 0; virtual void render( int32 *) = 0; }; --effect1.h-- class Effect1 : public Part { public: virtual void init() { // load all the graphics and tables }; virtual void loop() { // calculate values }; virtual void render( int32 *buffer) { // render all graphics to buffer }; }; --main.cpp-- void main(void) { // setup graphics & sounds // get a pointer to the drawing surface/buffer = buffer; effect1 sine_blob; // preload all demo events; sine_blob.init(); while ( !demo_end ) { // check key events sine_blob.loop(); sine_blob.render( buffer); } }
As you can see from the above listings we have our parts
inheriting the part class thus creating a standard interface for
all the demo parts. Thus you can ask one coder to write let's say
a sine_blob routine aka effect1 and he knows what the demoengine
is only interested in the 3 virtual functions init, loop & render.
This is the easy way to get people to work together. You don't
have to worry about coding crashing other code or strange things
since all you're part code is in it's own class.
Nice and clean and you don't need to flog you're coders to focus.
But what if I have a demo with more than one part, wise ass?
Well who has a demo with more than one part ?? ok well since
everyone put their hands up I'll show you how I did it using
scripting.
consider the following.
we change the above code as follow.
example
script_t script[]={ { 1, 1, Part_intro }, { 1, 5, Show_picture }, { 3, 4, Part_3d }, .. .. .. { 100, 2, NULL} }; void Part_intro () { active_part = lens_part; } void Show_picture () { active_part = NULL; // no part is being called instead // display a picture loadAndShowPic( buffer, "pic1.tga"); } void Part_3d() { active_part = lens3d_part; }
and so on.
As you may have noticed we changed the pointer to NULL in the
show_picture function. We will have to check in our main loop
for NULL pointers and ignore them. This is just a cheap way to
display pics etc etc. You can of course make a part that
displays pics.
Let's face it, C++ has not been the best way to do things in the
past but then again ignorance is bliss. C++ has almost come of
age and things are looking up OOP wise for demos.
I hope you could make some kinda sens from my lucid ramblings.
I'm not the best person to explain things.
Enjoy you're coding and see you all at optimise 99.
viper/Serenity
vpr@quakclan.net
greetings go out to
caz, maverick, rawhed, deadpoet or was that deadpot, saurax, jahya, get-a-fix, zeroimpact,
meeku, neuron, riot, AJ, Serenity, Atomic Warloks, Shunt, OO, SO