fast bitmap drawing
Author
Ok, im working on somthing similar to a raytracer. After a frame is finished rendering i basically have a large bitmap that i need to dump to the screen. I've been using the windows GDI but that is too slow for what I'm eventually going to be doing. I need a way to dump large bitmaps to the screen (like maybe even up to 1600x1200) at a rate of at least 60 fps and it needs to be cross platform compatable, maybe even do it in windowed mode =)...any ideas?
Thanks in advance
Edited by - warpexplorer on January 29, 2001 12:19:34 AM
OpenGL is cross platform.
I would suggest seeing how many frames per second you can get without drawing it on the screen first. I have a hard time seeing 60fps with raytracing especially at 1600 by 1200. That would be 115 million pixels per second. If that was 24 bits per pixel you would be moving over 345MB/s. Then when you copy it to the screen you are doubling that rate so you are hitting 690MB/s being moved. With a memory bus at 100MHZ and 64 bits wide the max possible if memory could keep up is 800MB/s and I don''t believe it can. I would say you would be lucky to actually move 200MB/s and 100MB/s would be more likely. I haven''t gotten heavily into performance testing yet for this type of application so I wouldn''t suggest taking my word for it, but I would strongly suggest testing whether the concept is practical.
I would suggest seeing how many frames per second you can get without drawing it on the screen first. I have a hard time seeing 60fps with raytracing especially at 1600 by 1200. That would be 115 million pixels per second. If that was 24 bits per pixel you would be moving over 345MB/s. Then when you copy it to the screen you are doubling that rate so you are hitting 690MB/s being moved. With a memory bus at 100MHZ and 64 bits wide the max possible if memory could keep up is 800MB/s and I don''t believe it can. I would say you would be lucky to actually move 200MB/s and 100MB/s would be more likely. I haven''t gotten heavily into performance testing yet for this type of application so I wouldn''t suggest taking my word for it, but I would strongly suggest testing whether the concept is practical.
The windows GDI isn''t what I would call slow.
I think that if you timed your code you would find that the thing that is taking the majority of your time is your raytracer.
If you used directX you could lock the surface and use memcpy to just copy it from your buffer to your surface.
At 1600x1200x2 (16-bit) = 3,840,000 bytes per frame.
Obviously trying to achieve such a high frame rate transferring that much memory around is going to take a helluva lot of tweaking.
I barely get 105fps running @ 800x600 on a Celeron 400 + TNT 2 doing software blits.
If you used directdraw then you could use hardware blitting, which would probably reduce the amount of time to do this.
Regards,
Nekosion
I think that if you timed your code you would find that the thing that is taking the majority of your time is your raytracer.
If you used directX you could lock the surface and use memcpy to just copy it from your buffer to your surface.
At 1600x1200x2 (16-bit) = 3,840,000 bytes per frame.
Obviously trying to achieve such a high frame rate transferring that much memory around is going to take a helluva lot of tweaking.
I barely get 105fps running @ 800x600 on a Celeron 400 + TNT 2 doing software blits.
If you used directdraw then you could use hardware blitting, which would probably reduce the amount of time to do this.
Regards,
Nekosion
Author
I said it was somthing _similar_ to a raytracer...dont worry about that part, thats not what i asked.
Yeah, I admit that 345MB/s is alot but i'm looking ahead...
In the next year or two they will be coming out with systems with a 400mhz FSB with DDR ram and a 2.5 ghz Sludgehammer(i think thats the name)...I want my game to be able to utilize that kind of power. Now i know that 1600x1200x24bit@60fps is totaly unfeasable at this point, but 1024x768x24bit@60fps
(135MB/s) should be achievable, or at least come close.
so i guess i'll refrase what im saying...
I need a way to copy 800x600 size bitmaps to the screen at a rate of 60 fps and it needs to be cross platform capable. With the ability to go to 1600x1200 if i wanted it to.
Dont worry about the speed of the 'raytracer' its not what you think it is and besides with a dual 3 ghz processors who would care anyway
How would you do what i want in OpenGL? You could use GL_POINTS but that just seems like it would have alot of overhead thats not necessary, but I'm new to GL so i dont know.
Edited by - warpexplorer on January 30, 2001 8:34:20 PM
Yeah, I admit that 345MB/s is alot but i'm looking ahead...
In the next year or two they will be coming out with systems with a 400mhz FSB with DDR ram and a 2.5 ghz Sludgehammer(i think thats the name)...I want my game to be able to utilize that kind of power. Now i know that 1600x1200x24bit@60fps is totaly unfeasable at this point, but 1024x768x24bit@60fps
(135MB/s) should be achievable, or at least come close.
quote:I barely get 105fps running @ 800x600 on a Celeron 400 + TNT 2 doing software blits.yeah but Celerons dont even compare to even a cheap Athlon and are almost half the speed of an even cheaper duron (thats what intel doesnt tell you)
so i guess i'll refrase what im saying...
I need a way to copy 800x600 size bitmaps to the screen at a rate of 60 fps and it needs to be cross platform capable. With the ability to go to 1600x1200 if i wanted it to.
Dont worry about the speed of the 'raytracer' its not what you think it is and besides with a dual 3 ghz processors who would care anyway
How would you do what i want in OpenGL? You could use GL_POINTS but that just seems like it would have alot of overhead thats not necessary, but I'm new to GL so i dont know.
Edited by - warpexplorer on January 30, 2001 8:34:20 PM
you would upload the buffer to a texture and then draw a textured quad the size of the screen.
.
I don''t know OpenGL, but I assume it has basically the same functionality as DirectX. Within DirectX you would setup a primary and back buffer. You would then lock the back buffer which gives you direct access to the video memory assuming the card supports it. Then rather than writing to a bitmap you are going to blit you write directly to the page buffer. When you are done you unlock the back buffer and flip. Rather than moving the buffer the hardware on the card that reads the buffer and generates an analog signal basically just switchs base addresses.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement