Thread: A good graphics library?

  1. #31
    Registered User
    Join Date
    Jan 2008
    Posts
    244
    10 times faster
    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!

  2. #32
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    You know, people have done quite pretty 2d graphics when 800MHz was science fiction.
    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.

    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:
    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);
    }
    That's a substantial speed increase.
    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.

  3. #33
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    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
    Last edited by mike_g; 01-24-2008 at 06:55 PM.

  4. #34
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    Quote Originally Posted by mike_g View Post
    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.
    You mean, double buffering? Do you use the SDL's built-in double buffering (SDL_Flip() and all that)?

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

    Oh and btw even unoptimized C++ code is blindingly fast compared to Blitz, so theres really nothing to moan about
    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.
    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.

  5. #35
    Registered User
    Join Date
    Jan 2008
    Posts
    244
    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...)

  6. #36
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by CornedBee View Post
    You know, people have done quite pretty 2d graphics when 800MHz was science fiction.
    Possibly NOT on a 1024 x 768 x 32bpp screen.

    --
    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. #37
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    You mean, double buffering? Do you use the SDL's built-in double buffering (SDL_Flip() and all that)?
    No - accessing ram is faster than surfaces thats all.

    Well, I think Blitz is interpreted
    Blitz is compiled, but its very slow for working with pixels, and theres no pointers.

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

    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.

  8. #38
    Registered User
    Join Date
    Jan 2008
    Posts
    244
    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!

  9. #39
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Yes, the buffer you are writing to is copied to the screen (using a bitblt or similar) during the "Flip" call.

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

  10. #40
    Registered User
    Join Date
    Jan 2008
    Posts
    244
    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?

  11. #41
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    I know you said you don't want to use OpenGL, but what's wrong with it?

  12. #42
    Registered User
    Join Date
    Jan 2008
    Posts
    244
    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!

  13. #43
    Dr Dipshi++ mike_g's Avatar
    Join Date
    Oct 2006
    Location
    On me hyperplane
    Posts
    1,218
    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?
    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.

    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.
    Last edited by mike_g; 01-26-2008 at 07:30 AM.

  14. #44
    Registered User
    Join Date
    Jan 2008
    Posts
    244
    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

  15. #45
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    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.

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