A good graphics library?

**dwks** · 01-23-2008

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

**Devils Child** · 01-23-2008

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 ?

**dwks** · 01-23-2008

Originally Posted by Devils Child

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.)

**Devils Child** · 01-23-2008

ok. i will use that. if i have any more questions, i will ask again

thank you very much!!!

**Devils Child** · 01-23-2008

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'?

**matsp** · 01-23-2008

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

**dwks** · 01-23-2008

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

**Devils Child** · 01-23-2008

ok. thats something i can use. works fine now

thank you!!!

**Devils Child** · 01-23-2008

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...

**691175002** · 01-23-2008

Originally Posted by Devils Child

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.

**matsp** · 01-23-2008

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

**dwks** · 01-23-2008

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.

**matsp** · 01-23-2008

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

**dwks** · 01-23-2008

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.