I need to draw a circle with a radial gradient on the canvas in my custom control (XAML). But Windows::UI::Xaml::Media contains LinearGradientBrush only. I know about design guids but my control requires so feature to the user can see the color gamma.
Below that I need to get:
P.S. I ask how to draw it at least programmaticaly without XAML.
P.P.S. I know that I can draw a picture in some editor with radial gradient and after draw it on the canvas but it seems not good solution for the adaptive design.
You can check the RenderColorPickerHueRing() method for a sample of how you could do it on a CPU in a WriteableBitmap. It's not super fast (at least in the C# version), but at least it saves you from packaging another image with your app or from using DirectX, which is a bit more tricky to get set up correctly and stabilize.
Related
I'm working with OpenGL and Qt. I render a scene in an OpenGLWidget. When hovering over objects in the scene, I would like to display a box near the selected object with some text. I have already implemented the selection of the object.
I thought of two possible approaches.
Place a widget (such as a QLabel) above the OpenGLWidget in
which the scene is rendered.
Render the text in a quad directly in OpenGL.
Which of the two approaches you recommend and you could please give me some suggestions on implementation. Alternatively, you could recommend another approach. Thanks!
Hi #Artic I am not a Qt expert so I can't give you information on widgets, but I can give you some pointers for creating a label with OpenGL. Giving a full implementation is tricky here because it depends a lot on how you want to display the text. But I'll try to outline some of your options.
To render text in OpenGL most people go with a technique known as bitmap fonts, see more here:
https://learnopengl.com/In-Practice/Text-Rendering
The concept of bitmap fonts is fairly straight forward, all characters are pre-rasterized to a texture and then you can sample from each part of the texture depending on the character you need. You build your label out of quads, textured with each part of the bitmap you sample from for each character.
Signed distance fields essentially use the same technique but the pre-rasterized texture of characters are rendered using signed distance fields which deal with some of the issues that standard bitmaps fonts have.
In basic terms, SDF works by generating a special texture, or image, of the font that stores the distance from the edge of each character to its centre, using the colour channels of the image to record the data.
If you use signed distance fields it won't be enough to just sample from your bitmap, fonts rendered this way require extra work (typically done using a shader program) to produce the correct rendering.
Once you have a way of generating a label you can decide if you want to display it in screen space or in world space.
If you want to display it in world space (where the label is hovering over the model or item) you will need to do more work if you want that label to always face the camera and this technique is called billboarding.
You could also render your text "on the fly" if you just want to render some text to the screen in screen space. You can use a library like SDL_ttf.
See: http://lazyfoo.net/tutorials/SDL/16_true_type_fonts/index.php
In this example you use SDL_ttf to render a string of text to a surface with dimensions of your choosing, you can then create an OpenGL texture from that surface and render it to the screen.
Sorry if this information is a bit broad, I would need a more specific question to give you further implementation details.
For an implementation, I would evaluate the pros and cons based on what you need. If you haven't implemented a system for rendering text before it's probably best to stick with something simple; there are more techniques for text rendering than I have listed here such as turning text in to polygons and other libraries which attempt to deal with some of the issues with traditional font rendering techniques but you probably don't need anything complicated.
For a recommendation on which to use I would go with the technique that you feel most comfortable with, typically doing things from scratch in OpenGL will take more time but it can provide you with a nicer set of functionality to use in the future. However if Qt already has something nice for rendering a label (such as a widget that you mentioned) it is probably worth taking the time to learn how to use it as it may yield faster results and you don't want to reinvent the wheel if you don't need to. On that note though doing things from scratch with OpenGL can be very rewarding and greatly improve your understanding since you have to get familiar with how things are done when you don't have a layer of abstraction to depend on. Ultimately it depends on you. Good luck!
You could use tool tips in Qt. The string will appear when the OpenGlWidget is hovered over. You can change the text of the tool tip based on the mouse location in the scene, using the tool tip method showText():
QToolTip::showText(QPoint &position, QString &text, QWidget *w);
There are more options for the showText() method and can be found in Qt's tool tip documentation. Also, here are more examples on how to use Qt tool tips.
I’ve tried my best searching online and reading the documentation to find a good answer, but I have yet to find one.
I’m creating a multi-platform 2d side-scrolling retro game in Cocos2d-x v3. The engine is rather new to me, but I do have decent experience in C++, Xcode and game development.
The game which I’m trying to create is utilising super minimal pixel art and I’m at a loss as to decide which approach would be best. Currently I have two ideas:
Work with a fixed resolution (e.a. 240x120, I’m working with
really(!) small sprites) and use Design Resolution to scale the entire canvas
upwards to the screen size using kResolutionNoBorder.
Pros: I don’t have to scale my sprites and I can just use a short piece of code in the Init() function.
Cons: Not sure if you can use Design Resolution to scale pixel perfect?
Scale every sprite so that it appears to be running on a ±240x120
resolution.
Pros: ?
Cons: I have to scale every sprite which means more code and less clarity as to what is really happening on my canvas.
I read the multi-resolution-support page on the Cocos2d-x wiki, but it didn’t really give me advice on what would be the best approach for retro games.
I feel that I don’t have enough knowledge about Cocos2d-x to make the right decision yet, and a voice in my head says I’m forgetting something important.
There are more factors at play. How do want the game to look that are diffrent from 240*120.
I'll suggest scaling the screen for pixel art games. You can also control aliasing/anti aliasing param for all texture. Generally for pixel game, anti aliasing is turned off.
KResolutionNoBorder might crop your game edges to fit it in. There are other options,like kResolutuonFixedHeight, kResoltuionFitAll, depending to game requirement and HUD placement.
Well, it still can look pixel perfect in large screen, cocos2dx uses float for the size and position, so even if 1 pixel in your design view is represented as 5x5 pixels on the screen, when you move the position 0.2 point it will look like it moves 1 pixel. How precise it can be depends on the device screen resolution.
I would go for scaling the canvas
I'm trying to make a program that handles graphics and I am not quite sure how to implement zooming. I have done a zooming effect with primitive shapes such as lines and circles (with SDL_gfxPrimitives) by scaling them down but that wont work for a picture. How would I implement zooming?
There is a SDL library that supports zooming:
SDL2_gfx Library
The SDL_gfx library evolved out of the SDL_gfxPrimitives code which
provided basic drawing routines such as lines, circles or polygons and
SDL_rotozoom which implemented a interpolating rotozoomer for SDL
surfaces.
The current components of the SDL_gfx library are:
Graphic Primitives (SDL_gfxPrimitves.h)
Rotozoomer (SDL_rotozoom.h)
Framerate control (SDL_framerate.h)
MMX image filters (SDL_imageFilter.h)
Custom Blit functions (SDL_gfxBlitFunc.h)
Your question is not specific enough to produce a specific answer that is likely to get you what you appear to be looking for.
What I can offer you is the suggestion that you first come up with a way to represent zooming.
If you already know how to draw a picture, consider the fact that when it comes to computer graphics, it is almost always the case that "zooming in" or "zooming out" is nothing more than drawing your picture at a progressively larger or smaller size.
With that in mind, maybe you will begin to see that a reasonable way to represent the concept of zooming is with some form of Camera class that will unambiguously determine the size and location of the pictures you draw.
I'm building an application that is drawing an anaglyph (stereoimage) on 200 Hz screen based on two provided pictures (NOT 3D model). So speed integity of redrawing is very important. I've achieved the best results with DirectDraw surfaces and their Flip() (switching current surface's image to secondary one):
(void) lpddsPrimary->Flip(nullptr, DDFLIP_WAIT);
But DirectDraw is very outdated and I look for a way to reimplement this functionality based on modern DirectX libraries. But I really don't want to create a quad, draw picture as it's texture, calculate 3D projection matrices just to output 2D images.
I would be really greatful for any snippet of how this can be possibly done with DirectX. Thanks in advance.
For your purposes you can use DXGI and avoid D3D completely. You don't say how you get the data into the backbuffer, but DXGI allows you to create a swapchain, flip it (Present), and access the surfaces (e.g. lock them - it's called Map now). For 3D you need the "1" versions e.g. DXGISwapChain1. See http://msdn.microsoft.com/en-us/library/windows/desktop/bb205075(v=vs.85).aspx.
Note that DXGISwapChain1 is a subclass of DXGISwapChain, and some vital methods such as GetBuffer are in the base interface.
I guess I'll illustrate with an example:
In this game you are able to draw 2D shapes using the mouse and what you draw is rendered to the screen in real-time. I want to know what the best ways are to render this type of drawing using hardware acceleration (OpenGL). I had two ideas:
Create a screen-size texture when drawing is started, update this when drawing, and blit this to the screen
Create a series of line segments to represent the drawing, and render these using either lines or thin polygons
Are there any other ideas? Which of these methods is likely to be best/most efficient/easiest? Any suggestions are welcome.
I love crayon physics (music gets me every time). Great game!
But back to the point... He has created brush sprites that follow your mouse position. He's created a few brushes that account for a little variation. Once the mouse goes down, I imagine he is adding these sprites to a data structure and sending that structure through his drawing and collision functions to loop through. Thus popping out the real-time effect. He is using Simple DirectMedia Layer library, which I give two thumbs up.
I'm pretty sure the second idea is the way to go.
First option if the player draws pure freehand (rather than lines), and what they draw doesn't need to be animated.
Second option if it is animated or is primarily lines. If you do choose this, it seems like you'd need to draw thin polygons rather than regular lines to get any kind of interesting look (as in the crayon example).