Printable View
Hi there!
I'm looking for a good graphics library (Not OpenGL!) for c++.
I'm common to some languages but new to c++. I know the basics and OOP.
My question: What's a recommended graphics library to add pixels to the screen very fast?
Thank you :)
bye!
Probably not the fastest, but SDL does this.
--
Mats
If it's not the fastest, is there a faster one?
Propably it will be enough for now.
I found it and try to impement it. Let's see wheter it works this time.
I tried some others but they didn't work...
Do I have to use Win32 projects or is a console app enoguh?
I don't think SDL works in Console mode, you have to use a "Window" app.
Of course, the Windows API itself has GDI(+) that does draw pixels to the screen (or off-screen for that matter) quite well.
--
Mats
Really? So i don't have to use a library at all? Show me how the GDI does that :)
Is the GDI included to c++ in VisualStudio 2005 PROF_EDITION ?
allegro is also another one, comparable to SDL, I can't tell you whether or not its any faster as i don't have much experience in graphics programming.
to use sdl or allegro, you'll need to know the correct linker commands to use the functions from their libraries, otherwise the compiler is going to say it doesn't know what you're talking about.
as far as whether or not you need to use the win32 api for either of those...
i'm pretty sure you create an *emtpy* project, and add all the stuff you need. if you want your app to be *windowed* then you'll need to include "windows.h", although you shouldn't need to use much of the win32 api to accomplish this (i.e. you won't need all those millions of lines of code that typically go into a win32 app.)
hope this helps somewhat.
Hm, but isnt that as matsp said possible with GDI?
I mean: I'm kinda confues with adding libraries to VC... I tried a couple of times and it never worked...
GDI is part of Windows base functionality - it is how your windows appear on the screen, and how this text in this post eventually will be visible on someones machine [assuming that machine is running Windows - at least before Vista, Vista has some new concepts when it comes to drawing to the screen].
--
Mats
So, how do I add some pixels to the screen/window now?
Well, first of all you need to implement enough code to put up a window, once you have done that, here's a reference of "Drawing" functions:
http://msdn2.microsoft.com/en-us/lib...06(VS.85).aspx
Bitmap functions:
http://msdn2.microsoft.com/en-us/lib...43(VS.85).aspx
All windows functions by category:
http://msdn2.microsoft.com/en-us/lib...86(VS.85).aspx
--
Mats
You should really look into Programming Windows 5th Edition by Charles Petzold.
Todd
Note also if you want to really draw individual pixels, it's probably best to create a bitmapsurface, draw pixels there, and then BitBlt the bitmap to the screen [if you want to see updated pixels as it draws, have a count of how many pixels you've been drawing and BitBlt every <choose a number, 256, 1000, 50 or whatever makes most sense>].
--
Mats
hm... any examples?
I'm pretty sure Google can come up with loads - but I don't have any here...
--
Mats
google is where i searched. but for me, as i dont know much about GDI, it is hard to find the good examples. i thought you might are?
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:
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.Quote:
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.
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:
Quote:
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
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.Quote:
Originally Posted by Devils Child
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.)
ok. i will use that. if i have any more questions, i will ask again:)
thank you very much!!! :)
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'?
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
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
ok. thats something i can use. works fine now :)
thank you!!!
dude, this is awfuly slow!
this fills the form with approx. 20 FPS and thats 1024x768!!!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);
}
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...
Thats because SDL wasn't designed to be used that way. Any per pixel manipulations like that are going to be extremely slow.Quote:
Originally Posted by Devils Child
You will need to set up SDL_gfx for anything other than rectangles.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;
}
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:
then it runs nearly ten times faster: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++;
}
}
clocks = 7156
clocks = 828
Note that I've swapped the loops for x and y, and moved the calculation to the outer loop.
--
Mats
Real Programmers never use more libraries than they have to! :pQuote:
You will need to set up SDL_gfx for anything other than rectangles.
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. :)
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
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.
You know, people have done quite pretty 2d graphics when 800MHz was science fiction.
10 times faster :D
have to try this at home...
this is my project i made in (blitz)basic
http://www.dev-ch.de/upload/files/De.../VirtualGL.zip
it shows a software renderer and i wonter how much faster i can get it here :)
i'll tell you when something doesnt work!
thank you very much for your support! this community is really somethin ;)
bye!
I didn't mean to sound like I was insulting 800MHz and slower computers -- one of my favourite computers ever, this one I'm using right now, clocks in at 400MHz. I was trying to defend the SDL, because I really like it. :)Quote:
You know, people have done quite pretty 2d graphics when 800MHz was science fiction.
Incidentally, this computer took 20.981 seconds to run the original version (I didn't feel like running it more than once!), and this version only took slightly over 6.7 seconds:
That's a substantial speed increase. :)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[] )
{
int i, x, y, rgb;
SDL_Init(SDL_INIT_EVERYTHING);
screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, 32, SDL_SWSURFACE);
SDL_WM_SetCaption("VirtualGL", NULL);
for (i = 0; i < 100; i++) {
rgb = ((rand() * 255) << 16) | ((rand() * 255) << 8) | (rand() * 255);
SDL_LockSurface(screen);
for (y = 0; y < SCREEN_HEIGHT; y++) {
Uint32 *bufp = (Uint32*) screen->pixels + y * screen->pitch / 4;
for (x = 0; x < SCREEN_WIDTH; x++) {
*bufp = rgb;
bufp++;
}
}
SDL_UnlockSurface(screen);
SDL_Flip(screen);
}
SDL_Quit();
return(0);
}
For software rendering in SDL I make a screen buffer in RAM then do all the read/write operations to it, as its much faster then reading/writing to/from graphics surfaces. At the end of the loop I blit the whole thing to the screen, the same way matsp suggested.
Also I noticed that flattening a 2D screen array in C provides can provide a significant speed boost although bizarrely it dosent seem to make a difference in Blitz.
Oh and btw even unoptimized C++ code is blindingly fast compared to Blitz, so theres really nothing to moan about ;)
You mean, double buffering? Do you use the SDL's built-in double buffering (SDL_Flip() and all that)?Quote:
Originally Posted by mike_g
Well, I think Blitz is interpreted, so the interpreter probably wasn't coded to interpret loops specially. But in C or C++, a single loop can be very efficient if the loop body and conditions are very small and simple. Don't ask me why -- ask matsp. :)Quote:
Also I noticed that flattening a 2D screen array in C provides can provide a significant speed boost although bizarrely it dosent seem to make a difference in Blitz.
Aye, you just have to know what you're doing, that's all. Yes, a plane is faster than a car, but only if you try to take off from the ground. Otherwise, the wings just get in the way. ;)Quote:
Oh and btw even unoptimized C++ code is blindingly fast compared to Blitz, so theres really nothing to moan about ;)
hi!
in my early basic software renderer, i used bitblt but with the windows api.
how do you do that with c++ and sdl? any example?
ps: is that software rendered. can i call my project a "software renderer" at all? or does it use the GPU for all this? (no matter if it does...)
Possibly NOT on a 1024 x 768 x 32bpp screen.Quote:
Originally Posted by CornedBee
--
Mats
No - accessing ram is faster than surfaces thats all.Quote:
You mean, double buffering? Do you use the SDL's built-in double buffering (SDL_Flip() and all that)?
Blitz is compiled, but its very slow for working with pixels, and theres no pointers.Quote:
Well, I think Blitz is interpreted
Yeah its still unlikely that you would be able to get update a an entire screen each loop at that rez in software and get a decent frame rate. And you definitely wouldent with a raytracer.Quote:
Originally Posted by CornedBee
You know, people have done quite pretty 2d graphics when 800MHz was science fiction.
Possibly NOT on a 1024 x 768 x 32bpp screen.
One way to get four times the speed would be to use the MMX or 3Dnow registers. It would require a little asm tho and I havent done it myself as of yet.
i'm using double buffering using flip(). but i think what i need is a color buffer that will be copied _AT THE END_ to the backbuffer. that is possible with bitBlt. still, i dont know how it works here.
can you please post an example? :)
thx!
Yes, the buffer you are writing to is copied to the screen (using a bitblt or similar) during the "Flip" call.
--
Mats
i implemented the color buffer which will be blitted to the backbuffer. but do i need this at all when i DON'T want to read from the backbuffer?
I know you said you don't want to use OpenGL, but what's wrong with it?
it's just a "software renderer", which usualy doesnt use openGL.
but sure, when i have time, i will do an openGL engine as i done it once before!
Well if youre are making a ray caster there is another problem: Moving around the screen. In my raycaster implementation I casted the walls first, then did the floor casting. So, i could no longer just run through each pixel conseutively.Quote:
i implemented the color buffer which will be blitted to the backbuffer. but do i need this at all when i DON'T want to read from the backbuffer?
The screen data is on a GPU. GPUs like to get large lumps of data and perform the same instruction on them. IE:
for(y=0; y<h; y++)for(x=0; x<w; x++, p++) *p=col;
GPUs generally don't like get interrupted with calls to jump to a different location all the time. Usually with software rendering I found communicating with the GPU to be one of the biggest bottlenecks, however it does take time to copy data to a screen array, then to the screen itself.
A screen array would also be useful if you wanted to apply some post-drawing filtering of some kind.
All I can say is try it and see. If you draw each pixel consecutively, dont read any pixels and dont write more than one layer, then yeah you wont need a screen array.
i see what you mean. i will write more colors to one pixel at different times soon. so i will implement a color buffer as soon as i need it. well i tried it and it worked, so i know how to :)
Right, if the memory you are accessing is really the graphics memory, then doing individual pixel updates is really bad - I worked on a graphics chip simulator, and I implemented a method to cache the Video memory reads in system memory with the simulator. This helped performance by about 10-20% - that is ONLY the video memory reads, not all the other simulator functions.
It is quite likely that reading/writing pixels from/to graphics memory is 10-20x slower than the same operation in system memory. Not a good idea.
Writing your data to a memory buffer and updating the final result onto the screen is the right idea, unless you can make the GPU do some of the work for you (but unlikely in this particular instance).
--
Mats