Is there a way to create a ID2D1BitmapRenderTarget without calling CreateCompatibleRenderTarget on a "parent" render target?
MSDN shows the way how I can do it with WIC, but I am not sure, will the drawing operations be accelerated by GPU, so not sure to go this way.
Thank you.
Related
As I mentioned in a question before, I am trying to make a simple game engine in C++ with OpenGL.
I am currently using GLFW for drawing the OpenGL context and I chose it because I heard it's one of the faster ones out there. However, it doesn't support widgets and I really don't want to write them myself. So I decided to get into Qt a bit, because it would allow me to have a pane for the render context and different handy bars as well as all the fancy elements for editing a world map, setting OpenGL rules, etc.
I want to use GLFW on the exported version of that game, though. Is that possible without an abstraction layer of some kind?
Thanks in advance! :)
Yes it is definitely possibile, infact I'm writing a 3D engine that is not coupled to any windowing library and can be used with Qt, SDL or whatever.
You of course have just to wrap regular GL calls into a higher level layer, this require you don't call "SwapBuffers" inside your GL code.
If by abstraction layer you mean "inversion of control" so, you don't want to override a "Render/Update" method that's exactly what I done. If by "abstraction layer" you mean you want to use GL directly than it is still possible.
Basically every windowing system have "some place" where you can make your GL calls (between MakeCurrent and SwapBuffers). Just read documentation of your windowing system.
I'm drawing some graphics and text with GDI in my CScrollView. I need to implement the zooming functionality. I only need the zoom out functionality, no need to zoom in more than what is normally rendered.
Here are my best ideas:
Use MM_ANISOTROPIC mapping mode with SetWindowExt/SetViewportExt... The problem with this approach is that it does not scale text. Is there any way to force MFC to scale the text as well? Only thing I can think of is to set text font size according to the selected zoom value, but I'm not sure whether this will look well after all...
Draw to memory DC, and use StretchBlt to blit to the client area of appropriate size (set with SetScrollSizes...). This will solve the text scaling issue.
Also it is desirable to have antialiasing effect in the process. I think both methods above should accomplish this per se, but I don't know which will look better. Also I will have to implement printing/print-preview functionality later (using MFC's standard implementation from doc/view architecture), so I need the method to be compatible with that.
Need your advice please. Which way to go and why. Maybe other options exist too?..
You really don't want to mess with the mapping mode when you use MFC -- MFC itself already uses it for (at least) the print preview functionality.
I'd see if SetWorldTransform will work for you. At least with vector/TrueType fonts, it will scale the text along with everything else. Note that before SetWorldTransform will work, you need to call SetGraphicsMode with GM_ADVANCED.
I ended up using the second method I proposed in the question, but used DIBs instead of DDBs (and StretchDIBits() instead of StretchBlt()) because it proved to cause less problems, especially when using big bitmaps, and when printing.
Is there any way I can read the content of the framebuffer in Qt or anyway in C? I read it is possible to write the content of /dev/fb0 to a file and then load it. But is it possible to avoid saving it to memory and simply copy to a new memory location to use in Qt?
Thanks!
The ordinary Qt distribution is not likely to have special support for reading a framebuffer on Linux. It layers on top of X11 and is trying to provide cross-platform capability (as things like /dev/fb0 won't have meaning on Windows, for instance). So you would use higher level abstractions, such as the QPixmap::grabWindow() that #BerkDemirkir points out...probably a lot of hops through layers before the framebuffer.
(Note: If you are writing an ordinary cross platform Qt app intended to run in a windowed environment, that's certainly the route you want to go for a simple screen capture task!!)
On the other hand, Qt/Embedded is designed for Linux and to work with the QWS instead of X11. The mindset is that there's no windowing system and your app owns the whole screen. It writes directly to the framebuffer through a QScreen object, which has a base() method that can actually give you a pointer to the underlying memory:
http://doc.qt.nokia.com/4.7-snapshot/qscreen.html#base
Those are probably the only "Qt" ways to do these kinds of things. If you want an API instead of going through to /dev/fb0 directly you might investigate something like EZFB. (I didn't dig deep enough to know if it's useful or not, just found it with a query something like "linux framebuffer API")
http://freshmeat.net/projects/ezfb/
You can look this example to take a screenshot from any window (even desktop). Example uses QScreen::grabWindow() function to take screenshot.
Could anyone suggest me a particular way to implement animation in my Dialog-based mfc program? The animation that I am intending to add is like a construction digger machine graphic that would read the values of the machine parameters and change the shape of the graphic accordingly. Most of the information is read from a text file in terms of the parameters, so I just need to be able to get the animation working.
Thanks for your help in advance.
Well, GDI is easy but ugly and quite slow, GDI+ is also easy, but nicer although generally slower. OpenGL or DirectX are much, much faster but quite hard to program. Other libraries, such as cairo, are also available.
I'd suggest to start with the easiest (maybe GDI+) and see if it is fast enough for you.
Do do that, just Invalidate() the control where you are drawing in a timer, (or when you receive new data), and paint the whole graphic in the OnPaint() function. A basic improvement is to Invalidate() only the region where the new data affects the picture.
If then you notice that your code is not fast enough, come back and ask how to improve it. A concrete example will make it easier to get a more useful answer.
there are lot of articles. Most of them based on drawing in device context
http://www.codeproject.com/KB/GDI/flickerfree.aspx
http://www.codeguru.com/cpp/g-m/bitmap/article.php/c4879
http://www.codersource.net/mfc/mfc-gdi-plus/animation-control-mfc.aspx
Given that I am programming within another program already using OpenGL (let's say theoretically that I have no idea how they are using it).
Can I just set up my context however I want and push/pop it from the stack and all should work as expected, or MUST I know how my (calling) program is using OpenGL in order to avoid accidentally screwing things up?
Also, how would I go about "initializing" OpenGL when it might have already been initialized?
Thanks for any advice you might have!
To answer your first question, you probably could get away with calling glPushAttrib(GL_ALL_ATTRIB_BITS) before calling the program's functions, and calling glPopAtrib() afterward. Note that this can be slow if you do it frequently (say, every frame in a loop).
I'm not sure what you mean by initializing OpenGL. Do you mean setting up the rendering context? Setting viewport and projection? Disabling or enabling certain features? You can always check if certain states are enabled (using glGet functions), but the rest depends on how your program and the other program work.
I am told that theoretically OpenGL should be able to work within any context as long as you restore the prior context afterwards.
What exactly do you want to do with OpenGL? Are you trying to draw into the same window? Do you want to draw into your own window? If you want to just draw into your own window, and the fact that the existing app uses OpenGL is just a coincidence, then you can probably get away with just creating a completely new context and ignoring the existing stuff. The only gotcha is that you will need to make the existing context current whenever you finish what you are doing, and make your context current whenever you want to do something with it. The existing code won't be expecting to need to make its own context current, and may wind up randomly drawing into your context if you aren't careful.
If you want to draw into the existing window, then your use almost certainly requires some sort of idea about what the existing stuff is doing.