int Number_of_Successfull_Initializations;
if( !InitWindow() )
{
return false;
}
if( Number_of_Successfull_Initializations = Display.Init(hWnd) +
Scene.Init(&Display) + World.Init( &Interface, &TextureManager ) +
Interface.Init( &Scene, &TextureManager ) != 4 )
{
MessageBox( hWnd, "I knew this was a sloppy method!", "Error", NULL );
return false;
}
return true;
Is there a cleaner way?
Author
I am trying to work on the beginnings of my own feeble 3D engine, but im not liking a certain way that my core objects work together, its just not clean at all. Could any of you C++/OOP fanatics help me figure a better way to link my objects together than this?
This is obviously not what I actually typed into my code but its the general idea. This represents the body of my App::Init() function more and less, and those objects initialized are members of cApp. The Inits are mostly there to link the core objects together and I HATE how that works. Is there a better way? Should I lose the cApp class and make the core objects global? How should I work this?
~Vendayan
Why not
if( !Display.Init(hWnd) ||
!Scene.Init(&Display) || !World.Init( &Interface, &TextureManager ) ||
! Interface.Init( &Scene, &TextureManager ))
Since C++ has lazy evaluation, your code will attempt to init everything regardless of failures. This snippet will stop initing once a failure is detected. Also in your code you have to put parentheses around the assignment, because its precedence is less than that of comparison.
if( !Display.Init(hWnd) ||
!Scene.Init(&Display) || !World.Init( &Interface, &TextureManager ) ||
! Interface.Init( &Scene, &TextureManager ))
Since C++ has lazy evaluation, your code will attempt to init everything regardless of failures. This snippet will stop initing once a failure is detected. Also in your code you have to put parentheses around the assignment, because its precedence is less than that of comparison.
Author
Sorry for the sloppy coding, my biggest issue though is not in how that statement is evaluated, but in how my objects are linked.
Its simply not clean to initialize them all with pointers to one another is it? For instance when the 'World' class (which contains my geometry, textures, character managers, AI and everything else of the sort) decides that the player has died, it will call a method of 'Interface' letting it know to drop the hp meter to 0% and not to allow the player access to certain menus and buttons that are only used the the player is alive.
I just hate the idea of having to give practically all of my objects m_p's to each other in order for them to interact. Does anyone have a better way?
~Vendayan
[edited by - Vendayan on June 26, 2002 12:52:51 AM]
Its simply not clean to initialize them all with pointers to one another is it? For instance when the 'World' class (which contains my geometry, textures, character managers, AI and everything else of the sort) decides that the player has died, it will call a method of 'Interface' letting it know to drop the hp meter to 0% and not to allow the player access to certain menus and buttons that are only used the the player is alive.
I just hate the idea of having to give practically all of my objects m_p's to each other in order for them to interact. Does anyone have a better way?
~Vendayan
[edited by - Vendayan on June 26, 2002 12:52:51 AM]
I don''t think that having member pointers to other objects is such a bad idea. But if anyone knows a better way (i''m sure they exist) then i''d be interested to hear too.
Indirectx: "Since C++ has lazy evaluation, your code will attempt to init everything regardless of failures. This snippet will stop initing once a failure is detected. "
Doesn''t that contradict itself - "your code will attempt to init everything regardless of failures" "will stop initing once a filure is detected."
Which way is it?
I''m not sure whether C++ is strict or lazy evaluated but if it is indeed lazy then I would have thought that it will stop once a failure is detected and not bother executing the other functions in the if statement (since one of the ORs has already returned a true condition).
Gobsmacked - by Toby Murray
Indirectx: "Since C++ has lazy evaluation, your code will attempt to init everything regardless of failures. This snippet will stop initing once a failure is detected. "
Doesn''t that contradict itself - "your code will attempt to init everything regardless of failures" "will stop initing once a filure is detected."
Which way is it?
I''m not sure whether C++ is strict or lazy evaluated but if it is indeed lazy then I would have thought that it will stop once a failure is detected and not bother executing the other functions in the if statement (since one of the ORs has already returned a true condition).
Gobsmacked - by Toby Murray
Author
IS it ok for me then to simply initialize all of them with pointers to one another like that at the same time or is there another way to handle that?
quote:Original post by tobymurray
Indirectx: "Since C++ has lazy evaluation, your code will attempt to init everything regardless of failures. This snippet will stop initing once a failure is detected. "
Doesn''t that contradict itself - "your code will attempt to init everything regardless of failures" "will stop initing once a filure is detected."
No, I just said it poorly. The original code, with +, will try to init everything and then either fail or succeed. My code, with ||, will stop initing once an error is detected.
quote:
I''m not sure whether C++ is strict or lazy evaluated but if it is indeed lazy then I would have thought that it will stop once a failure is detected and not bother executing the other functions in the if statement (since one of the ORs has already returned a true condition).
Yup.
--
quote:Original post by Vendayan
IS it ok for me then to simply initialize all of them with pointers to one another like that at the same time or is there another way to handle that?
Well, the texture manager seems to be a good candidate for a singleton, as does Display. There are several articles here on Gamedev about singletons.
What does Interface do?
I would think that Scene should be included in World. Then World''s Init will call appropriate Scene methods. Does your Scene handle only one or all scenes?
Author
ok as for cInterface, it will more or less be an object defining my game interface and it will also be an ecapsulation of DInput since well... thats that a game interface does by definition, interface user input with game mechanics. As for the scene object I''m not entirely sure how much it will be needed but my intentions are to make it a layer between the models and the display, it should preform any last minute optimizations needed to reduce overdraw and then perform most of the rendering. Just something im experimenting with.
~Vendayan
~Vendayan
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
