We Keep Coding

Performance of WriteableBitmap(Ex) vs DrawingContext

I am building a custom UI framework in WPF where I basically ditch as much of the built-in layout system and controls as I can. So far I have been branching off from UIElement directly, but since I am already doing the measure, arrange and rendering myself, I am thinking I could slice off more of the WPF legacy by getting even "closer to the metal" (especially when it comes to layout / rendering). How close is it possible to get while staying in managed code and not being afraid of doing the dirty work myself?
I am toying with a prototype concept on the side now where I only have one element inheriting from UIElement: a Root object, similar to a stripped down Canvas, that "hosts" the rest of my layout engine and channels relevant IInputElement benefits into it. From that point onward, all elements would be completely custom objects not inheriting from anything in WPF, but rendering directly into the DrawingContext of Root (in its OnRender method).
Now I'm wondering about the relative performance of having a WriteableBitmap root element and manually draw onto that instead, for example using WriteableBitmapEx for convenience. Not having anti-aliasing isn't an issue, neither is a custom hit testing system.
My thoughts are primarily that WriteableBitmap(Ex) does not have the privilege of any GPU acceleration gains and therefore will be [much] slower when large areas needs to be repainted / transformed.
I do have other needs for a "pixel-based-rendering-engine-in-the-engine", though, so I am still interested in some perspective on this.
Any insights?
Edit: And what about SharpDX in this context? Maybe once I'm at it I might as well go for a WinForms solution with a DirectX wrapper like SharpDX (..or.. I guess what I really should do is sign up for the whole C++ enchilada, but unfortunately I don't have time to start learning that in the midst of things)..

WriteableBitmapEx is quite fast, even when it just runs on the CPU. It's used in this high perf charting control: http://www.scichart.com
You should also checkout Direct3D indeed. You can get really good performance, but it really depends how it's used and that most draw operations are cached and the CPU-GPU communication is as lets as possible.

What are the basics for switching from DirectX to SlimDX?

I have an old application for playing video that uses DirectX and I would like to update it and prevent the "error" of Loader lock among other things.
Can I ask what are the basic steps for converting the application? What do I have to pay special attention to?
Currently I have references in the project that point to local DLL files that I have added to a local folder. This is not a good approach and another reason for this question.
Microsoft.DirectX
Microsoft.DirectX.DirectInput

You'll need to change the namespaces to the SlimDx namespaces. At that point, you'll have to migrate some code, as some of the names are different in SlimDx vs. Managed DirectX.
That being said, the basic API calls for DirectX 9 are very similar, so the migration is not too bad once you get going.

I'm a little late to this thread, but I have used SlimDX for a year and I'm nearly but not quite finished translating my embryonic game to SharpDX (because I want to use XAML and a couple other reasons). I highly recommend both, and putting aside SharpDX's advantages (DX11.1, WinRT, XAML, some speed improvements), I would say that SlimDX is as close to managed DX as your going to get, it's equal to SharpDX, without considering those advantages that I mentioned.
I hope the point I'm making is that SlimDX is a closely mapped framework, equal to SharpDX. In that regard, SharpDX can't be recommended alone, without mention of SlimDX. And also I want to make the point that SharpDX will not minimize the migration steps over SlimDX, if that's what you're thinking. They are very similar, more similar than you think if you are of the opinion that you might fail in one and succeed in the other. If you can work it out in one, then you can work it out in the other, they are that much alike. So much alike that I wished they would rejoin as a team and work together on a unified package of frameworks. There is just too much overlap for them to be distinct projects IMO.

WPF, XNA, SlimDX ... suggestion for a CAD-like desktop application? (C#)

This is what I have to do:
To build a CAD-like application that loads a point cloud (i.e. thousands of 3D points representing a 3D object) from file, allows the users to manipulate the points (i.e. change the shape by moving the points), do a lot of calculations the points on the points (e.g. finding the intersection points between lines and surfaces, detect a point is above or under a surface etc., measure the distances between points, or points to surface etc.), and then save the modified points to file.
It also provides basic CAD-like UI features such as zoom in/out, pan the view, rotation the camera etc.
Speed is the major concern.
Instead of writing my own functions for matrix operation and defining my own point/line/surface classes, I would like to use existing libraries/APIs to do the job.
I know WPF, XNA and SlimDX provides the API to do 3D geometric calculations and all of them are finally calling DirectX, but I'm just newbie to all of them. I'm wondering:
Which one (or some other suggestion) could give better performance in speed.
My understanding about DirectX's 3D functions is that it mainly deals with gaming graphics / screen outputs, is it also suitable for data-level calculations(i.e. use the 3D functions to manipulate the point data, calculate the distances etc., but not outputting it on the screen)? By suitable, I mean if I create thousands of DirectX vertexes and mainpulate them, would it be much slower than using my own data types and structures?
Pls correct me if my understanding is wrong.
If I use WPF, do I need to use XNA as well? I'm kind of mixing up these two things.
The application is supposed to run in research lab's PC which doesn't have powerful gaming display card, so does it mean XNA is not preferred?
An suggestion about the technologies should be used for this application?
Thanks!!
========update
To make it clearer, the app will load ~108,000 points in 3D, and every points will form surfaces with other adjacent points, so roughly the the same number of 3D surfaces are involved (I'm not generating them at the same time). I will do a lot of 3D geometric and matrix calculations with the point and surfaces, such as intersection, interpolation, transformation etc. , so the speed of the "calculations" is my major concern. Most of the time I will only draw the final result to the screen and the drawing is mainly lines and points, the speed of "drawing" is not a big concern . so it is not really a graphic-intensive app, but a geometric-calculation-intensive app.
After reading the answer and comments, I think of two options:
store & calculate the data with primitive data-types, and convert data to the WPF/XNA/SlimDX data structures when drawing them on screen, or
use these API's data structures to store, calculation and drawing all those points.
which one is better?

Honestly, if performance is your
primary concern I would go with the
API that gets you closest to the
hardware. Less obfuscation = more
speed. In that case, from the
choices you've provided, SlimDX
is the best option, followed by XNA,
and lastly, WPF.
No, DirectX must use efficient data structures and algorithms. Think about it-- would games that utilize DirectX be able to run at a suitable framerate if all DirectX calculations were inherently slow?
No, WPF and XNA are mutually exclusive. WPF is a framework for creating responsive and intuitive user interfaces. XNA, on the other hand, is a framework for creating games.
Not necessarily. What it actually means is that WPF is not preferred, as WPF will offload a lot of work to compatible video cards. If WPF is unable to find a suitable video card, the CPU will take that work instead, resulting in poor performance.
As I said before, for a graphics-intensive application such as the one you have described, the closer you can get to the hardware is the better. Native DirectX or SlimDX are good options.

Have you considered developing your functionality as a plugin for an existing CAD environment?
AutoCAD, for example, has a very powerful c++ sdk (ObjectARX), it also provides a managed .NET API. You can use c# and WPF to develop your extensions. It has existing geometry libraries you can reuse.
Certainly AutoCAD has its price, but there are alternatives. For example BricsCAD. I'm not sure if BricsCAD provides a .NET api though.
Developing an application from scratch would take weeks if not months.
If I were to develop your functionallity as an AutoCAD plugin it would take me a day.
Consider if you really need to roll out own your own 'CAD' environment.

A few weeks ago, I checked out the limits of XNA. I want to know how much billboards (GPU accelarated) the engine in able to deal with. The result:
Pure XNA: 350k billboards
XNA as rendering context in WPF: 100k billboards
I do not realy know why the engine slow down when rendering to a WinFormHost control. Some debugging shows, that GraphcisDevice.Present()

Game engine development question [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am thinking of making a simple game engine for my course final year project. I want it to be modular and expandable so that I can add new parts if I have time. For example I would make a graphics engine that would be completely independent of the other systems, once that was finished I could add a physics engine etc.
I would also want to make a tool set to go with this engine. For the tools I would like to use C# but I am not sure about the libraries. My question is, if I want a C# GUI program, can I reference a library written in C++? Also would there be any performance problems etc. if I made some of the libraries in C# but wanted to use them from a C++ game.
I would like to avoid C++ as much as possible, my experiences have shown that development time can be a lot higher for a project over that of using C# or Java etc. My graphics development would be in OpenGL, this is all I have been taught. We have only done this in C++ but I have seen that projects such as SharpGL allow for the development with C#. Is there any performance issues with this. I am not looking for a blindingly fast, top graphics game. It will most likely be something simple to show my engine working. My engine probably won't be that great either as I only have a year and am working on my own.
Any advice on this would be appreciated. I am still really in the planning stages so it wouldn't be too much work to completely change what I want to do. I would just like to preempt any major problems I might have.
Thanks

If you can pull this off even under a relaxed set of goals, you're set for a great project. First, you need to get a grasp of scope:
How long do you have to work on the project?
How many people are working on the project?
If you can only create one "piece of the pie" on your own, which one would you pick? Use this to establish a working plan to make sure if you don't get as far as you'd like, you still have enough to make the work show as a great project.
A game engine is a big development task. A game engine with a toolchain is an enormous development task. In a lot of ways, choosing a smaller but more challenging task is preferable because it shows higher-level thinking about problem solving, which is greatly preferred by academics - double that if you are CS and not [Area of] Engineering. Since you are working in managed languages, things you may want to consider are:
Expressing gameplay logic (rules of the game) in a clean manner so as to provide an efficient and reliable path from designer->developer->tester. If you want, this could absolutely include the manner in which you describe the rules (Custom editor? Code API? DSL?)
Game AI has no shortage of extremely challenging problems.
Physics and graphics are interesting and I believe managed languages will eventually be used in these areas, but you may find yourself a bit more limited in your ability to solve these problems. If I were going to work in this area now, I would be trying to answer: "If I could use a managed language for writing [graphics|physics] code without hurting performance, what kinds of [language|runtime] features make the most difference in improving the expressiveness, correctness, maintainability, and reliability of the resulting programs." This goes way past simply having garbage collection and pointer safety.

You should look into XNA. It performs quite well, and from what I've heard, is quite easy to work with.
About referencing C++ code from C#: It's perfectly doable, though it will take some effort from your side to get it right. C++/CLI can work as an intermediate wrapper or you can use P/Invoke. Just remember that C++ is unmanaged and that you will need to do some manual garbage collection, which can be somewhat icky in a managed environment like .Net. Perfomance in the C++ -> C# bridge is okayish, but I'm unsure how it will perform if you need do 100.000 calls to a math-library each second. I guess a small test would be good.. I'll see if I get time to do this later today, though I somewhat doubt it :)

When creating a graphics engine (I'll only really speak about graphics as that is my area of expertise), these are a few of the choices you need to make EARLY in the project:
1) Is it an indoor and/or outdoor engine?
2) What sort of visibility system are you going to use?
3) Forward or deferred renderer?
4) How will you have animation hierarchies?
5) Dynamic or static lighting?
6) How are you going to handle transparency?
7) How will you handle a 2D overlay?
8) What mesh formats will you use? Roll your own?
Bear in mind you need a GOOD solid vector/matrix library and preferably a full maths library that will help with things from eulers to quaternions to axis-aligned bounding boxes.
Do a lot of research as well. Try to find out what the potential problems you are going to face are. Remember things like changing a texture or a shader can have HUGE impacts on your pipelining. You need to minimise these as much as possible.
Bear in mind that getting a rotating bump mapped mesh on the screen is simple by comparison to getting an engine running. Don't let this put you off. It should be no problem to write a fairly simple game rendering engine in a matter of months :)
Also ... find communities specific to this area. You will get a lot of good (though non-OpenGL-centric) information off DirectXDev. There is a fair bit of general game development algorithm information available at GDAlgorithms. There is also an OpenGL specific mailing list here.
Its worth noting that DirectXDev and GDAlgorithms, at least (I don't know so much on the GL mailing list) are populated by some VERY experienced 3D engine and game developers. Don't post up lots of "beginner" questions as this does tend to breed contempt among the members. Though the odd query or 2 at whatever level (beginner to advanced) will get amazing answers.
Good luck! I wish I'd had the chance to do this at University. I might not have gone off and joined the games industry and enjoyed an extra year of sleeping late ;) hehehe

Why do you need any C++ code?
There are already several wrapper libraries exposing OpenGL or DirectX to .NET, such as SlimDX (which, as the name implies, is a much thinner, more light-weight wrapper than something like XNA)
If you're more comfortable with C#, there's no reason why you couldn't write your entire game in that.
Performance generally won't be a problem. In most cases, the performance of C# code is comparable to C++. Sometimes it's faster, sometimes it's slower. But there are few cases where C# isn't fast enough. (However, there is a significant performance cost to interfacing between native and .NET code -- so doing that too often will hurt performance -- so the trick is, if you use native code at all, to have sufficiently big native operations, so the jump to/from .NET isn't done too often)
Apart from that, a word of advice: Don't bother writing an "engine".
You'll be wasting your time producing a big monolithic chunk of code which, ultimately, doesn't work, because it was never tested against the requirements of an actual game, only what you thought your future game would need.
If you want to experiment with game development, make a game. And then, by all means, refactor it and clean it up and try to extract reusable parts of the code. But if the code hasn't already been used in a game, you won't be able to use it to build a game in the future either.
The engines used in commercial games are just this, code extracted from previous games, code which has been tested, and which works.
By contrast, hobbyist engines pretty much always end up taking 2+ years of the developer's time, without ever offering anything usable.
The whole concept of a "game engine" is flawed. In every other field of software development, you'd frown at the idea of one vaguely-defined component doing basically "everything I need to make my product". You'd be especially suspicious of the idea that it is a separate entity that can be developed separate from the actual product it's supposed to support.
Only in game development, which is by and large stuck in 80's methodologies, is it a common approach. Even though it doesn't actually work.
If this is a school project, I'm sure whoever is supposed to grade it will appreciate it if you apply common good software practices to the field. Just because many newcomers to game development don't do that (and prefer to stick to some kind of myth about "engines"), there's no reason why you shouldn't do better.

Make sure your scope is feasible.
As a teenager I went through the build-my-own-engine phase, a few years later I realized I would have gotten a whole lot more done if I had just used pygame and pyopengl and not wasted the effort.
Check out the forums at gamedev.net.

Sounds to me like you have a pretty good plan for your project. (I get your point about XNA in your comment to #Meeh)
You can interop with C++ via P/Invoke directly or COM, you could also I guess come up with some SOA way of doing it, but to be honest as yucky as this sounds I would be inclined to target COM as your API lever of choice...why? because then you open up your API to a lot of common client language's not just C# and VB.NET you will also get Delphi, VBA, Powerbuilder etc.
Performance should not be a problem as the API entry points are just to kick of the work and transport data structures, the real work is done in your library in native code, so don't worry too much about the perf. ATL will be your friend with creating COM Classes that provide entry to your Library.

Whilst it's certainly do-able to bridge between C++ and C# (Via managed C++ is a good way to go if the interface is complex, P/Invoke for a very simple one), for tool<->engine communication I might suggest instead a network based interface. This is ideal for a high-ish level interface, such as you might want for a level editor/model viewer or such. An actual object modeller is not such a good target. What tools do you envision?
If you do it this way you gain the ability to connect to remote instances of the engine, or multiple instances, or even instances running on different hardware platforms. It'll also teach you a bit about sockets if you don't know them already.

OpenGL game with multiple entities on screen at once, what language to use?

Going to create a small game with OpenGL as a side project. Going to be a top down shooter with emphasis on large numbers of enemies (the more the merrier)
Thinking about having the resolution max out at 800x600 (for an old school feel)
What language would you recommend, is C# capable of handling the number of entities I want on screen (60-100) or should I try out C or C++ or even some other language.
Do you have any other suggestions when going for a project like this, special documentation you recommend etc.

C# is easily capable of handling a few hundred objects at once. The real speed issues come from rendering, which will not be in C# space, and possibly any computation you want to be done for each object, such as physics. Ideally you'd be using a library such as Box2D or Chipmunk for that anyway, making C# speed a non-issue there as well.
I'd personally be willing to write a game such as this in even-higher level languages than C#. C# should easily suffice.

On the scripting languages tip, consider the excellent Pygame in python:
http://www.pygame.org/news.html
Or the newer LÖVE in Lua
http://love2d.org/
For a top-down shooter both are probably excellent choices.

Have you considered Haskell, D, or ADA?
C# will definitely be able to handle a paltry 60-100 OpenGL-rendered entities on any reasonable hardware.

Generally, for a project of this scope I would recommend using whatever language you want to learn next.
Your project scope isn't huge, but is meaty enough that it would probably stretch your knowledge of the language you choose a bit. So choose one you want to get better in.

I've only ever dabbled with it but LWJGL will facilitate a Java version. All of the in-house games at puppygames.net are done in Java with LWJGL, for instance, and curiously they too are top-down or side-on blaster style games.