A good graphics library?

This is a discussion on A good graphics library? within the C++ Programming forums, part of the General Programming Boards category; Consider using a cross-platform library like the SDL. Seriously. Your code might be infinitesmally slower -- but not much, especially ...

  1. #16
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    Consider using a cross-platform library like the SDL. Seriously. Your code might be infinitesmally slower -- but not much, especially with the SDL, because SDL uses DirectX behind the scenes. And your code will run on Linux, Windows, Mac, various BSD variants, and almost any modern operating system you could care to name. From libsdl.org:
    SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported.
    If all you're doing is painting pixels, you really, really don't have to worry about speed. Even if you're doing quite complicated things.

    What kind of computer are you using, that you should be worried about speed? My parallax main menu for xuni, written with the SDL, has no trouble running at 30FPS under 800MHz. And I haven't optimised it yet very much.

    As a side note, I'd recommend the SDL over Allegro, because Allegro is older and doesn't really support Windows too well, IIRC. Just DOS, not DirectX. (That would make the SDL faster.) Allegro does have more extensive support for loading images and rotating them etc, but the same functionality can be had with the SDL with additional libraries such as SDL_gfx (SDL Graphics) and SDL_Image. Worry about that when you come to it.

    Gotta love SDL_Image:
    SDL_image is an image file loading library.
    It [...] supports the following formats: BMP, GIF, JPEG, LBM, PCX, PNG, PNM, TGA, TIFF, XCF, XPM, XV
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  2. #17
    Registered User Devils Child's Avatar
    Join Date
    Jan 2008
    Posts
    244
    ok. so all i want to do is write pixels either for a software-renderer, a raytracer or a raycaster. i cencearly want the easier way. is that gdi or sdl?

    anyhow... if i use sdl, i have to add it to cpp somehow and the readme.html didnt help me, also there were many infos about how to add these libraries. i guess i have to learn more about c++...

    so: gdi / sdl ?

  3. #18
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    Quote Originally Posted by Devils Child View Post
    ok. so all i want to do is write pixels either for a software-renderer, a raytracer or a raycaster. i cencearly want the easier way. is that gdi or sdl?

    anyhow... if i use sdl, i have to add it to cpp somehow and the readme.html didnt help me, also there were many infos about how to add these libraries. i guess i have to learn more about c++...

    so: gdi / sdl ?
    I can't help you with GDI programming, as I'm not a Windows programmer.

    If you want to see how to use the SDL, check out this absolutely fabulously excellent tutorial: http://lazyfoo.net/SDL_tutorials/index.php

    The only thing I would add to it is that recent versions of Dev-C++ have a DevPak for the SDL, which you can get instead of downloading them manually. It's a lot easier.

    Again: don't worry about speed! Writing pixels is typically very fast. (Unless you're using the BIOS, but never mind that.)
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  4. #19
    Registered User Devils Child's Avatar
    Join Date
    Jan 2008
    Posts
    244
    ok. i will use that. if i have any more questions, i will ask again
    thank you very much!!!

  5. #20
    Registered User Devils Child's Avatar
    Join Date
    Jan 2008
    Posts
    244
    oh boy... this sure looks complicated and its a lot source code. the image example works, but the pixel example fails...
    is there an easier way? or even a way that is actually 'software'?

  6. #21
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Right. I was working on a sample to show a failure in a graphics library that a supplier provides. The sample to show this came to 240 lines - only about 15 of those are actually doing the drawing that actually fails. The rest of it is to do with "setting things up" and "tearing things down".

    You will find that graphics involves quite a bit of work to get to a point where you can do things yourself.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #22
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    I'm not sure what pixel code you used -- care to post it? -- but you could try code from a second source: http://libsdl.org/intro.en/usingvideo.html
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  8. #23
    Registered User Devils Child's Avatar
    Join Date
    Jan 2008
    Posts
    244
    ok. thats something i can use. works fine now
    thank you!!!

  9. #24
    Registered User Devils Child's Avatar
    Join Date
    Jan 2008
    Posts
    244
    dude, this is awfuly slow!
    Code:
    #include "SDL/SDL.h"
    
    const int SCREEN_WIDTH = 1024;
    const int SCREEN_HEIGHT = 768;
    SDL_Surface *screen = NULL;
    
    int main( int argc, char* args[] )
    {
    	SDL_Init(SDL_INIT_EVERYTHING);
    	screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, 32, SDL_SWSURFACE);
    	SDL_WM_SetCaption("VirtualGL", NULL);
    
    	int rgb;
    	for (int i = 0; i < 100; i++) {
    		rgb = ((rand() * 255) << 16) | ((rand() * 255) << 8) | (rand() * 255);
    		SDL_LockSurface(screen);
    		for (int x = 0; x < SCREEN_WIDTH; x++) {
    			for (int y = 0; y < SCREEN_HEIGHT; y++) {
    				Uint32 *bufp;
    				bufp = (Uint32*) screen->pixels + y * screen->pitch / 4 + x;
    				*bufp = rgb;
    			}
    		}
    		SDL_UnlockSurface(screen);
    		SDL_Flip(screen);
    	}
    
    	SDL_Quit();
    	return(0);
    }
    this fills the form with approx. 20 FPS and thats 1024x768!!!
    am i doing anything wrong or is it slow?
    even in basic i get 120 fps for that (6x faster!)...

    i need this for a software renderer, which just has to be fast...

  10. #25
    Registered User
    Join Date
    Apr 2007
    Posts
    10
    Quote Originally Posted by Devils Child View Post
    dude, this is awfuly slow!
    Thats because SDL wasn't designed to be used that way. Any per pixel manipulations like that are going to be extremely slow.

    Code:
    #include <SDL/SDL.h>
    
    int main ( int argc, char** argv ){
        if ( SDL_Init( SDL_INIT_VIDEO ) < 0 )
            return 1;
    
        SDL_Surface* screen = SDL_SetVideoMode(640, 480, 32, SDL_SWSURFACE|SDL_DOUBLEBUF);
        if ( !screen )
            return 1;
    
        bool done = false;
        while (!done) {
            SDL_Event event;
            while (SDL_PollEvent(&event)) {
                switch (event.type) {
                case SDL_QUIT:
                    done = true;
                    break;
                case SDL_KEYDOWN:
                    if (event.key.keysym.sym == SDLK_ESCAPE)
                        done = true;
                    break;
                }
            }
            SDL_FillRect(screen, 0, SDL_MapRGB(screen->format, rand()%256, rand()%256, rand()%256));
            SDL_Flip(screen);
        }
    
        SDL_Quit();
        return 0;
    }
    You will need to set up SDL_gfx for anything other than rectangles.

  11. #26
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    It is indeed correct that it's not designed to be used that way, but if you change the calculation of the buffer position to be done only once per line [because pixels themselves are next to each other], using this way:
    Code:
    		for (y = 0; y < SCREEN_HEIGHT; y++) {
    			bufp = (Uint32*) screen->pixels + y * screen->pitch / 4;
    			for (x = 0; x < SCREEN_WIDTH; x++) {
    				*bufp = rgb;
    				bufp++;
    			}
    		}
    then it runs nearly ten times faster:
    clocks = 7156
    clocks = 828

    Note that I've swapped the loops for x and y, and moved the calculation to the outer loop.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  12. #27
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    You will need to set up SDL_gfx for anything other than rectangles.
    Real Programmers never use more libraries than they have to!
    http://www.brackeen.com/vga/shapes.html
    http://dwks.theprogrammingsite.com/m...src/graphics.c (old code of mine, sorry for bad practices)

    But yeah, the SDL_gfx is much more efficient as well as being properly tested and stuff . . . .

    It might actually be more efficient if you generated a surface beforehand, and then used SDL_BlitSurface() to blit it quickly over to the video surface . . . just a thought. If it's too inefficient, you can probably do something to get it to run faster.

    Really, I'm not sure how much better other libraries would be in this case . . . handling one pixel at a time is asking for slowness.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  13. #28
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    The time I get on that test, after the above modification show 123 frames per second. This is with an ANCIENT graphics card (nVidia GeForce2 GTS), and an Ahtlon64 3200+.

    The FillRect isn't any faster, as it appears that copying the pixels to the screen (bitblt) is the slow path.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  14. #29
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    On my computer, the original code with the above modification runs in 2.7 seconds at 800MHz. That's only 37 FPS, I think. But that's 800MHz -- come on.

    SDL_FillRect() is about 34 FPS.

    But that's what you get with per-pixel access.
    Last edited by dwks; 01-23-2008 at 05:11 PM.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  15. #30
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    You know, people have done quite pretty 2d graphics when 800MHz was science fiction.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. standrad library
    By sarahr202 in forum C++ Programming
    Replies: 11
    Last Post: 05-18-2009, 08:50 PM
  2. Makefile for a library
    By sirmoreno in forum Linux Programming
    Replies: 5
    Last Post: 06-04-2006, 04:52 AM
  3. Good Game library
    By Girvo in forum Game Programming
    Replies: 2
    Last Post: 06-10-2004, 10:17 AM
  4. Graphics Programming :: Approach and Books
    By kuphryn in forum Windows Programming
    Replies: 4
    Last Post: 05-11-2004, 08:33 PM
  5. good vector library
    By rotis23 in forum C Programming
    Replies: 4
    Last Post: 10-08-2002, 11:49 AM

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