Well if you would like to write an fast software renderer use direct memory access

try using the SDL (www.libSDL.org)

EASY to use, and it just gives a nice little pointer to screen.. letz draw in there

when you need some source, call me, i''ll give you..



we wanna play, not watch the pictures

try using the SDL (www.libSDL.org)

EASY to use, and it just gives a nice little pointer to screen.. letz draw in there

when you need some source, call me, i''ll give you..



we wanna play, not watch the pictures

they DIDNOT combine directdraw and d3d into one directgraphics api aka d3d8.
the reason ms droped support for direct access to the frame buffer (directdraw) is cause its slows down the cards rendering speed to much

http://members.xoom.com/myBollux

this wasnt written by me by from a nvidia guy

quote:

The short answer is, "no".
The long answer...

The fact that DX8 has _eliminated_ this feature really casts doubt on it. It has caused an absolutely huge number of problems in D3D!

I see two major areas where people might be asking for this access:

- framebuffer access
- texture access

For framebuffer access, use DrawPixels and ReadPixels. Both are fast on GeForce. If it''s not fast, we can optimize it; there is no theoretical reason it would need to be slow, certainly.

For texture access, we are working on ways that texture downloads can be cheaper. There is no inherent limitation that causes TexSubImage to offer poorer performance than directly writing to video memory. There _are_ Windows platform restrictions that make doing this correctly very difficult.

Once we offer video memory pointers to apps, Bad Things can happen quickly. We have to sync the hardware before any such pointer is usable, which kills performance. We have to take some kind of system-wide mutex so that apps don''t stomp on top of each other if we decide to reorganize video memory.

We _cannot_ give you a pointer to the start of your framebuffer without taking a system-wide OS mutex. What happens if you move the window? The part of the framebuffer used by your app moves with it. That means we have to take a mutex that prevents any window events from occurring. In turn, this means that if you take the lock and never release it, the system will hang. Even if you take it for, say, a second, the system will suddenly become very unresponsive to input. NT does a better job than 9x here, but not good enough for us to trust apps. In fact, in certain ways, it is worse on NT, to the point where it may not be safe to do this at all.

Finally, direct writes to video memory are actually _not fast_ on most PC platforms today. In fact, this is the "Fast Writes" feature that some of you have heard about. Without that feature, writing to video memory directly is _much slower_ than writing to AGP and then pulling from AGP. (which only the driver is in a position to do). Even where they are implemented, in many cases, there are motherboard and chipset bugs that break things pretty quickly. Also, they only work for sequential writes (just like AGP write combining), and apps that read from video memory directly (don''t laugh, lots of old [and new] DirectX apps do this) get absolutely horrendous performance, since CPU readbacks over the AGP bus are absolutely disgustingly slow, and video memory is uncached.

The reason this works for vertex array range is that video memory vertices are best reserved for static vertex data. In fact, we specifically recommend AGP instead for dynamic data. Also, the synchonization hazards for vertex data are much simpler than those for framebuffer data -- vertex data is read only, and we have spun off the synchronization problem to the app (NV_fence), and there is no way that vertex data can get asynchronously relocated like framebuffer memory can.

There are genuine problems with the current situation, and we are working to solve them, but unfortunately there are platform limitations and there''s only so much time in a day. Furthermore, none of these limitations are inherent OpenGL limitations.

Offering these pointers (either FB or texture) to apps opens up the biggest Pandora''s Box in all of graphics programming. Microsoft did it, and they regretted that decision for years. I refuse to make that mistake again with OpenGL.

http://members.xoom.com/myBollux

Hi all

I checked an old Direct Draw app and as I thought it did work with DX8. The Info on Direct Draw was very interesting. The nvidia guy said use DrawPixels and ReadPixels I think this is glDrawPixels and glReadPixels, I have used them from time to time but I have a voodoo 5 and they are soooooo slow, a shame really.

I think I will do some performance checks on the options stated and I will use the fastest one. HBITMAP looks promising I hope it is adequate speed wise.

3DG

I suggest you that you check out my website. I have a ddraw framework online that is ripped out of my SW renderer. The framework is well written and 100% exchangeable, a OpenGL implementation is supplied. My engine checks for DDraw, and uses GL if it fails to init DDraw. You could even write a DGraphics or a WinG or DIB port.

You should also take a look at Nicolas Capens'' framework it''s also on my site. It doesn''t support windowed rendering and it doesn''t have this multi-rederer approach but it might be better to learn.

Those are two highly usable DDraw/OpenGL wrapper systems, together with TinyPTC there is really no need for you to bother with this final raster output step if you don''t want.

You might want to read the gdnet DDraw7 tutorials if you are interesting in learning it...

Tim

--------------------------
glvelocity.gamedev.net
www.gamedev.net/hosted/glvelocity

Hi

Thanks for the Info I will take a look.


3DG

Take a look at: www.gamedev.net/hosted/3dgraphics/index.html

Hi all


Hay Ozz thanks for the link, I am sure it will be useful if I get stuck thanks. I have decided that I can not decide what method to use to draw pixels to screen. So I am going to make the application very modular so I can easily employ any method I like from Direct Draw to OpenGL to OpenPTC to DIB''s etc.

Thanks for all your input on this subject, And Happy Coding.


3DG