Archived

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

3DG

A Software Engine Question

Recommended Posts

A Software Engine Question Ok I have been coding in OpenGL for quite a while now, and I have a BSP engine running nicely, and also my Octree Engine is starting to come together as well. Anyway, I would like to start developing a Software Engine I am not aiming for anything amazing, dots then lines then polygons then texture mapping, and so on. Ok first things first in windows how do I just display or draw a simple dot, 1 pixel on a form in windows. I cant seem to find any windows functions to do this, in dos this would be very easy but how does windows do such a thing. If I can just find a way to draw the simplest of things a pixel of any color then the rest will fall into place without any help ie drawing lines, polygons etc So simple put, How do I draw a pixel of any color on a form in Windows? Any Info on this would be very helpful or pointers to a Tutorial if this is a difficult thing. Thanks 3DG

Share this post


Link to post
Share on other sites
You must use DirectDraw. Read some DirectX tutorials on how to use it. To plot pixels on a DirectDraw surface, you first Lock() it, draw stuff, then Unlock() it.

I just finished an affine texture mapped, gouraud shaded, z-buffered software renderer in MMX today. It took a little while, but it was worth it -- it's much faster than Direct3D's (although mine doesn't have perspective-corrected textures yet).

~CGameProgrammer( );



Edited by - CGameProgrammer on January 29, 2001 7:44:55 PM

Share this post


Link to post
Share on other sites
Just for the record: you can choose to do it all with Win32 using a DIB (device independent bitmap).
But much people have trouble setting this thing up, and it is slower then DX.

So like CGameProgrammer said - DirectDraw

Share this post


Link to post
Share on other sites
Ok Thanks,

I will defiantly look into using direct draw, but is there anyway to do it with out Direct Draw??


Thanks Again 3DG

Ps This was written before the message from baskuenen (thanks for the info) appeared for me thanks I will look into using a DIB (device independent bitmap), are there any other ways ? Anyone ?


Edited by - 3DG on January 29, 2001 8:16:11 PM

Share this post


Link to post
Share on other sites
Why don''t you want to use DirectDraw? It''s the best way. And learning to use it is much, much easier than writing an actual decent software renderer, so you might as well learn it.

~CGameProgrammer( );

Share this post


Link to post
Share on other sites
>>Why don''t you want to use DirectDraw?<<

a good reason is its gone the way of the dodo

http://members.xoom.com/myBollux

Share this post


Link to post
Share on other sites
>>Why don''t you want to use DirectDraw?<<

a good reason is ''cause its gone the way of the dodo''

http://members.xoom.com/myBollux

Share this post


Link to post
Share on other sites
Graphics using windows functions doesn''t have to use DIBs. You can simply use an HBITMAP. Then use SetPixel and GetPixel to plot individual pixels. BitBlt is a sprite blitter, PatBlt is a fast way of clearing the bitmap. Used properly, you can do Windows graphics pretty fast.

You don''t have to use DirectDraw at all. I''d be more inclined to recommend you use OpenGL, since it blends rather well with Windows.



"NPCs will be inherited from the basic Entity class. They will be fully independent, and carry out their own lives oblivious to the world around them ... that is, until you set them on fire ..."

Share this post


Link to post
Share on other sites
Ok I will try to answer all the topics raised, and also first off thanks for all the input so far, OK then,

>CgameProgrammer

>Why don''t you want to use DirectDraw? It''s the best way. And learning to use it is >much, much easier than writing an actual decent software renderer, so you might as >well learn it.

>~CGameProgrammer( );

For the Software Engine I wish to write, well I had hoped to create something from scratch, the whole thing is intended to be more of a learning project than anything else, and also I had hoped that it could be entirely my own code nothing else needed. I do not at present care about the performance I just wish to experiment with the algorithms that go into a software engine.

---------------------------------------------------------------------

>>zedzeek

>>>>Why don''t you want to use DirectDraw?<<
>>a good reason is its gone the way of the dodo

Without looking I think DX8 combined Direct Draw and Direct3D. I would have to look to see if Direct Draw programs still work under DX8 but it does not look good.

---------------------------------------------------------------------

>>morfe

>>Graphics using windows functions doesn''t have to use DIBs. You can simply use >>an HBITMAP. Then use SetPixel and GetPixel to plot individual pixels. BitBlt is a >>sprite blitter, PatBlt is a fast way of clearing the bitmap. Used properly, you can do >>Windows graphics pretty fast.

Ok Thanks for this, I new it would be something simple, I will definitely be taking a look at this thanks.

>>You don''t have to use DirectDraw at all. I''d be more inclined to recommend you >>use OpenGL, since it blends rather well with Windows.

I could use OpenGL but I would like to take a stab at creating everything from the ground up, I hope and think it will stand as a great learning experience.

---------------------------------------------------------------------

Thanks for all your input I will take a look at both HBITMAP and DIB (device independent bitmap), thanks again for al your input. Happy Coding.


3DG

Share this post


Link to post
Share on other sites
Hi.

The "Direct Draw is extinct" argument is somewhat void.You can still (And will always be) able to use the Direct Draw 7 interfaces for straight DD stuff. You can use DD3 if you want to. Just because DX8 has merged DD and D3D does not mean that you cant or shouldn;t use the older interfaces.

Pete

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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


Share this post


Link to post
Share on other sites