Finally, I understand!

This is a discussion on Finally, I understand! within the Game Programming forums, part of the General Programming Boards category; The age old question, it has plagued me.... Since I was just beginning turbo C++ graphics, now venturing into OpenGL ...

  1. #1
    Absent Minded Programmer
    Join Date
    May 2005
    Posts
    964

    Finally, I understand!

    The age old question, it has plagued me.... Since I was just beginning turbo C++ graphics, now venturing into OpenGL graphics... How do you actually make an object... GO AWAY!!!!

    Well if you want to look at it in a straightforward way, you can't, you cant make something you've drawn, disappear out of thin air, out of memory, out of everything...

    UNLESS

    If statements, they are my friend.... Why would you make a cube go away? because this and this and this happens, well...

    If this and this and this happens.....
    Draw the object!
    Else (it doesnt)
    Don't draw the object!.......

    A big fat function, right in your DrawGLScene, it controls what gets drawn and what doesnt, with ALOT ALOT of if statements...

    My only question now is, is this the best way to do it?

  2. #2
    Banned nickname_changed's Avatar
    Join Date
    Feb 2003
    Location
    Australia
    Posts
    986
    If I were using C++, I would start with a simple base class:
    Code:
    class Sprite
    {
      public:
    	bool Visible;
    	virtual void Draw();
    };
    Everything my application could possibly draw would inherit and implement this base class. Each object would have its own overriding Draw() method to draw itself. I would then have a list of objects to draw:
    Code:
    	std::map<int, Sprite> allSprites;
    Then in the drawing loop you described, I would go:
    Code:
    for (int i = 0; i < allSprites.length; i++)
    {
    	if (allSprites[i].Visible == true)
    	{
    	            allSprites[i].Draw();
            } 
            // no draw
    }
    Its a nice simple object oriented way of drawing. Polymophism is great because it lets each child class write its own draw method. But your main openGL loop doesn't need to know things for each object - all it needs to know is that its a Sprite (it has a Visible attribute and a Draw() method).

    Hope that helps

  3. #3

    Join Date
    May 2005
    Posts
    1,041
    In my own project I have a 'Renderer' class which holds pointers to everything that can be drawn. When I want something drawn, I just add a renderable object to the Renderer, and it handles it.

    edit:
    Everything my application could possibly draw would inherit and implement this base class. Each object would have its own overriding Draw() method to draw itself. I would then have a list of objects to draw:
    In my opinion, the Draw() function for each object should not actually draw the object. I think a centralized Renderer should be what actually does the drawing. I set my own engine up that way so that I can cut down on the number of state changes that need to be done in the graphics API that I use. Otherwise, whenever you have each object Draw()ing (heh) itself you need to keep track of what you draw before it and after it and keep track of what settings are on and what settings rae off and blah blah blah, and then you get speed impacted (doing a lot of state changes makes the rendering process go slower esp if you are doing material/texture changes). This comes from personal experience.
    Last edited by BobMcGee123; 06-06-2005 at 08:40 PM.

  4. #4
    Absent Minded Programmer
    Join Date
    May 2005
    Posts
    964
    I see stoveLP

    instead of creating a bool for each and every object you wish to draw, make a class that has the bool in it (visible) and link any other objects to that bool with the scope resolution operator....

    this is why I post here....


    To bob McGee....

    Currently I am fledgling programmer, therefore

    pointers = scary

    I'd rather go the other route stovelp said

    (correct stoveLP, I'm using Borland C++ builder)
    Last edited by Shamino; 06-06-2005 at 09:07 PM.

  5. #5
    Absent Minded Programmer
    Join Date
    May 2005
    Posts
    964
    Can anyone elaborate on what stovellp is giving me?

    like documentation or something?

  6. #6
    ---
    Join Date
    May 2004
    Posts
    1,379
    Please don't take this the wrong way but, Shamino, you really need to go back and learn this stuff. Take small steps instead of giant leaps.

  7. #7
    Absent Minded Programmer
    Join Date
    May 2005
    Posts
    964
    for christs sakes, this is a technique, not a written in stone something that they will teach you in the books...

  8. #8

    Join Date
    May 2005
    Posts
    1,041
    Hey whoa whoa calm down buddy. I understand what you are saying, but to be fair, if you don't know what pointers are or are not comfortable using them, then you sort of do need to do more work learning the basics.

    And, this IS in fact something that is taught in books and literature. A quick google search for a scenegraph (look at OpenSceneGraph) directly discusses ways to relate objects in engines and how to most effectively deal with them.

    Best of luck.

    edit:
    Can anyone elaborate on what stovellp is giving me?

    like documentation or something?
    Not really. Each object implements its own Draw() method and inherits itself from an abstract base class. An excellent method for starting out doing simple things. Perhaps my own suggestion is really only geared towards working with very complex objects that may require the implementation of widely different graphics routines.
    Last edited by BobMcGee123; 06-06-2005 at 10:16 PM.

  9. #9
    Super Moderator
    Join Date
    Sep 2001
    Posts
    4,913
    for christs sakes
    If you must blaspheme, at least do it in a grammatically correct fashion.

    Don't get so angry - if you're asking people to teach you stuff, they have every right to suggest you take things in smaller steps. You can't expect anyone to want to teach you advanced techniques (written in stone or otherwise) if you don't even pay much attention to the simple stuff.

  10. #10
    ---
    Join Date
    May 2004
    Posts
    1,379
    What stovellp is talking about is polymorphism, basic funtionality of C++. These are the things you should know.

  11. #11
    Banned nickname_changed's Avatar
    Join Date
    Feb 2003
    Location
    Australia
    Posts
    986
    Shimano although the getting angry wasn't necessary (or if it just came out wrong), I can empathize with you - although I understood OOP very well and how it worked years ago, it wasn't until I started working that I learnt how to use it. Yes, these are techniques, and you can only learn them from experience or when an experienced person teaches you.

    My advise would be to take what I've suggested, and just have a go at doing it yourself. If you get stuck, post your code. When you have something that works, post a sample and explain how you made it work and we'll go over it and offer ways to improve it. You can only learn by trying.

  12. #12
    Banned nickname_changed's Avatar
    Join Date
    Feb 2003
    Location
    Australia
    Posts
    986
    Quote Originally Posted by BobMcGee123
    In my own project I have a 'Renderer' class which holds pointers to everything that can be drawn. When I want something drawn, I just add a renderable object to the Renderer, and it handles it.

    edit:


    In my opinion, the Draw() function for each object should not actually draw the object. I think a centralized Renderer should be what actually does the drawing. I set my own engine up that way so that I can cut down on the number of state changes that need to be done in the graphics API that I use. Otherwise, whenever you have each object Draw()ing (heh) itself you need to keep track of what you draw before it and after it and keep track of what settings are on and what settings rae off and blah blah blah, and then you get speed impacted (doing a lot of state changes makes the rendering process go slower esp if you are doing material/texture changes). This comes from personal experience.
    Thats a matter of personal taste I guess. I prefer to think of my objects as independant. If I have a Knight object, I would have all the Move() actions on the Knight, and I would also put the Draw() method on the Knight.

    I do this with my business objects too. For example, if I have a User object that gets itself from the database, I would have user1.Load() and user1.Save() to read and write the database. However some people would argue that Load and Save aren't really actions performed by a User, they are just helper functions, so they prefer to use factories (ie a static User.Load() methods that return the loaded User object). The same argument would work for the renderer.

    I've seen it done both ways, and I've used both myself, and I really don't know which one is right, but personally I find the first way more convenient.

    Do you prefer:
    Code:
    User me = new User();
    me.Name = "Paul";
    me.Paddword = "OrangesShmoranges";
    me.Save();
    
    // or
    
    User.Save(me);

  13. #13

    Join Date
    May 2005
    Posts
    1,041
    Thats a matter of personal taste I guess. I prefer to think of my objects as independant. If I have a Knight object, I would have all the Move() actions on the Knight, and I would also put the Draw() method on the Knight.
    I understand what you are saying and agree with you in probably every other scenario (I would choose the first method in your example), but when it comes to rendering I found that the easiest and most efficient way to handle it is to have a centralized renderer that knows how to do the actual drawing and each actual object such as a knight just adds itself to the renderer in its own draw() function. Not to be confusing, but the renderer doesn't know how to draw a 'knight', but it does know how to draw a 3D model with the appropriate texture and perhaps lighting information, and the knight just says 'Renderer, add a 3D model with this lighting information to the rendering list for this frame'.

    As I stated, the biggest problem I had with each object overriding its virtual Draw() method is keeping track of the 3D graphics API states. If you render a knights, then a transparent sprite, then another knight, then you've got to switch in and out of states. If every object just adds itself to the renderer, and then at the end of the frame the Renderer draws all of the knights' 3D models, and then draws all of the sprites, and then the next type of object etc, then it can avoid doing needless state changes. Avoiding doing needless state changes is good because it makes it easier for the programming to keep track of things, and it also makes the actual rendering process go faster, especially if you can batch together material and texture calls (for example, if you just have a generic 'Particle' texture, you can just bind the particle texture once and then draw all of the sprites. If you are doing billboarded particles then you only need to apply the appropriate BillBoard transformation matrix to the 3D API matrix stack once before drawing the sprites).

    Again, this really is specific to graphics, and while I believe is more efficient isn't exactly easy to implement.
    Last edited by BobMcGee123; 06-07-2005 at 08:51 AM.

  14. #14
    Absent Minded Programmer
    Join Date
    May 2005
    Posts
    964
    yes, I went a little overboard

    it gets frustrating when every time you ask a question about anything someone posts and says you should go back to the basics, when this is the basics, and i'm asking about it...........

    thanks stovellp your posts are quite useful

  15. #15
    Wen Resu
    Join Date
    May 2003
    Posts
    219
    What i did,
    I made a class to be the artist. its comprised of several primitive drawing functions. each of my classes <sprites> had a draw routine to which you pass an artist reference. the object then uses the artist to draw itself.
    also i'm using Stovellp's OO idea with a virtual draw

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Example from book, don't understand.
    By RealityFusion in forum C++ Programming
    Replies: 1
    Last Post: 09-30-2005, 03:47 PM
  2. Don't understand
    By jaylc185 in forum Game Programming
    Replies: 2
    Last Post: 05-24-2005, 07:29 AM
  3. Need help to understand this STL code.
    By Hulag in forum C++ Programming
    Replies: 3
    Last Post: 04-26-2005, 01:59 PM
  4. please help me understand the euclids algorithm
    By xerxes1986 in forum C++ Programming
    Replies: 15
    Last Post: 03-02-2005, 07:58 PM
  5. I don't understand K&R example
    By rllovera in forum C Programming
    Replies: 8
    Last Post: 10-25-2004, 10:45 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21