I would just love to ask a question about the possibly of creating a 2D RPG game in Qt QGraphicsView
A game similar to battle heart - http://www.youtube.com/watch?v=0VqlJ_AvFS8
Why am thinking of using Qt?
Qt is cross platform, and the support for mobile platforms like iOS and Android is increasing fast
I want to save the image on HD as SVG
I want to render the images on the fly ( For the example, when the game is loading ) into pixmap images for better performance after scaling them to the appropriate screen size ( So we cab have a ++, better performance, and infite support to any screen size )
What do you guys think about Qt? Do you have any other good options,
Qt make converting SVG to PNGs as easy as it could be, so that's the killing feature why am sticking to Qt
Bests
I've done this, and I can confirm that Qt is a perfectly good option, as long as you're not particularly concerned with download size (you're probably going to end up with a minimum of about 30 megs). You might consider looking into QML for handling your UI animations, as it's particularly well suited for that sort of thing.
I would strongly recommend using the OpenGL 2 backend, as it's fast, and it allows for GLSL shaders, which are good for special effects. It's also possible to use a QGLWidget as the background so you can do direct opengl drawing if needed.
Edit: Source is available at https://github.com/lendrick/Orange-Engine/wiki
Related
I wonder, if it is more beneficial to use the abilities of QML for animations, or prefer to use animation files (such as GIF oder MNG) for simple, small-scale animations.
Examples for what I call "simple, small-scale animations" are:
turning Hourglasses
those rotating dots, known from video platforms, while loading
flashing alert symbols
those "recharging buttons" known from many RPGs used for special attacks
I don't know much about the internals of Qt, so I am unsure, whether I benefit from hardware acceleration, when programming the animations (e.g. image rotation) or not. And if so, whether this hardware acceleration outperforms the display of pre-calculated animations from GIF and MNG.
Greetings and thanks,
-m-
I wouldn't worry about things like this unless they visibly slow the performance of your application. Some points to consider:
The use cases you mentioned almost always involve only one "busy indicator" being visible at a time.
Both Image and AnimatedImage have the high DPI #*x file look-up.
Both Image and AnimatedImage support caching.
Both Image and AnimatedImage will use the Qt Quick scene graph to display the images (OpenGL textures, which should result in hardware acceleration).
AnimatedImage has to read several images, but won't require rotation.
Rotation of images is pretty cheap, as far as I know.
It's trivial to swap out one with the other, or with something else.
If you're looking for good general performance advice, read the Performance Considerations And Suggestions documentation.
I have been trying to come up with a solution for having a QtQuick 2.0 scene together with a Direct3D scene for quite a while, but wasn’t very successful. My goal is to have a Direct3D engine running at reasonable speed (60 FPS?) together with QML UI on top. Both things run just fine at 150-200 FPS on their own. But when forced to cooperate together within one window, everything just goes bananas. I have investigated several approaches, but none of them seems to be sufficient enough:
Solution A: Rendering Direct3D scene into a texture, visualizing with QImage & QQuickPaintedItem
this solution works quite well and it seems to be the preferred one according to other people on the web. However it is TERRIBLY slow. I wasn’t able to have more than 18-20 FPS in full HD. The bottleneck was clearly in the texture transfer chain from GPU (D3D) to CPU (QImage) and back to GPU (QML renderer) each frame. Especially the CPU->GPU processing on the QML side was way too slow!
Solution B: Rendering QtQuick scene into a FBO, then using Direct3D texture
this is basically the previous solution other way round. The speed is a little bit better when the UI does not require an update. Once it starts animating, everything drops down to 18-20 FPS again. QOpenGLFramebufferObject::toImage() obviously takes its time. Implementing texture/FBO double buffering on both sides to reduce stalls does not really help.
Solution C: QQuickView with enabled transparency on top of QWidget with Direct3D scene
was not lucky with this approach either. It seems like the transparency works only when QQuickView is in its own window. Once I put it on top of my D3D QWidget within the same window, it immediately stopped working and became fully opaque. Someone was trying to do something similar there as well: http://qt-project.org/forums/viewthread/5484, but I had no luck with that solution at all. Maybe keeping two completely separated windows (main D3D window + frameless transparent QML window) on top of each other all time would do the trick, but that just sounds silly.
Solution X: Modify ANGLE library and try to extract & share D3D device context with my Direct3D renderer
haven’t tried this yet, avoiding any library modifications as long as possible. Would that even be a sensible option?
My obvious questions here are: Am I doing something wrong? What is the preferred solution? A, B, C, X or maybe something totally different? Can someone point me to the right direction?
TL;DR: What is the fastest way to render QML scene on top of Direct3D scene?
Sounds like you ideally want a bastard mix of Solution X and writing yourself a DirectX QPA plugin.
http://qt-project.org/wiki/Qt-Platform-Abstraction
I'd wager you'd make a lot of friends if you open sourced such an effort!!
I am using wxWidgets to draw a large flow chart, i.e. 625 x 26329 pixels. The program was transported from Qt to wxWidgets. It is easy in layout with a main frame which has a customized scroll window inside. The scroll window draws part of the chart every time within updated client region.
Now Qt and wxWidgets make much difference. When scrolling vertically with mouse rolling, Qt refreshs painting the chart very smoothly, while wxWidgets is slowly with flicker.
Can anyone tell me how to make the painting efficiently?
Are you sure it's slow? I would be wondering, I encounterd a different experience.
You mention flickering. Flickering is mostly result of too many refresh calls.
To prevent this you must use double buffering and this is the key.
Double buffering means to draw all stuff offscreen into a image / bitmap and after everything is drawn the image/bitmap is drawn fully (this is done really fast so no flickering :)! ).
Qt uses for default double buffering. That's why it looks everytime smooth.
However the downside of this approach is that it consumes performance.
wxWidgets doesn't bound you to that. Instead it says, it's your task to get double buffering.
Also you should look whether you aren't clipping the region you're drawing. Clipping under Windows with wxWidgets gave me a really better performance.
PS:
Yes, old question but I think it's still needed to know how the facts are.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
For basic 3d web application i.e. a few cubes, rotation and translation in 3d space - which is better to choose?
CSS 3d seems the easiest, but is not supported on IE9 or on the roadmap for IE10, and offers less control than the other options.
Canvas & WebGL seems way more complicated, but I don't know if they are future proof.
Why are there so many different techniques for 3D? which is better? which is future proof?
The reason there are so many different options for 3D is because the whole thing is still in a state of flux -- 3D in the browser isn't a finished standard, and of the options you listed, the only one that works in all currently available browsers is Canvas.
IE in particular is unlikely to give you much joy -- as you say, 3D isn't even slated for IE10 at this point. Having said that, SVG was added to IE9 quite late in the day, so there's always hope. But the reason it's unlikely is that Microsoft have made a point of only supporting features which have been formally ratified as standards.
Of the technologies you listed, Canvas is by far the best supported, but Canvas isn't a 3D technology; it's a 2D canvas, and if you want to have 3D effects in it, you need to write them yourself, and they won't be hardware accelerated.
I guess the real answer to your question depends on how important the feature is for your site. If it's just eye candy, which users of unsupported browsers could live without, then by all means do it with some 3D CSS. But if you need to make it consistent in all current browsers, then do it with Canvas.
I'd tend to recommend not using WebGL for your case, because it sounds like it would be overkill for what you're doing.
3D CSS is probably the right answer, but use Canvas for now, until the rest of the browsers add support for 3D CSS.
I know this is 2 years old but I figure I'd post this here for future readers.
What to choose depends on what you need.
Do you need a simple 3d shape with no or little animations? Try if you can do it with CSS3, that's the easiest by far. For IE you can probably get a library that offers support.
Do you need some sweet 3d models with nice graphics and that can do all kinds of stuff? Go WebGL, you can't ask for more control AND performance for 3d in browsers.
Do you need 3d shapes that can do all kinds of stuff, but don't need textures and will work everywhere and won't require much performance? Go Canvas.
CSS3 is just for the eye-candy. You can make it rather easily, style it any way you want and is very easily maintainable. Once you want to do more than just eye-candy, put on your gloves because that is gonna reuire some work.
With 2d Canvas you can make 3d stuff. If you're new to it, it will be very annoying and complicated (to name one example; you need to know of matrices), You can pretty much do anything with 2d canvas that you can do with WebGL but some thing will be easier in WebGL (seriously, if going 2d Canvas, don't try to use textures, it's a nightmare). WebGL uses OpenGL which, in a nutshell, means it will always outperform 2d Canvas.
However, WebGL requires the user to have a compatible video card.
I really depends on what you are trying to do. How simple is simple?
3D CSS is far from usable. It's only just made it into firefox. It's buggy in both firefox and chrome. It's not working in FF9 beta on OSX. It's also got issues in Chrome up through at least 16. See http://greggman.com/downloads/examples/intersecting-elements-3d-css.html and compare Safari on OSX to pretty much any other browser.
three.js (https://github.com/mrdoob/three.js/) used to (and maybe still does) provide some simple 3d using canvas.
Otherwise if you want anything interesting go WebGL and pick a library (three.js, SceneJS, etc..)
You've got to make a choice. Use WebGL and give up IE, Use Flash 11, Use Unity3D, use Canvas and get very limited 3d, or don't do 3d.
WebGL is already being used by major sites. CNN is now using WebGL http://www.stinkdigital.com/en/work/ecosphere
Everyone is probably tired of hearing 'it depends', but...it depends!
There's a little "war" going on as to whether it's better to use Canvas or HTML/CSS3, and namely because Canvas is slower than DOM on older machines/devices. Yeap, DOM is way faster in some cases, while canvas is faster on most modern browsers/devices.
WebGL - Best option for both 2D and 3D, but since it is not well enough supported across browsers and devices, you'll have to offer fallback to canvas or DOM whenever necessary.
Canvas - Less suitable for 3D comparing to WebGL, but more suitable for compatibility, community, tools etc
DOM - Faster than most think, if used right, highest support around, but you cannot go too fancy animation/gaming-wise.
Hope this helps
My problem is that we have developed a product using 480x800 on a 10" LCD display, and we want to "give the idea" to a customer who has a PC.
No modestly-priced laptop has a vertical resolution of 800 these days, probably because of 720p standards, but I digress.
Basically, I want to take a suggestion back to the designer, who used Qt, and suggest something that will work. He has already stated that it is impossible, but I suspect that is laziness talking.
As a .NET developer, I know how easy it is to scale a WinForms application, but I don't want to suggest something where I have no expertise, and while searching StackOverflow and Google for tips with scaling and Qt have yielded no results.
Is there something easy to cause an entire application to scale downwards in Qt?
Thanks for any help you can provide.
If you mean normal scaling where some widgets retain their sizes and some scale, then yes, it's really easy (like what a WinForms developer achieves with anchors if I remember correctly). Just a matter of using layouts and spacers. Grid and form layouts are very flexible but in case a more complicated layout is needed it's easy to add a subcontainer that has a different layout. This layout concept is similar to Java SWING and AWT layouts.
Also, if he used Qt Creator to design the ui, then selecting the container and applying grid layout often yields the desired results (it's on the toolbar).
If you mean proportional scaling of all widgets then it's not simple. One would need to override the resizeEvent and scale all widgets accordingly, plus fonts are tricky to scale well.