Quick question! [DIBs]

For stock windows mehtods StretchDIBits is probably the easiest to use.

For spead you may have to move to a graphcis API. DirectX has a sprite class that I tent to use alot. Is DirectX an option??

Cheers
Chris

Quote:

Original post by chollida1 For stock windows mehtods StretchDIBits is probably the easiest to use.

StretchDIBits is 'DIB to DC'

I asked for 'DIB to DIB'.

Your right, but you can always get a dib back from a DC:)

Cheers
Chris

quick answer

look at CreateDIBSection

BitBlt would probably be the fastest GDI method:

SelectObject (src_dc, src_bitmap);SelectObject (dest_dc, dest_bitmap);BitBlt (dest_dc, 0, 0, w, h, src_dc, 0, 0, SRCCOPY);

I don't think you'll get any speed improvements by using DirectX - GDI is hardware accelerated as well, maybe not as much, it depends on the drivers (DirectX was originally planned to replace GDI, or at least, sit underneath it). You won't get transparencies unless you do two BitBlts (and the mask, or the colour). GDI+ may support transparencies - never used it so I'm reiterating what I think someone else here has said.

Skizz

Why do I feel like a moron?

Ok, let me make this clear.

iNofORMaTioN!11
OpenGL - NO
DirectX - NO
BitBlt - NO
GDI+ - NOoo
.NET - NOoooo
DIB->DC->DIB - WTF? NOooooo!!1


@petewood
Thats nice but umm, I asked how to draw a DIB onto another DIB, not how to create a DIB!

@Skizz
Be honest, you really don't have any idea what I'm asking, do you?

Well then when I'm looking for a certain function that I think someone would have allready implemented. I look at www.codeproject.com. They've got lots of good implementations.

Hope that helps you !!

Cheers
Chris

I've been there, didn't find any relevent articles.
I've also googled it, didn't find any relevent matches.

Allright, then one last stab at it:)

You do know that by setting a dib into a dc and then drawing another dib onto it you are doing what you want. THe dib in the dc will have the other dib on it.

With out knowing if htis is supposed to be cross platform this might be the best I can do for you!!

Cheers
Chris

Quote:

Original post by chollida1 You do know that by setting a dib into a dc and then drawing another dib onto it you are doing what you want. THe dib in the dc will have the other dib on it.

Yes, I know that.

This may sound strange in the "Microsoft Windows" environment, but I'm after performance!

The reason I'm drawing a DIB onto another DIB DIRECTLY is because its FASTER than drawing everything onto a DC.

Only my final product is being draw onto the window DC, all other drawings are done via DIBs.

How did you create the DIB? I've used DIBs before through CreateDIBSection. This gave me direct access to the bits and copying one was a matter of copying bits of one DIB onto the bits of another.

Quote:

NetCoaster The reason I'm drawing a DIB onto another DIB DIRECTLY is because its FASTER than drawing everything onto a DC.

You don't draw onto a DC - a DC is not a thing that can be drawn onto. A DC is a collection of functions that manipulate DIBs. You attach a DC to a DIB and under the hood the DC configures itself to optimally manipulate the DIB. Compared to the cost of doing the blit, the setup is insignificant.

Have you actually timed the blits? Are they really that slow?

The only other thing I can think of is to store your bitmaps as byte arrays and write your own copy function. The blit might then be faster but you have the overhead of converting to a DIB to draw to the screen which will cancel out any improvement your custom blit created (unless you're using DirectX) and you don't get the benefit of any hardware acceleration that might be present.

Skizz

Quote:

Original post by NetCoaster @petewood Thats nice but umm, I asked how to draw a DIB onto another DIB, not how to create a DIB!

Firstly, less of the attitude, thanks.

As Ternary said, if you have a DIB, created using CreateDIBSection, then you have access to the 'bits' of the bitmap. You can simply copy using memcpy or whatever.

Quote:

Original post by petewood if you have a DIB, created using CreateDIBSection, then you have access to the 'bits' of the bitmap. You can simply copy using memcpy or whatever.

I knew that already. memcpy doubles the data, and loops are quite slow. Reread my question.

And I'll lose that attitude when people with more experiance in programming start posting on this thread.

I honestly don't understand what's the problem. You have 2 choises:

1)CreateDIBSection returns the address in RAM where the bitmap resides. You can manipulate the pixels directly, so write an algo that copies chunks of memory from one buffer to another.

2)CreateDIBSection also returns an HBITMAP object, which can be selected into a dc, so you can use BitBlt and GDI functions as well. I think Skizz already mentioned that.

Quote:

Original post by mikeman I honestly don't understand what's the problem. 1)CreateDIBSection returns the address in RAM where the bitmap resides. You can manipulate the pixels directly, so write an algo that copies chunks of memory from one buffer to another.

Well your 2nd option was off, but your on the right track with your solution #1.

I'm after an algorithm that copies the chunks of memory from one buffer to another, but does it sigificantly faster than others.

My 640x400 GDI game does alot of drawing, and his realtime lighting and weather effects (It's a wonder I'm doing in GDI and not OpenGL). The game is runnable on my computer, but I have a 2.0GHz Amd: I want it to run well even on older PCs.

Perhaps this is the wrong website to be asking these questions: I'm after performance, not simply getting the project done, or programming it the most standard way... I've had people recccommend I write this game in Java! Jeeze... yah and while I'm at it, why don't I use GetPixel & SetPixel instead of DIBs because GetPixel and SetPixel is more ISO standard.

Edit: I think the next post I make, is gonna have a complex code example, that way it scares off all the inexperianced programmers from commenting.

Quote:

Original post by NetCoaster I knew that already. memcpy doubles the data, and loops are quite slow. Reread my question.

What are you on about? I've had a look at your post history and it seems you are very new to programming, especially Win32 programming. If you find yourself fighting the OS, it's probably because you're doing something that thousands of programmers and designers far more experianced than you have decided isn't a particularly good idea.

Exactly how did you think you could place one bitmap onto another without 'doubling the data'?

So, to put one bitmap onto another you have three options:
1) Create HBITMAPs and DCs and use BitBlt (two, for masked blits)
2) Use DIB sections and write your own blitter
3) Use DirectX

(1) and (2) will be fast enough for most applications and without actually timing them, they may be about the same speed.
If you want bleeding edge speed then use DirectX - it's a lot more complex though.

Quote:

And I'll lose that attitude when people with more experiance in programming start posting on this thread.

There are a lot of very experianced people on the board and you've pissed them all off, hence your zero rating. I myself have been programming for nearly 25 years and programming Windows for 14 of those (yep, I did Win3.1 programming!).

In future, I suggest stating your requests clearly and explaining why you want to do whatever it is you're asking about and avoid statements like:

Quote:

This may sound strange in the "Microsoft Windows" environment, but I'm after performance!

and act upon the replies you get (have you actually timed the Win32 BitBlt functions?)

Skizz

Quote:

Well your 2nd option was off...

LOL
No it wasn't, but suit yourself. I doubt you can write a blitter faster than GDI's. Unless you want more control of pixels than a single blit can offer, so your only choise is to manipulate memory yourself. And btw, your attitude is really weird.

[Edited by - mikeman on November 4, 2004 11:40:34 AM]

Hey Netcoaster,

I know your after performacne, but I think your mistaken about memcpy. ITs about the fastest way to copy memory there is!!, no stretching or pixel format changes. Its probably the most optimized method available.

I remember Intel comming to us and showing how their SSE2 version of memcpy could give us a 5% speed improvement!!

If you want to copy bits around, ie drawing one DIB onto another, you won't get faster than memcpy.

I hope that clears up some of your misconceptions!!!