man, you guys shure like to complicate stuff.

Basicly what i do is i store all textures/shaders in one shader class, the same with objects and everything else.

I automate everything and then some.
if i want to load a object full with textures and other important stuff i just call

CFdraw dm;
dm.loadObject(ENT_LOAD,0,"object.cfmd");

CFdraw is my renderlist class, it takes a list of different rendering steps and runs them.
It allso loads the stuff into static variables so once loaded i can access it from anywhere in the code.

---------------------------------
For an overdose of l33tness, flashbang.nu

quote:
man, you guys shure like to complicate stuff.

Basicly what i do is i store all textures/shaders in one shader class, the same with objects and everything else.

If this is as it sounds you''ve just demonstrated how NOT to use OOP, and have probably made things more complicated than they need to be.

quote:
if i want to load a object full with textures and other important stuff i just call

CFdraw dm;
dm.loadObject(ENT_LOAD,0,"object.cfmd");

And how is that any less complicated? Behind that loadObject() function you still need to load and manage your textures, models, etc.

quote:
Original post by lc_overlord
It allso loads the stuff into static variables so once loaded i can access it from anywhere in the code.

This ISN''T a good thing. For small projects you can get away with it but the bigger you get the more unmanagable and bug-prone this will become.

quote:Original post by llvllatrix
From my experience it seems that more automation is inversely preportional to flexibility. This should be obvious; its the reason why opengl is so powerful to begin with.

I think this is where OOP shines. With a well designed class hierachy I think that both can be achieved. Any desired changes to the default functionality can be achieved by deriving from the existing classes. While the same is possible without OOP by using function pointers, I find it far easier to manage using OOP.

quote:Original post by llvllatrix
From my experience it seems that more automation is inversely preportional to flexibility. This should be obvious; its the reason why opengl is so powerful to begin with.

that is if you want total controll of everything that happens.
Beleve me, there is no need if it's programed right.
Shure it's hard coding it from the begining, but hey, in the state my engine is now i can make a small(but still good) game/demo in under a day.

quote:Original post by joanusdmentia
If this is as it sounds you've just demonstrated how NOT to use OOP, and have probably made things more complicated than they need to be.

Who ever said that pure oop is the best thing that ever happend.
infact if you use to much oop there is a large probobility that you are going to feed the wrong variable somewhere(because you don't know witch one your sending) and everything is going to hell.

quote:Original post by joanusdmentia
And how is that any less complicated? Behind that loadObject() function you still need to load and manage your textures, models, etc.

Yes, but so do you, mine does it automaticly, does yours?

quote:Original post by joanusdmentia
This ISN'T a good thing. For small projects you can get away with it but the bigger you get the more unmanagable and bug-prone this will become.

True, but that is allso true for everything else.
But my engine was designed for flexibility, it was designed so that i could just take any part of the basecode i needed and use it in a project.
It was allso designed in a way so that i could develop different parts of it in other places.
This meant that all my classes had to be selfcontained in some way, it should not depend on any parant class using it allthough it might use other classes) and it has to be global so that all parts if the code can access the information(those parts that it is alowed to access anyway), without having to pass that class around.
Statics does the job just fine.

---------------------------------
For an overdose of l33tness, flashbang.nu

[edited by - lc_overlord on May 9, 2004 8:20:39 AM]

quote:Original post by lc_overlord
infact if you use to much oop there is a large probobility that you are going to feed the wrong variable somewhere(because you don't know witch one your sending) and everything is going to hell.

This has absolutely nothing to do with OOP.

quote:Original post by lc_overlord
Yes, but so do you, mine does it automaticly, does yours?

sceneGraph.AddNode(new GameObject("filename.ext"));  

If that's what you call automatic, then yes. ANY decent design won't have you typing the same 10 lines of code every time you want to load an object. I still fail to see how you think yours is any less complicated.

quote:Original post by lc_overlord
True, but that is allso true for everything else.

Yes, but with varying degrees. Larger projects will always be more complicated, but a good design will make this less of an issue.

quote:Original post by lc_overlord
But my engine was designed for flexibility, it was designed so that i could just take any part of the basecode i needed and use it in a project.
It was allso designed in a way so that i could develop different parts of it in other places.
This meant that all my classes had to be selfcontained in some way, it should not depend on any parant class using it allthough it might use other classes)

This can all be achieve without using global variables (which you effectively have with publicly accessible static variables), whether the design is OO or procedural. As for dependencies between classes making a variable static makes no difference, the class will still need to know the definition of the static variable's type regardless.

quote:Original post by lc_overlord
and it has to be global so that all parts if the code can access the information(those parts that it is alowed to access anyway), without having to pass that class around.
Statics does the job just fine.

And how do you ensure that parts that aren't allowed to access it don't?


[edited by - joanusdmentia on May 9, 2004 10:38:29 AM]

quote:Original post by joanusdmentia
And how do you ensure that parts that aren't allowed to access it don't?

It's a secret. =)

I actuarly don't have any reason to restrict information that mutch, i just keep some internal stuff private cause i can (like counters and such).
But the thing is that no other code than the code in the class can freely read/write/see/everything in those statics, so any data i want programs to read i just pass along trough special functions(witch there arn't that many of), it's a neat arangement that works verry well.

quote:Original post by joanusdmentia
If that's what you call automatic, then yes. ANY decent design won't have you typing the same 10 lines of code every time you want to load an object. I still fail to see how you think yours is any less complicated.

that specific function is perhaps not.
But i have worked hard to make it extra clear, intuiative and easy to code, that has to count for something.
But then again it's not finished, i am allready in on my third revision of the renderlist system, and im pretty shure i will have one or two more revisions.
(the first two was just an large array of numbers i passed to the render list).

the only thing i can say is that your way looks frightenly simmilar to the gamebryo basecode, and i still don't get it (nore does any of our programmers) after we have been working on it for a month or so.

---------------------------------
For an overdose of l33tness, flashbang.nu

[edited by - lc_overlord on May 10, 2004 4:05:06 AM]

quote:Original post by lc_overlord
It''s a secret. =)

Good answer, but I ain''t signing no NDA

quote:But i have worked hard to make it extra clear, intuiative and easy to code, that has to count for something.
But then again it''s not finished, i am allready in on my third revision of the renderlist system, and im pretty shure i will have one or two more revisions.
(the first two was just an large array of numbers i passed to the render list).

Heheh, I''ve lost count of the number of times I''ve restarted writing my engine

I guess it comes down to personal preference as well. If your not used to a particular style then its naturally going to be more difficult to get their head around.

quote:the only thing i can say is that your way looks frightenly simmilar to the gamebryo basecode, and i still don''t get it (nore does any of our programmers) after we have been working on it for a month or so.

Can''t say that I''d even heard of the Gamebryo engine before, although I recognized the games on the site. Not sure what skill level you and your programmers are, but keep in mind that it is a commercial engine intended for professional game developers. I''m not saying that indie developers are sub-standard, but as a general rule we don''t have the same level of experience. If a design of mine looks like that a commercial engine then I''ll take that as a compliment