Share on other sites

Share this post

Link to post

Share on other sites

I agree, it does seem to be "difficult" ... Thats probobly why many people have yet to adopt object oriented programming fully. (That, and many people hate 'new' things. Even if the thing has been around for 30 years and is only new to the person in question hehe)

But what might offer some insight is the reason that I didnt switch to full on object oriented programming until recently:It forces you to plan. Plan plan plan. Every detail. If you have a shoddy functional program design, it is easy to make it work and keep working on it, figuring the plan as you go.

With full object oriented code, I find I run into a dead end where I _must_ refactor if the design isnt clean enough. (This is a good thing!)

Too much work to hack up a quick program, and more thinking than coding goes into a project.

Then again, those arent good reasons. There just reasons.

... my 2 cents.

[edited by - Kevlar-X on December 14, 2002 7:46:42 PM]

0

Share this post

Link to post

Share on other sites

Kevlar is correct. To be fast in 3D you must do it how the hw likes it and not the other way around. Too bad hw isn''t oop. Also, engines are evolutionary where lots of code gets thrown out during dev. stages and is not oop friendly. This breaks down any planning you had thought of previously. New hw features or techninques come completely invalidating your old code base note lightmapping to real-time per-pixel lights/shadows. Notion of light in lightmapping code doesn''t make sense while it does in per-pixel light code. Major reason is that hierarchies and extended planning locks you in, this is completely orthogonal of how engines/tools are produced. You just don''t keep on using 10 year old code base in gfx development as the technology moves too fast. Notice performer and d3d retained mode situation. Or Java3D scene graph. Very few if anyone is using them for games. They''re slow and frequent new tech. makes them obsolete thus need to be rewritten invalidating user''s entire code structure. Plus lang. authors want you to buy their books so they start the propaganda machine and newbie is then led to believe that oop is the only way to program. Then newbie gets frustrated when everything doesn''t fit his new found oop paradigm and he gives up programming because it just became too hard. If you''re spending more time in c++ standard book or in design stage rather then writing your game code then something went wrong on the way to kansas, toto. In the real world, you need to produce code fast and have a product on the store shelves pronto otherwise you don''t eat and die. Real life sucks

Share this post

Link to post

Share on other sites

It isn''t difficult once you got the rule. As Kevlar said, you should have almost the entire program design wrote down into paper before you can start writing a single line of code, but not necesarily, and that can also be applied to linear programming.

I find OOP a good way to "encapsulate" low level programming into a higher level structure, easy to understand, hard to mess with (because it protects data from dirty hands like mine), easy to scale and easy to mantain. After you write the structure, then you only play with objects, properties and actions (methods), like playing with toys. Of course writing those objects isn''t easy, but it isn''t harder than writing global functions.

my 0.10 cents.

0

Share this post

Link to post

Share on other sites

Correct xaxa. Your engine must have some kind of structure in order for you to make head or tail of it. You can use high level constructs if you think they will help out but you shouldn't force yourself into using them on something that would just not work well. Engines are evolutionary and you won't have all the pieces nailed down because of this. You should accept that you will find new ways to do gfx stuff as you progress and your framework should take this into account. Two things helped me the most were object data encapsulation and breaking my functions into blocks that could be reused and more complex algos created from the simple functions. I don't use inheritance nor oop as much as I used to because it hides your intent and makes it harder to understand. Inheritance sometimes works well othertimes the meaning of inheritance doesn't make as much sense on some objects.

[edited by - JD on December 15, 2002 5:28:30 PM]

0

Share this post

Link to post

Share on other sites

If your engine framework can''t handle the addition of per-pixel lighting effects, then take the opportunity to determine why the design failed and learn from it. How could it be redesigned so that adding this effect would be easy? I''m actually interested in how using an OOD could make adding that harder than if a modular or procedural design was used? It seems it would be about the same.

How is added support for a custom pixel shader any different than adding/having support for different vertex formats? And your going to want your engine to support more than one format.

It has long-reaching consequences with the material that the engine renders, but it doesn''t seem hard to add the capability to an existing engine.