|
Steve Hazel wrote: fn=c:\test_00.bmp w=6400 h=4900
That is quite a large bitmap. On my machine CreateCompatibleBitmap falls over and GetLastError() returns 0x00000008 - "Not enough storage is available to process this command" when I try to create large bitmaps.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good, use it!!!
|
|
|
|
|
Thanks for checkin' into it - I appreciate that 
Yep. I noticed it was biiig, but this machine handles it ok
and I only need the app to work for -me- so I can get this bitmap for my docs.
I wonder how to get around this...
I wonder how the printer driver handles this big of a bitmap?
Keeps it compressed or somethin?
I'd really like to have a full resolution bitmap (or jpg or whatever) for
my docs for this app. (which eventually will just do a regular printpreview)
Anybody got any ideers?
Thanks
...Steve
|
|
|
|
|
Steve Hazel wrote: I'd really like to have a full resolution bitmap (or jpg or whatever) for
my docs for this app. (which eventually will just do a regular printpreview)
This may be a dumb question, but if you have access to the application (and presuming it shows the image on screen), why not just print-screen and extract the necessary image using Paint?
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
When my app prints, it uses a different drawing function than when drawing in a window.
(Takes advantage of the higher printer resolution, etc)
We're talkin music printing here, by the way.
On screen, it's a regular piano roll as my docs show here:
http://shazware.com/ditty/12_tinker.html[^]
On the printout, a couple pianorolls are squashed on the page in parallel down the page (as space permits).
Ok, so how can i get that big ole bitmap... But non-black ?
The bitmap file =is= being created, (93 meg!) but it's all black.
The size can be alloc'd - width * height * 3 (bytes for RGB).
So either the BitBlt ain't workin or the GetDIBits() ain't workin...
Hmmm...
Bet it's the GetDIBits runnin outa space...
[edit] nope - the new works so why would GetDIBits need space? [/edit]
Maybe it'll work on my machine at home... I think it's got more ram
...Steve
|
|
|
|
|
Steve Hazel wrote: Anybody got any ideers?
Yeah - don't know if they are good or not though
Saving at a resolution higher than the highest source resolution is a waste of resources IMO.
Compressing with a lossy compression algorithm kinda negates the reason for saving the high res
data.
Maybe something like a metafile would be more appropriate. That way the saved data isn't bound
to a certain device.
I don't think you can count on being able to read from a printer DC. You could, however, create
a memory DC and an appropriate bitmap (DIBSection would be handy) at the desired resolution and
do all your drawing on that DC and save the DIB section as a BMP.
|
|
|
|
|
Thanks SO much for the help
Ok, I only need the bitmap file for my docs.
(read my reply to James Twine above...:/)
So what's this "metafile" thing you speak of?
And "DIBSection"?
Time to hit google which will point me back to CP...
Then read up in MSDN for a while...
Then come back here...
Unless you can gimme some shortcuts
Thanks very much,
...Steve
|
|
|
|
|
A DIB section is a DIB that can be selected into a DC like a DDB. Besides giving you direct
access to the pixel data, it's also already in DIB form which makes writing a BMP file simple.
If memory is the problem though, that method won't help
Metafiles[^]
|
|
|
|
|
I don't think memory is the problem...
The machine slows down, but mem -is- alloc'd at the last step that needs to alloc.
at char *bits = new char [sizeVarWhateverThatWas];
But the bitmap is black (all 0s)
So GetDIBits() must not be workin... It works to get the size, but not to actually set the DI bits...
Dang.
All I can come up with is to pop a dialog with the biggest custom control that'll fit on screen,
draw in it, screen print, move it (the control is the size of the full printer bmp),
printscreen, move it, printscreen
then knit all the printscreens back together with mspaint 
If you got any better ideas, i'm all ears
How does a metafile get me to a .bmp?
And my drawing code doesn't flip bits or set pixels, it does the usual graphics via HDCs...
...Steve
|
|
|
|
|
Steve Hazel wrote: So GetDIBits() must not be workin... It works to get the size, but not to actually set the DI bits...
Yeah...once you've written to a printer DC, I don't think you can read the resulting pixels
from the DC. They may not even be in RAM.
You can still always create your own dc and draw to it the same as you draw to a printer DC.
Way easier than the "draw in it, screen print, move it " method
Steve Hazel wrote: How does a metafile get me to a .bmp?
It doesn't. It gives you a metafile, a recording of all the drawing you do to a DC.
The docs explain it better than me ...
Enhanced metafiles provide true device independence. You can think of the picture stored in an
enhanced metafile as a "snapshot" of the video display taken at a particular moment.
This "snapshot" maintains its dimensions no matter where it appearson a printer, a plotter, the
desktop, or in the client area of any application.
You can use enhanced metafiles to store a picture created by using the GDI functions (including
new path and transformation functions). Because the enhanced metafile format is standardized,
pictures that are stored in this format can be copied from one application to another; and,
because the pictures are truly device independent, they are guaranteed to maintain their shape
and proportion on any output device.
That may even be what a printer device driver uses to avoid needing a huge chunk of memory for a
bitmap.
Anyway, if you need a BMP, you can create one at any time, at any size, by "playing" a metafile
on to a DC. A DIBSection could again be used to make saving easy.
|
|
|
|
|
Problem Solved !!
And, again, thanks for your help
What i do now is
- first create the memory HDC + HBITMAP,
- pass the hdc to my PrntGfx function that draws,
- THEN do the bitmapinfo/bitmapfile/GetDIBit()/file writing stuff
- (and cleanup, etc)
I have a few misc things to do like make sure the memory bitmap is WHITE like a printout and PrintGfx needs to be able to do ONE page at a time or somethin.
But there is now a WAY OUT of my hell
Thanks so much for kickin me in the right direction!!
...Steve
|
|
|
|
|
Cool That's what I was getting at using a DIBSection. With a DIBSection instead of a HBITMAP
it saves you the GetDIBits step. Otherwise it's the same.
Cheers!
Mark
|
|
|
|
|
More info on the differences between printer DCs and screen DCs...
About Printing[^]
|
|
|
|
|
(my english is not so good)
I'd like to draw a window in a game (like XFire) but I don't have an idea how to do this. I think something like a Hook would be great. Best would be a non-MFC Code (I usualy use normal Win32).
|
|
|
|
|
You say "semi transparent" but what do you mean?
1. A window that is not square?
2. A window with a glass effect ( blended with the background )?
|
|
|
|
|
semi means "half" also, so i understand it as if he asked the alpha=50%
|
|
|
|
|
but he also mentions a hook, which in my interpretation is a shape 
|
|
|
|
|
no, the hook is not the shape. he talks about a Windows Hook here (the "hacking" method)
it seems that i was wrong in fact
-- modified at 12:54 Wednesday 7th February, 2007
|
|
|
|
|
possibly, but why would you need to "hack" a window to enable transparency?
|
|
|
|
|
no idea... but let's hope Parallan will read this
|
|
|
|
|
I ment a window that is not square, glass effect needn't to be
And with "hook" I ment, that I can change pixels after the Game has done a render step
|
|
|
|
|
If you need an example: http://media.xfire.com/xfire/xf/themes/XFire3/images/tour/tour_image_4.jpg
|
|
|
|
|
|
Sorry, I think you missunderstood:
This Examples dont work in Games, only in Windows!
I'd like to have something, that I can see while I'm playing a (3D)game
|
|
|
|
|
Parallan wrote: This Examples dont work in Games, only in Windows!
You said in your first post that you were using the win32 api. In fact you don't want to use regular windows but create your own that are semi-transparent ? Am I right ?
If yes, it would be really helpfull to know which libraries you are using (I suppose that you use a 3d engine). There could be support for basic GUI in it.
But anyway, you'll probably need to find a way to draw that yourself. What are you using for the rendering ? DirectX, OpenGL, ... ? (or maybe you don't do anything yourself and let the engine draw everything ?)
|
|
|
|
|
It would be enough, if I could draw pixels in front of the Game (at end of each render my pixels should be drawn).
-- modified at 7:16 Thursday 8th February, 2007
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
