Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Cybird

Heavy C++ use overhead

This topic is 5903 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Small question Im planning to do a heavily object oriented 3d engine. I just wanna know if using C++ specific code, like Polymorphysm, exceptions, virtual functions is viable for a 3d engine. It is REALLY slower? I know it is a bad idea to make core engine specifications as virtual functions, but for the ones that are calld less times?

Share this post


Link to post
Share on other sites
Advertisement
*Technically* it is slower, but unless your name is John Carmack or Mel that difference will be completely undetectable compared to all the other things slowing down your code (and frankly even John Carmack is saying good things about OO). Basically if your OO engine runs at 100fps on a GeForce4 super system, it will run at 100.05fps if rewritten to not use OO. Considering all the time you save, both in coding and in debugging (OO makes it so much easier to prevent, find and fix bugs), I would say OO is the way to go.

Share this post


Link to post
Share on other sites
It''s slower...

But I recommand you to do this.
I have a 3D engines which use many virtual functions. In 2 day I add a new platform or a new 3D API in my 3D engine.
In fact 3D engines are so complex that you can optimize many things else before to worry about latency create by virtual functions.

Good luck

Share this post


Link to post
Share on other sites
It''s slower... if used badly and in bad designs.

For example going overboard and having a CPixel class, a CVertex class and a CPolygon class all inherited from some CObject class, all with virtual accessor functions is going to get you hideous performance. But that is due to inappropriate use of the language rather than the language being slow.

If on the other hand the lowest level you get is CMesh, CMatrix etc, then it''s *extremely* unlikely it would be slower than plain C unless you''d made some bad coding/design mistake.

In fact in some circumstances you''d actually get faster code due to the compiler knowing more about the constraints on data (const correctness, aliasing etc).


Having said that, exceptions and RTTI are often best avoided since many *implementations* of them tend to add a whole bunch of extra code to make them work. The features themselves aren''t a problem though - it''s just I''ve never seen a good compiler implementation of them. STL should be fine on most platforms, though some of its memory allocation patterns in certain implementations might not suit you, particularly on some fixed memory platforms like games consoles.


[I''m only using the Cxxx naming convention to emphasise that I''m talking classes - personally I tend not to use it]


In our engine we make use of C++ features in most of the higher level code, and a few lower level parts such as:

- Maths functions (being able to do vector1+=vector2 type things is so much nicer than directly calling a C function to do it).

- Management lists/containers (lists of buffers, textures, etc). Templates and a few choice base classes can greatly simplify much code.

- Device, view, display command handling. We had a single D3D adapter encapsulated in it''s own "Adapter", making multiple Adapter classes allowed us to add multimonitor support in less than a day. (Though it was one thing thought of at the design stage)


I suppose it depends how heavy you mean. In some places for example we pass "command" structures where in a more OO world we may say use a Command pattern.

Learn the costs of each OO feature, then decide at each stage of your engine *design* "is this being called at such a high frequency that the 2 cycle overhead for XX virtual function call is going to have a negative impact". Careful design is the key to good OO/C++ and optimal use of it.

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites
In fact, i saw the OGRE s Engine source code, as well as its documentation, wich is an example model to follow, i think.


They made heavy use of inheritance, exceptions, and templates.

The immediate result is their code is really easy to follow and understand, all seems to be so natural.

The power of the processors, I think, is not more the bottleneck in a 3d engine. Because in ideal hardware conditions, they are only doing some physics and AI calculations, wich is, depending of the physic and AI not too costly.

well.


thanx foir the answer...


Share this post


Link to post
Share on other sites
It's not a question of OO being faster or slower. Your implementation will be the deciding factor.

Virtual functions in OO are probably faster than trying to "virtualize" your code written in C or Pascal, i.e. heavy use of switch-case, and can be easier to write and maintain.

Member functions are really no slower than passing in a pointer to a struct, and the code of your member function can be quite clean.

And with C++, you can step out of the OO realm when necessary to write time-critical, optimized code.

C++ often grabs lots of stack memory in certain circumstances involving copy operations. It's best to learn how that can happen and learn the ways to avoid it if such stack use isn't really necessary.

It's sloppy, careless use that can give C++ a bad rap, but it can be blazing fast if you use it smartly.

Value of good ideas: 10 cents per dozen.
Implementation of the good ideas: Priceless.

Proxima Rebellion - A 3D action sim with a hint of strategy

[edited by - BS-er on July 24, 2002 9:56:49 PM]

Share this post


Link to post
Share on other sites
Odd thing, I saw this topic and reluctantly opened it up because I assumed that that original poster would get flamed with a bunch of uninformed, unexperienced bashings against OO in game programming.

Does this mean that the game programming community in general is finally warming to OO?


*If this gets posted multiple times I''m sorry, but I keep getting an SQL timeout error..

_____________________________________________
Come join us on IRC in #directxdev @ irc.afternet.org

Share this post


Link to post
Share on other sites
The finishing touches of DooM III was writen in C++
(I don''t think Carmack will touch it with a ten-foot pole yet, but we may be surprised with Quake 4).

Share this post


Link to post
Share on other sites
The finishing touches of DooM III were writen in C++
(I don''t think Carmack will touch it with a ten-foot pole yet, but we may be surprised with Quake 4).

Where the Quake III engine has an advantage over a design like ORGE, is in cache coherency. With the OO scene-graph, you can jump all-over the memory space of the CPU each step the rendering. With Quake''s deterministic BSP trees, and flat player & projectile list, everything that the uses the same code is garuanteed to be rendered sequentially (there by minimizing CPU cache misses).
ORGE''s advantage is that it''s vastly more flexible.

Carmack also manages his memory efficently, whereas ORGE manages it''s memory automatically.

Carmack also performs extensive empirical studies to determin the optimal batching order for the rendering (seeing how grx card companies give him prototypes, this is hard to compete with).

Those three things are why the Quake engines have the highest frame-rates (along with high quality).

Share this post


Link to post
Share on other sites
The finishing touches of DooM III were writen in C++
(I don''t think Carmack will touch it with a ten-foot pole yet, but we may be surprised with Quake 4).

Where the Quake III engine has an advantage over a design like ORGE, is in cache coherency. With the OO scene-graph, you can jump all-over the memory space of the CPU each step the rendering. With Quake''s deterministic BSP trees, and flat player & projectile list, everything that the uses the same code is garuanteed to be rendered sequentially (there by minimizing CPU cache misses).
ORGE''s advantage is that it''s vastly more flexible.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!