I am implementing a simplistic GUI library for a game.
My solution uses SFML 2.1 2d API.
As you can imagine, the ui elements are organized in a hierarchical structure. Children are expected to render within the bounds of their parents.
I could live with the need to trust children to render outside their parent. However, to implement scrolling in a simple manner, I'd like to clip whatever children render.
Is there a way to achieve this using the SFML 2d api ?
For now, I could only come up with drawing to a texture and use that texture for a shape or sprite. I am concerned with performance (even though, the texture would only be regenerated when UI content changes).
Unfortunately this features isn't yet implemented, but you're not the only one waiting for it, see the first issue ever created on SFML's GitHub issue tracker.
In the meantime the only way is to either use OpenGL directly or via a sf::RenderTexture.
Related
Sometimes a Unity project has data that demands more than ordinary inspector fields and we want to create more sophisticated tools to edit the data. For example, here's a blog post about creating a node editor: Creating a Node Based Editor in Unity
It's useful to be able to create node editors, but that project draws nothing but boxes and lines and curves using the tools in GUI and Handles, which is fine for what it is, but what if we need to draw something not supplied by Handles?
For example, if we want to draw an elaborate mesh to represent some data that we want to be able to edit, it seems not ideal to render each individual polygon of the mesh using Handles.DrawAAConvexPolygon(...). Shouldn't we instead have a way to more directly send the mesh to be rendered? Or is DrawAAConvexPolygon exactly what we should be doing?
Is the GL class the appropriate approach when wanting to draw arbitrary meshes in an editor control? It is certainly capable of drawing, but is it bad practice? In particular, the GL.Viewport(Rect) method seems to work very strangely within a GUI. One cannot simply give it a GUI Rect and thereby have a viewport in the same place we'd have a GUI control if we gave it that same Rect. We need to calculate the Rect that will put the viewport in the appropriate place, and even then we have to determine the coordinate system within the viewport. Based on the documentation for Viewport(Rect) one might expect the viewport to be (0, 0) to (Screen.width, Screen.height), but it does not always work out that way exactly, and it all gives the impression that GL is not designed to be used within Editor GUI. The documentation for GL.Viewport has it used in an OnPostRender method, so is it misguided to try to use GL in other places?
If we should not be using the GL class, then what is the technique for drawing within custom Editor controls?
You may wanna look at Unity Graph view if you want to make a Node Based Editor in Unity.
It use UXML and USS with is close to HTML and CSS.
Making it pretty easy to customise as you wanted.
Unity Video on UXML and USS: Customize the Unity Editor with UIElements!
https://www.youtube.com/watch?v=CZ39btQ0XlE&t=98s
Here are 3 Github you can download and look at.
https://github.com/rygo6/GTLogicGraph
https://github.com/rygo6/GraphViewExample
This one is made by me.
https://github.com/KasperGameDev/Dialogue-Editor-Tutorial/tree/Dialogue-Prototype-Bonus
I currently have a WinForms C# application. I have a .txt file with GPS coordinates of some points (borders of buildings, roads etc.), and using Graphics.FillPolygon method in System.Drawing I am drawing these on a Panel. However, I got an idea that for what I am trying to do (it basically is a 2D game), a Unity 2D project would be more suitable and easy to use (mainly because of easier view handling using the cameras). However, I don't know how to do this drawing in it. I just need to somehow get these coordinates drawn in Unity, but I don't know how to do it.
Note: I already have some minor expirience with 3D in Unity, but I am a total newbie to 2D.
Thanks
There is no GDI/canvas implementation built into Unity. Drawing these in rastered 2D would be quite hard in Unity (basically putpixel level, or finding some third party library).
You have an alternative, though - you can draw these shapes in 3D, ignoring the third dimension. You have a few methods for this:
Line renderers - this one will be the easiest, but forget about anything else than just drawing the outline, no fill etc.
Make your own mesh - This will let you use the geometry with your scene. It's an retained mode API (you init your geometry once)
Use the GL namespace - This will be only rendered on the screen, no interaction with the scene. It's an immidiate mode API (draw everything on every frame)
If I'm looking to create a game that doesn't necessarily run full screen, but simply needs to feature 2D/3D graphics somewhere in a portion of the screen, what's my best approach?
Some specific questions could be:
What component would the rendered area use?
Are there any game libraries I could leverage for the rendered area?
What would be the most "pure" or "canonical" stack according to Microsoft to use here?
Omega --
Visual Studio 2010 and 2012 are Both WPF apps. WinRT is for Tablets / Mobile. WPF is certainly NOT outdated.
If I were you I wouldn't render everything out the way canvas forces you to, it might be a better approach to have the center item be a UI element named Frame, which is the base element for all UI related content in WPF.
In this way you would be able to leverage all of the possible types of controls in the Frame whether you decided that An ImageSourceType or Canvas is more applicable to a particular features of the game.
Depending on how you want to draw graphics, you could use (but are by no means limited to):
Canvas - which would be totally appropriate for slow moving games. This way you get the benefit of the various WPF layout routines and can define objects inside the scene in XAML/vectors as well.
WPF supports 3D graphics (using Direct3D on the backend) so you could probably set up an orthogonal projection matrix and treat it like a Direct3D context (with the WPF API). I don't have enough experience to know how slow this is compared to D3D, but it's certainly easier (built-in "scene graph" like support from the XAML architecture, for instance).
If you want to go whole-hog with Direct3D you could use SlimDX, which has a WPF shim that I've used in the past, as well as another third party control. There may be other libraries available as well.
Direct blitting to/from a Bitmap using WriteableBitmap (see WriteableBitmapEx for a third-party version with a much friendlier API) or similar.
There are probably a lot of other options too. My preference would be for using Canvas initially if it's a slow-paced game that doesn't need super-fast frame rates (the layout work does incur a fairly substantial overhead, but it's less work and may be easier to get looking exactly the way you want).
If you want absolute control and speed, use D3D through SlimDX, but this is a pretty hefty learning curve if you're new to it.
I am trying to achieve a simple task (or so I thought) in XNA 4.0. I have objects that need to glow (rendering and Gaussian blurring them and then adding them to the main scene). These objects can be at different depths so I will need to make sure that they are obscured by objects in front of them in the main scene. It's 3D.
Because depth buffers cannot be re-used in XNA 4.0, I am having a hard time figuring out how I can achieve this?
I can find no examples or tutorials or explanations of this process. The bloom post process example of XNA also does not do exactly what I need, as it post processes the entire scene.
I know that I can preserve RenderTarget info by using PreserveContents, but it sounded like it was slow. Is there a way to achieve this without using PreserveContents?
Any help would be appreciated.
Thank you,
Riaan.
I'd try to render the glowing objects using a second rendertarget to store its depth... this is a multi target rendering technique...
I suppose that you will need another for the non glowing objects..(or use the same, storing both depths with an addtive blending) to compare them at postproccess time...
later in the post process it would be possible to know if the glowing object is visible or is hidden.
My goal is to gain a better understanding of the characteristics of C#, and become more comfortable creating simple apps. I am fairly competent with Flash (Actionscript 3), and found an old Tic-Tac-Toe game I'd written. I started wondering about porting this code into a C# application. Not knowing much about C#, I'm wondering how difficult the migration would be.
On the one hand, the underlying game logic is syntactically similar, and therefore would be easy to port.
However, as far as the graphics are concerned, I don't even know where to begin. So far, I've only exposed myself to Windows Forms and Console apps in C#.
I'm wondering if these Flash concepts have similar analogs in C#, or if the procedures and syntax are radically different:
Placing graphic elements on a stage
Rendering lines from start/end coordinates
Event listeners on movie clips
Swapping the image inside a graphic element (or, in my Flash version, nextFrame() in a movie clip)
You may want to try developping your little game using Silverlight. Silverlight applications, coded using C# and Xaml, are pretty similar in form with flash applications, and you should find everything you need without trouble.
So I suggest you download the Silverlight SDK (free) and give it a try.
Firstly, Flash is to WPF (close enough) as ActionScript is to C#.
The WPF/Silverlight model is much more similar to Flex that it is to Flash. Everything is added to the UI tree as a object, even lines.
Likewise, adding event handlers to controls (like a button click) can be done in the "code behind" (the code that lives with the view), but the recommendation is to use the MVVM pattern. If you are new to the concepts of separation of concerns and unit testing, feel free to start with the simpler "code behind" method.
While WPF and Silverlight are very similar, I'd recommend starting with Silverlight as the SDK and available samples are richer. You can easily move onto WPF later on (though porting an application from Silverlight to WPF is not automatic).
Swapping images, as you mentioned, would be done via "Visual States" in Silverlight (or possibly changing the image reference, which is more "hacky").
Have a look at the following links to get started:
Learn # Silverlight.net
Silverlight on MSDN
Shapes and Drawing (Silverlight)
If you're looking specifically to do games and the like, you may wish to look into the free XNA framework. However, there will be differences as Flash gives you far more ability to "set up" things beforehand and modify them.
Placing graphic elements on a stage
If you go the XNA route, you will be drawing sprites using the spritebatch, you tell them where and how to draw and that's where they will go
Rendering lines from start/end coordinates
In windows forms you can do this via a simple System.Drawing call, however if you wish to do this in XNA, you will either have to make a 1 pixel square and stretch/rotate it to what you want, or use 3d primitives (Though this will limit you to a 1 pixel line)
Event listeners on movie clips
Look into delegates, but there isn't really an equivalent for movie clips to my knowledge
Swapping the image inside a graphic element (or, in my Flash version, nextFrame() in a movie clip)
This is fairly simple, depending on what you mean. If you want to, say, animate a sprite. You can do this by moving the source rectangle or changing the texture of the spritesheet. If you mean the screen as a whole, this is mostly handled for you provided you use the spritebatch. In windows forms you'll have to do more of it yourself, but the base concepts are the same.
Overall it's not that bad, but if that doesn't sound appealing check out Silverlight. It's basically C# styled flash so you may find the transition easier.
Good luck and hope this helps.