Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Chuck3d

What is the best graphics lib for software rendering ?

This topic is 5480 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello! I''m working on a software rendering engine with directX7 but im not satisfy. I want to know what is the fastest free graphics librairy for 2D rendering on windows ? SDL ? Thank You very much for you answer. Good Day. Chuck

Share this post


Link to post
Share on other sites
Advertisement
I obtain doubtful performances:

On an Athlon 1800+ and geforce2, i obtain 175 fps in 640*480*32 when I just write all the pixel in blue. I lock the surface and all the thing that rulezz but this is strange I think.

In 1280*1024 It goes down 35 fps !!! without calculations !

Thanx for reply.

Chuck

Share this post


Link to post
Share on other sites
The best 2-D library (to my knowledge) is actually Allegro. If you want 3-D, go DirectX or OpenGL, but 2-D, Allegro is king.*

(* oppinon)

Free, Open-Source, complete crossplatform support for QNX, BEOS, Mac OS X, Linux, Unix, DOS, Windows, and I might be forgetting some. lol. Oh, (SGI's) Solaris.

Hehe.

Though, if your only getting 35fps, it might be a hardware/bus limitation. Try doing more then drawing blue, and then see if it declines. Also, how are you drawing blue? If you do it by

for(x=0;x
for(y=0;y
putpixel(x, y, color_blue);

Then that could be it in itself. I would recommend using Allegro's included Testing program to benchmark your actual speeds. But that's assuming you have it.


[edited by - the etwinox on September 21, 2003 7:19:11 PM]

Share this post


Link to post
Share on other sites
quote:
The best 2-D library (to my knowledge) is actually Allegro. If you want 3-D, go DirectX or OpenGL, but 2-D, Allegro is king.*


I don''t believe it is possible for Allegro to be faster than DirectDraw, since on Windows that is what it must be using.

Share this post


Link to post
Share on other sites
Yep, sounds like a bus limitation. When you''re doing stuff in software you will be bus limited, don''t expect to get 1000 fps (even with pure blue) when you''re sending megabytes of data to the card every frame.

Share this post


Link to post
Share on other sites
allegro is fast and *very*very* robust, however yes on windows it usually uses directx/directdraw (amazingly however, there is even a gdi driver too ) so it will probably not be faster. however it wont be much slower, and you should still consider using it since it already has 3d math routines and polygon (full perspective correct texture mapped gourad shaded alpha blended polygons ) drawing routines.

SDL is also good, runs off of direct draw, and is lower level then allegro. however all SDL can do is setup the canvas and give it to you, it has only a few other graphics features.

im sure you could write faster code with direct draw, but even with super optimizations, i dont think you''d be losing much.

btw, are you doing a pixel by pixel fill? use the hardware accelerated blit fill, its quite a few times faster.

Share this post


Link to post
Share on other sites
quote:
Original post by Chuck3d
I obtain doubtful performances:

On an Athlon 1800+ and geforce2, i obtain 175 fps in 640*480*32 when I just write all the pixel in blue. I lock the surface and all the thing that rulezz but this is strange I think.

In 1280*1024 It goes down 35 fps !!! without calculations !


It doesn''t seem memory bandwidth limited. That''s ''only'' 200 MB/s and your system can do gigabytes per second! AGP 4x should also be sufficient to get better results. So, what instructions do you use for writing your colors? Non-temporary SSE writes should keep the cache clean and write 16 bytes at once. Prefetching can also greatly improve performance if your processor doesn''t do it automatically. An example of fast filling routines can be found here: Fast P3 Memory Access.

Share this post


Link to post
Share on other sites
Thanx a lot for you answers.

I do a pixel per pixel render at the end (for my engine) then I use it at the begining . I know I can fill the screen faster with BltFast, but I need pixel per pixel methods.

I lock the back surface (I use a primary and a back one).
I store the back surface memory adress in a DWORD and I do a loop for each pixels (with just addition). I finally unlock the back surface and do a Flip() with DDFLIP_NOVSYNC. I lock with DDLOCK_WAIT. I clear the screen with

DDBLTFX ClsBltFx;
ZeroMemory(&ClsBltFx,sizeof(ClsBltFx));
ClsBltFx.dwSize = sizeof(ClsBltFx);
IDirectDrawSurface_Blt(surface,0,0,0,DDBLT_COLORFILL|DDBLT_WAIT,&ClsBltFx);

My resolution is 640*480* 32bits it is important, because I didn''t arrive to do better with 16bits !I concluded that is the number of writting that do the performances.

C0D1F1ED:
Non-temporary SSE writes should keep the cache clean and write 16 bytes at once.

What is Non-temporary SSE? It seems interresting . I don''t know the things you talk about, can you explain in details please ? Thanx for the article link.


Thank you all.

!o)

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!