Jump to content
  • Advertisement

Part_E

Member
  • Content Count

    15
  • Joined

  • Last visited

Community Reputation

100 Neutral

About Part_E

  • Rank
    Member
  1. Part_E

    C++ Organization Assistance Request

    I wouldn't resign yourself to global functions/objects just yet; as mentioned above, there are fairly straightforward object-oriented solutions to the types of problems you're trying to solve. (Assuming the goal is object-orientation, that is.) Also, what do the 'C' and 'O' prefixes to your class names stand for? [/quote] I manged to get it working by passing the TextureManager object by reference to the UI control constructors. But I don't know why I use C and O, really. It's pretty arbitrary, but it helps me. C for classes I'll only be instantiating one of, and O for classes that I'll be creating multiples of.
  2. Part_E

    C++ Organization Assistance Request

    Huh... Well I hadn't thought of passing a reference to the TextureManager object on to the UI control, but that's a viable solution. Wonder why I didn't think of it. But I am sort of using a flyweight design as it is. There's a universal OControl object which is extended by each of the controls and shares common methods between them all. As it is, each control object has a DrawControl() method to draw itself. So I can do things like: OControl *Controls[2]; Controls[0] = new OButton( x, y, ThisTexture, "ThisText" ); Controls[1] = new OProgressBar( x, y, AnotherTexture, Percent ); for( i = 0; i < 2; i++) Controls->DrawControl(); That's simplified, but you get the idea. Is this what you mean by flyweight design?
  3. Part_E

    C++ Organization Assistance Request

    Ok, I think I'm just going overboard with object orientation. I realized I don't really need a TextureManager class, since the GLuints it was storing were already being stored in other places. Now I just have some global functions floating about for LoadTexture() and everything is able to access them. I was just trying to avoid using global functions if at all possible.
  4. Part_E

    string compare or not to string compare?

    Oh, this is a scripting language. Guess I should've re-read the OP. Yeah, if this is just a scripting language you should be able to throw caution to the wind and just compare whatever you like. If it ends up running slowly, well that's the interpreter's problem ;)
  5. Part_E

    Delete List

    From what I've been told (I'm relatively new to this game stuff, myself) you'll want to do most (If not all) of your object creation in the initialization phase of your program. Dynamically creating and deleting objects always adds the most overhead to your project. Say you're keeping track of a list of entity objects in a game. It's typically better practice to load a bunch of these objects as empty objects at init and then just change out the data they hold as your game 'creates' and 'destroys' entities. So you're essentially just reusing the same objects over and over again rather than destroying and creating new ones. Just add an IsDead member and set it to true when you want to 'destroy' the object so the program knows this object is safe to re-purpose with a 'created' objects data. And If you do need to dynamically create or destroy lists of complex objects after init, plan on adding a load screen with a nice progress bar. And while you're at it you may want to do your mid-program object creation and deletion on a separate thread.
  6. Part_E

    string compare or not to string compare?

    As other's have stated an ID member is probably the way to go. If you're concerned about overhead, and you're definitely not tracking more than 256 objects, you can just store the ID as an unsigned char. Are these definitely objects WITH strings that you're storing though, or just the strings themselves? If just the strings themselves, consider instead an object class with and ID and string member. Then you could invoke a custom constructor to handle ID assignment and methods for ID comparison. Although I'm not sure why you need to compare lists of strings in the first place... Were you using the strings as a sort of ID and nothing more, or do you actually need the string data?
  7. This board has been such a huge help to me, I was hoping to further that trend with another (Hopefully simple) question: I'm nearly done with the skeletal framework of my game's openGL-based GUI system, but I'm having trouble organizing a few parts. To put it into perspective, I have a primary class named CGame, which extends CGUI. Mostly so actions from CGUI can bubble up to CGame and be interpreted and executed. I also have a TextureManager object that's created as a public member of CGame - It's intended to keep track of and assist in the loading openGL textures. So CGUI can access the TextureManager object in CGame via these methods I created (Along with corresponding virtual function declarations in CGUI): GLuint CGame::LoadTexture( SDL_Surface *TextureImage ) { return TextureManager.LoadTexture( TextureImage ); } GLuint CGame::LoadTexture( char *FileName ) { return TextureManager.LoadTexture( FileName ); } The problem is that I want the actual control objects that CGUI creates and tracks (OTextLabel, OButton, OProgressBar, etc) to be able to access these texture methods. So that when I create a new text label OTextLabel's constructor can request just a string, turn that into rendered text on an SDL_Surface, and then somehow call the LoadTexture method to load that surface as a texture and return the GLuint texture ID to be stored in OTextLabel. But OTextLabel can't see CGUI, or CGame, or TextureManager. And I can't quite wrap my head around creating accessors for it. Can anyone help? Let me know if more information is required.
  8. Part_E

    When To Stop Encapsulating? - C++

    Alright, sounds good then. More than likely I was looking at some old information. I've already pretty much scoured the internet for every STL example in existence by now it seems. And I should be OK on cleaning up considering I was creating, sorting and destroying dynamically allocated linked lists before vectors came along. Will this do? vector<OElement*>::iterator Iterator = ActiveElements.begin(); while( Iterator != ActiveElements.end() ) { delete (*Iterator); (*Iterator) = NULL; // <--- Is this actually necessary? I tend to er on the side of caution Iterator++; }
  9. Part_E

    When To Stop Encapsulating? - C++

    Ah, also, little bump here as I have another question: I've been reading in a few places that there are different implementations of the STL, specifically in regards to things like getting the sizeof a vector. Right now I'm using an ::iterator to loop through vectors, since that's the recommended method. But my main concern is that I'm trying to maintain cross-platform compatibility. Are there any other parts of the STL that may not be compatible across systems?
  10. Part_E

    When To Stop Encapsulating? - C++

    Alright, I've replaced all of my dynamic lists of objects with vectors of objects, at least in the GUI code so far, and everything seems OK - Perhaps even snappier ( I'm guessing because of the contiguous memory allocation ). And I think I'll stick with the switch statement for now since deciding to separate some of the GUI elements from my list of 'menu' objects, such as the main game HUD, conversation windows, labels, etc. So once the main game loads it'll be using event methods that're different from OnButtonAction, which itself will only apply to a handful of 'menus' with a handful of buttons. Thanks for explaining the STL though! I have a lot more reading to do, but it looks like boost also could really help with organizing my main game code. Entities and such. I also implemented that GUI_Element wrapper class [color="#413544"]Aardvajk suggested. Although I did split the vector of it into an ActiveElements and a StaticElements vector, respectively. Since I don't really care to iterate through static things like text labels and images when picking.
  11. Part_E

    When To Stop Encapsulating? - C++

    Ok, I'm converting my custom lists to STL equivalents. But I had one more question pertaining to basic class organization. I currently have this function here which processes basic mouse clicks: void CGUI::ProcessMouseClick() { if( !MenuList[CurrentMenu] ) return; if( OButton::HighlightedButton ) return OnButtonAction( CurrentMenu, OButton::HighlightedButton->Action ); } Where both CurrentMenu and Action just hold enumerated ID numbers. OnButtonAction is pure virtual in CGUI and actually implemented in CGame where a big switch statement resides. Based on the ID of the current menu (Which is just what I'm calling a screenful of UI elements) and the button action. Actually, here: void CGame::OnButtonAction( MenuType ThisMenu, ButtonAction ThisAction ) { switch( ThisMenu ) { case M_CHOOSE_RENDER: switch( ThisAction ) { case BA_TESTRENDER: CurrentState = TEST_RENDER; CGUI::OpenMenu( M_TEST ); break; case BA_MAINRENDERER: CurrentState = MAIN_RENDER; CGUI::OpenMenu( M_HUD ); break; } break; } } Originally I had wanted the ButtonAction member of OButton to be a function pointer which points to a virtual function that's actually implemented in CGame. So I could do something like: if( OButton::HighlightedButton ) OButton::HighlightedButton->*Action(); But that was a nightmare that I never got working. My question is, would the function pointer method have been a better option had I gotten it to work, or is my enumerated type solution viable enough? Also, are vectors of pointers pre-initialized with NULL or do I need to explicitly do that with the iota function or something?
  12. Part_E

    When To Stop Encapsulating? - C++

    Ok, well for most GUI elements I'll just be loading, indexing, and unloading as statically sized lists, so vector will probably be ok. No 'push to top', 'pop from middle', etc necessary. But that's good to keep in mind for the stuff that won't be so static. And please, be as technical as you freakin' want. I'm sick of tutorials pussy-footing around methods that're considered 'too complicated' even though they're the methods people actually, y'know, use.
  13. Part_E

    When To Stop Encapsulating? - C++

    I wouldn't call it bog standard. C programmers used to do stuff like this, but it is a pointless design choice in C++. It is never a good idea to mix up the implementation of an object with details of how lists of such object are stored, if for no other reason than it becomes impossible to take advantage of the standard libraries algorithms that generalise operations on lists of objects. You don't need to understand templates to use the standard containers. You are already using std::string, which is just a typedef of a template and essentially a container of characters. Start with std::vector and never look back. [source lang="c++"] class GUIElement { public: virtual ~GUIElement(){ } virtual bool IsHighlighted()=0; }; class Button : public GUIElement { virtual bool IsHighlighted(){ /* ... */ } }; std::vector<GUIElement*> elements; void f() { elements.push_back(new Button()); elements.push_back(new Button()); // for simplicity, ignoring iterators for now for(int i=0;i<elements.size();++i) { if(elements->IsHighlighted()) HighlightedElement=elements; } for(int i=0;i<elements.size();++i) delete elements; } [/source] It is as simple as suffixing the container type with the class you want in angle brackets. Then std::vector just works the same as a native array really. There are more appropriate solutions for storing containers of pointers but since you are new to the standard library, I'll ignore that for now. [/quote] lol - For the longest time I assumed <Vector>s were templates that stored an x, y, z coordinate and an angle. Y'know... Like a vector. Never realized they were actually containers for linked objects. That's much simpler than the custom methods I was writing to push and pop objects into linked lists and trees. Crud - Now this means I have to completely repurpose my octree code to use vectors =( Can I make vectors of vectors of vectors? Hmmm... Thanks though, Aardvajk.
  14. Part_E

    When To Stop Encapsulating? - C++

    Standard container? Like a GUI library or are you referring to C++ templates? If templates it's because no matter how many tutorials I read on them I still don't quite grasp the concept. Which is a shame because I do end up with quite a few objects with similar members. It's just that the only tutorials I ever find on templates are tutorials specifically about templates, which never offer examples of how you would actually use them. And all other (Game programming-specific) tutorials typically omit the use of templates. I'm guessing because explaining game programming concepts is difficult enough without also having to explain templates. But I revised it a bit, since HighlightedButton is a static member of OButton I just stuck it's assignment in the IsHighlighted(): bool OButton::IsHighlighted( int MouseX, int MouseY ) { if((MouseX >= X && MouseX <= (X + Width)) && (MouseY >= Y && MouseY <= (Y + Height))) { HighlightedButton = this; return true; } else if( this == HighlightedButton ) { HighlightedButton = NULL; } return false; } And my loop is now just: void CGUI::ProcessMouseMove( int MouseX, int MouseY, bool Left, bool Right ) { if( !MenuList[CurrentMenu] ) return; OButton *ThisButton = NULL; ThisButton = MenuList[CurrentMenu]->FirstButton; while( ( ThisButton ) && !ThisButton->IsHighlighted( MouseX, MouseY ) ) ThisButton = ThisButton->NextButton; } The ThisButton = ThisButton->NextButton is just bog standard linked list traversal.
  15. Quick question for those more versed in C++ than I. I'm working on a custom GUI for my demo (Lots of element objects), and I had a question about encapsulation. Say I have multiple button objects and I'm checking each on mouse move to see if any are highlighted (For picking / rollover purposes). Is it considered better practice to do the checking in the loop, or to have a method in the button object itself invoked for each button that does the checking? Here's my button object, set up currently to have each button check it's own bounding box - I've commented out the bit where it was checking in the loop by accessing the member variables of each button indirectly. while( ThisButton ) { //if((MouseX >= ThisButton->X && MouseX <= (ThisButton->X + ThisButton->Width)) && (MouseY >= ThisButton->Y && MouseY <= (ThisButton->Y + ThisButton->Height))) { if( ThisButton->IsHighlighted( MouseX, MouseY ) ) { OButton::HighlightedButton = ThisButton; ThisButton = NULL; break; } else if( OButton::HighlightedButton == ThisButton ) { OButton::HighlightedButton = NULL; } ThisButton = ThisButton->NextButton; } And here's the method for checking if the button is highlighted: bool OButton::IsHighlighted( int MouseX, int MouseY ) { return((MouseX >= X && MouseX <= (X + Width)) && (MouseY >= Y && MouseY <= (Y + Height))); } Actually, since HighlightedButton is a static member of OButton I could even set it inside the OButton::IsHighlighted() method
  • Advertisement
×

Important Information

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

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!