17 replies to this topic

[The Grey Beast]

Hi, this is my first post in these forums (I posted another 'first post' in the GameDev.net forums, and I'd thought I'd ask my next question in these forums, to get quite familiar with them.

Anyway, I have some questions ('bout Low-level stuff) regarding DirectDraw and Windows GDI. First, does DirectDraw store bitmaps (surfaces) in video memory or in system memory?

I heard you can specify where you want your surface to be (in video or system memory), but this leads to the second question: What kind of surface can you store in Video Memory? Say, if a video card supports only 1-bit/pixel (wheww :lol: ) or if the video card stores it's images in a compact format, does that mean your surfaces in video memory can only be allocated as 1-bit/pixel, or you can allocate in any format you like, and then when you render to screen, you convert this data to the format supported (1-bit in my example), and perform some dithering (1-bit per pixel requires A LOT of dithering, lol )?

This second question is quite long, i know...

Only 2 more questions, pls: What happens when you 'lock' a surface in DirectDraw? I know you must do it before plotting pixels, but what does that actually mean? Furthermore, what happens when you 'plot' a pixel on a locked surface that is in Video Memory? (ps: i would like the hardware steps, i.e. first the CPU sends information, then it walks through the bandwidth, etc.) Does it go through the bandwidth? I though it was a slow operation to do that for every pixel... Will it be faster if I store my surface in system memory and then 'blit' it to the Video Card (to display it on the screen)?

Last question is small: Are there equivalents for the Windows GDI? I only want to know how to allocate my bitmaps in video memory, plot some pixels manually (without SetPixel, because it's damn slow), and blit it to the screen (and also lock the bitmap/surface, you know... question number 3).. I would like to get almost the same performance with the GDI.


Thank you so much for reading this (quite big) post. If I confused someone with all my questions, i'm sorry, because it's so hard to ask something when you are confused. :lol:

[Axel]

The Grey Beast said:

First, does DirectDraw store bitmaps (surfaces) in video memory or in system memory?

Both.

The Grey Beast said:

I heard you can specify where you want your surface to be (in video or system memory), but this leads to the second question: What kind of surface can you store in Video Memory?

Almost every modern graphics-adapter supports the RGBA8888 format, and that is what you most likely will use for everything nowadays.

The Grey Beast said:

What happens when you 'lock' a surface in DirectDraw? I know you must do it before plotting pixels, but what does that actually mean?

The VRAM-memory is mapped to userspace. Normally you could not write to it, because it's protected. Also the kernel stops everything from reading or writing to the VRAM. A lock is very expensive so don't overuse them.

The Grey Beast said:

Furthermore, what happens when you 'plot' a pixel on a locked surface that is in Video Memory? (ps: i would like the hardware steps, i.e. first the CPU sends information, then it walks through the bandwidth, etc.) Does it go through the bandwidth? I though it was a slow operation to do that for every pixel... Will it be faster if I store my surface in system memory and then 'blit' it to the Video Card (to display it on the screen)?

Do you mean "bus" when you say "bandwidth"? Else it doesn't make a lot of sence.

When you write to VRAM the data is indeed written through the Bus. The writes are cached with "write combining", so it's quiet fast. What's slow is reading from VRAM. YOU DON'T WANT TO DO THIS. When you need reading your image, then you should alloc a system-memory surface and blit that to the VRAM when you are finished.

The Grey Beast said:

Last question is small: Are there equivalents for the Windows GDI? I only want to know how to allocate my bitmaps in video memory, plot some pixels manually (without SetPixel, because it's damn slow), and blit it to the screen (and also lock the bitmap/surface, you know... question number 3).. I would like to get almost the same performance with the GDI.

GDI is more high-level. And you don't get double-buffering IIRC. For real-time graphics it's better to use DirectDraw.

[The Grey Beast]

Thanks for the reply, and sorry for the bandwidth confusion :confused: . One of my friends apparently replaced the term 'bus' with 'bandwidth'.. That's where I got this information.

What's faster? Creating the surface in system memory, and then (after plotting all it's pixels) blitting it to the screen (video card), or creating the surface in video memory, and plotting each pixel there (through the bus at each pixel...), and finally do a cheap blit operation to the screen.


Anyway, with the GDI... I want to implement a user-selectable feature in my demo (I think i'll turn it into a game later), which will allow the user to select which Graphics system (API) to use. For now, these are: Software, DirectX and OpenGL.

Software means rendering without DirectX or OpenGL (that doesn't mean I won't use these two APIs, but I just want to add this "select-mode feature" :lol: ). Doing so with the GDI is quite loosing control over the low-level, and that's not good for my demo.

I just wanted to know if there are methods in GDI that are actually similar to DirectDraw (that doesn't mean it must be like DirectDraw, but I just want the same control and SPEED).

Aren't there any functions at all in the Windows API that allow you to have low-level control (like DirectDraw) over the graphics (bitmaps/surfaces, video memory allocations, etc). The Windows API may be huge, but it is not very flexible for 'almost' full control. Shame :lol:


Thanks again.

[Axel]

"bandwidth" is a term that stands for data/time (e.g. measured in MB/s), just to clear that up.

The Grey Beast said:

What's faster? Creating the surface in system memory, and then (after plotting all it's pixels) blitting it to the screen (video card), or creating the surface in video memory, and plotting each pixel there (through the bus at each pixel...), and finally do a cheap blit operation to the screen.

Try it. Implement both and do some #ifdefs. It's not that much work and performance-measurement is necessary at some point anyway.

The Grey Beast said:

Aren't there any functions at all in the Windows API that allow you to have low-level control (like DirectDraw) over the graphics (bitmaps/surfaces, video memory allocations, etc). The Windows API may be huge, but it is not very flexible for 'almost' full control. Shame

No, that's what DirectDraw is intended for.
Why don't you want to use DirectDraw? DirectDraw 5 is delivered with every modern version of Windows, so that's not a problem.

Just curious, but are you trying to do 2D or 3D graphics?

[The Grey Beast]

Oh, sorry for the late post, but I'm rather not very much online :)

3D graphics is the answer. I know how to rasterize polygons, apply texture mapping (with filtering), shade triangles, use S-buffers, Z-buffers, C-buffers (coverage), or BSP-trees (needed for alpha testing, I guess), etc. Probably, I'm a bit confused at shadows (maybe because I can't find a fast algorithm), but that should be fine.

Quote

Why don't you want to use DirectDraw? DirectDraw 5 is delivered with every modern version of Windows, so that's not a problem.

DirectDraw (DirectX mode) is not a problem for me because 'it's not included', but rather because I want to let the programmer/user select the mode in my demo... Some programmers I know, really appreciate this kind of stuff, and I thought adding this select feature will just make my demo with something new (ideas, probably...). Sorry for the grammar (I know I misspelled some verbs/words). :happy:

Anyway, I did some research and found that GDI functions (probably DirectDraw also :lol: ) are not the functions that really relate to the drivers. For example, the AlphaBlend function in the GDI, calls the DrvAlphaBlend function in the actual driver, and if the function fails, then EngAlphaBlend is called (software). Maybe I can probably find the functions DirectDraw uses internally (on the NET, of course) and probably find (if any) some GDI functions that call those functions. Then I know I'm at the right place. :happy:

But there's one problem: Each driver has different or same .dll names. For example, my OpenGL driver is in nvopengl.dll. Is the nv prefix present in all OpenGL driver names, or simply because nv comes from NVidia (I have a GeForce card)?

How can I actually know the driver (.dll) name, or is there a common name? If this is impossible, please tell me so that I won't do some research on this.


Thanks again. :)

[Axel]

You don't want to access the driver directly.

[The Grey Beast]

Ok.. I don't access them directly then.

2 more questions (it's amazing how Google can help): What's a device control interface (or DCI). Are there any tutorials about it? Can I access it?

In the Windows DDK, Microsoft mentioned something about a FrameBuffer or somesuch in DirectDraw, and clearly said that the HEL can do everything by itself (almost everything). That's cool... Probably I can (hopefully) manage some tricks on the GDI.

The HEL is not part of the DirectDraw driver, so it can be 'reinvented' in any application, not just DirectDraw (I think it's nothing special). This means there's gotta be a way to lock/unlock and flip surfaces (bitmaps), without DirectDraw.. but I'm still searching on....


If anyone knows something, don't hesitate to tell me (you can also e-mail me if you want :lol: or send me a PM).


Thanks for the help, Axel :yes:

[Axel]

I don't understand your problem. DirectDraw will you give direct access to the framebuffer, you can't get nearer to the hardware in a protected mode OS.

Why are you trying to do such unnecessary hacks?

[The Grey Beast]

I just wanted to implement my own Low-level routines (you know, knowing what's Under the Hood).. I hope I haven't make an offense (I'm truly sorry if I did), or bored you, etc.

Ok, this is my last post this day (time to log off), so see you guys! :)

[Axel]

Under a protected mode OS you don't have access to the register-level. DirectDraw is as low as you can get under Windows.

[pater]

If you really want to do it, you can use the GDI for rendering too. Just draw your entire scene to an off-screen bitmap (You'll have to do it by hand, of course) and BitBlt the whole image at once to the screen. I've done this before, and it's not even as slow as people tend to tell. What you should not do when using the GDI is drawing a scene using single calls to SetPixel().

[JapigeMan]

GDI blitting is pretty fast. I'm just rounding up a little GDI drawing interface.

You just create a Device Independant Bitmap to map a piece of memory to a DC, and you're set to go....

More detailed:
Create a DC compatible with the DC of your destination window.
*CreateCompatibleDC()
Then you create a DIB
*CreateDibSection()
Select the DIB into the DC
*SelectObject()

Then manipulate the data in the DIB as you please using your own drawing algorithms.

When you're done you copy it to the destination window
*BitBlt()

I can do alpha-blending, blurring, fading, whatever. It's all pretty fast.
The bottleneck AFAIK is still the BitBlt() call to actually get it on the screen, so try to update your screen efficiently.
I also daddled a bit in DirectDraw. It's nice, but maybe you should into SDL or Allegro. (never tried them though).

* can be looked up in the MSDN, just google for it, it's always the first hit you get.

[The Grey Beast]

Yeah... I know BitBlt is a fat slow cheese... I'll try to make my own blit (trying to get around 1000 frames per second on a 320x200 display)

Thanks for all the help :)

[pater]

1000 fps?? What the heck should this be good for? You do know that the eye can resolve 30fps max and your the most expensive screens are capable of displaying 120fps? Wouldn't it be more usefull to increase the screen resolution? :confused:

[JapigeMan]

Teh Gry B34st said:

...I'll try to make my own blit (trying to get around 1000 frames per second on a 320x200 display)]

Thanks for all the help :)

Good luck with that... :yes:

[The Grey Beast]

pater said:

1000 fps?? What the heck should this be good for? You do know that the eye can resolve 30fps max and your the most expensive screens are capable of displaying 120fps? Wouldn't it be more usefull to increase the screen resolution? :confused:

I was refering to 1000 fps with a black screen -- no other computations and drawing should be done... only the blitting... and of course I will increase the screen resolution, but this is just a starting point. :)

[pater]

Ahhh... Now this makes a lot more sense :blush:
Good luck :yes:

[The Grey Beast]

Thanks guys :D