I got something working the way I want it to work, but now have ?.

RHLinuxGUY · 04-01-2006, 04:49 AM

After several grueling days of working/school/familycomputerhelpthatIusualycannotfix/repeat(till now) I finaly got a chance to work on my game, and made an acomplishment. For a long time I couldn't have an object move on my program without leaving itself the space before it. So the screen would eventually fill up with that object. Now I got it so when you have the object move from on location to another, it recreates the background so not to have to show where the object I am moving was before. (pats himself o back, me gives me money for a night at the roxbury) Now my question is if my way of coding is "efficient". Even though it works, over the course of my self tought course of c++, I have realized that even though something may work, it may very well effect me dramaticaly if I do something else that I have no need for at the/that moment. (no sarcasm intended) So if someone can take a quick review of my code (you really only need to read the main.cpp.(just about all the major changes have been done in this file, and it is only 122 lines long.) You can find my updated files along with my newly added-- but still being worked on-- comments at http://pntbalg.shackspace.com/GeorgeLair/040106
put it somewhere, go into a command line and type "make". If there is anything that could have been done better that I have absolutely not a trace of attempting to do implement it into the code, I would like to know, how it should be done and why you believe it needs/shoud be done. Thank you in advance!

xhi · 04-01-2006, 02:02 PM

i took a quick look at the code and can give you one suggestion anyhow..

the way that display_bmp(..) works is extremely inefficient because it makes you to load the image source for every draw.. which can be be many times per second, and a load from file is pretty expensive.. the normal way to handle this would be to load the bitmap once and not unload it until you are done with it.. consider this untested snip..

Code:

class Foo {
  public:
    Foo(const char* imgPath, int x, int y, SDL_Surface* s){ 
        mainScreen=s;
        tile=SDL_LoadBMP(imgPath);
        position.x=x;
        position.y=y;
        position.h=tile->h;
        position.w=tile->w;
    }
    ~Foo() { SDL_FreeSurface(tile); }
    void draw(){
        SDL_BlitSurface(tile, 0, mainScreen, &position);
    }

  private:
    SDL_Surface* tile;
    SDL_Rect position;
    SDL_Surface* mainScreen;
}

now this object will be loaded one time on creation and not unloaded until you are done with it.. this is one way to make your onscreen objects more efficeint.. however the drawback here is that if you have a hundred of these objects, you will have one hundred loads of the image, which still is not efficient, but is far better that loading a hundred objects several times per second.. so you could go even further and have a resource manager, that will load resources so that they can be shared among objects. so for a hundred objects you would only need one load of the resources..

anyhow just somthing to think about..

ta0kira · 04-01-2006, 02:07 PM

The way a lot of graphics work is each object has its own "canvas" (the way Java words it.) The main program keeps track of where the objects overlap, and each object has a "refresh" type function that basically undoes the mess something else has made of it. In your case, the background would be an object, and the object moving on it would be an object; each having their own canvas and refresh functions. To make things more efficient, you could section off the background, and have the main program call the refresh function for the particular sections affected by the object as it moves. The refresh functions don't necessarily have to redraw everything from scratch; that's the place where you will optimize for speed. I don't have a lot of experience with that, however.
ta0kira

xhi · 04-01-2006, 02:30 PM

yes that is another common technique that ta0kira mentioned, however in 2d i have found that it is far easier to just assume a background redraw every frame.. the gain of determining redraw regions is small, and when you have many moving objects on the screen you are more likely to lose performance rather than gain.. a blit of an unanimated background is not very expensive..

however once you get into 3d stuff this technique is essential..