There is a 3D simulation I made with helixtoolkit.wpf, but it is not effective at all in terms of performance. How can I adapt this project to SharpDX? I could hardly find any information about it on the internet. Is there a resource or shortcut you can recommend?
That would be a total rewrite. HelixToolkit and SharpDX is in no way compatible in scope.
HelixTookit is a wrapper around Wpf and provides a bunch of convenient controls and functions to easily display viewports with navigation etc.
SharpDX is a wrapper around Direct3D, so provides a much lower level access to the hardware. But you would need to write a lot of components yourself to be able to provide anywhere near the level of functionality of Helix. SharpDX is also no longer maintained, so you would spend a lot of time porting to a effectively dead technology.
As always with performance you should start with profiling. Is it really Helix3D that is the bottleneck? Or are you using it in a way that is inefficient? Before doing a major rewrite you should be certain you have explored all other options for performance optimization.
One thing you might try is to export your model to a file and open it in the windows 3D viewer, I suspect that uses the same underlying wpf code to display 3D models, so it should give a fair estimation of the possible performance.
By compact I mean one that doesn't require you to pull the entire 600+MB monster of a library with you if you only need some capture/cropping/resizing/thresholding/image arithmetic done. I know I could attempt writing that subset myself, but I don't want to reinvent the wheel. And while there are loads of OpenCV wrappers floating on NuGet, nearly all of those are bloated and/or bugged to some extent.
Ideally the subset of operations require should be determined at compile time. However, as far as I'm aware, C# compiler is unable to optimize away unused methods or classes, even under assumption of Reflection not being used. So no luck on that front, I guess.
For simple tasks like you described i would recommand using Accord.net Imaging library from NuGet http://accord-framework.net/docs/html/N_Accord_Imaging.htm,
very good performance and easy to use, also check out all of Imaging.* namespace http://accord-framework.net/docs/html/R_Project_Accord_NET.htm
Good luck!
Have you given Emgu.CV or OpenCVSharp a try? I've used them couple of years ago and they only took like 100/150 MB (the whole installation).
The final end result(your released app e.g) usually takes much less space since not everything is used. Usually one or two DLLs are used based on one's usage of course. In my case it was like 20+ MB or so. So there is nothing monstrous here to be afraid of!
I didn't like OpenCVSharp much, Emgu.CV looked much better and mature. I guess I was using Emgu.CV.3.2.0.2721. The latest version though is Emgu.CV.3.4.1.2976
I realize someone asked a similar question here but I think my question is from a different vantage point and I hope it might help people in the future understand their options.
Basic issue: I have written a C# App (obviously managed) as a normal application (non-universal) and in order to support a quick log window above an active typing area, I initially wrote some graphics using pure .net (GDI I believe). This worked initially but it became VERY slow sometimes and I want way better control over how it looks including some specialized graphics.
What I would like to do is rework the app AND find out which of the following makes the most sense for a Windows 10 Universal Application:
Call DirectX Directly from C# (from documentation this is either not-possible or not really ideal, base project for C# does not have directX like C++ does).
Call Managed Libraries from C++ and use DirectX as the Application Foundation.
Use C++/CLI and call managed code. (I believe this is not possible anymore).
Use SharpDX (I looked and it didn't seem available based on a question here).
Use another Third Party (such as Unity) but deal with game frameworks.
Other parameters: Since everything is C# already, would like to avoid total rework, however, if it's recommended I'm 100% ok with doing so. This is not a game application, though it needs performance like one on one of it's screens, it will mostly be driven by interfaces (could be XAML) and network data coming in on a separate thread. I also have no qualms about learning extensively (say a very different language from C# or C++) in order to complete this project because learning is value. If I am missing something glaringly obvious that would be great to know about it as well.
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.
I'm involved in a development project that is using freeglut (based on the long defunct glut) for it's client.
The client will eventually allow full interaction with a large-scale 3d environment. Should I let the development continue with freeglut (is it even possible) or should I advise they use another alternative such as libsdl, opentk or even axiom.
I'm not a graphics person but I get the feeling freeglut might potentially be a limited choice.
The most convincing answer (for or against) will be accredited.
EDIT: A few points to make...
The project is already using the Tao Framework.
DirectX and XNA are not options (ie: something like freeglut or libsdl has to be used).
I did do my research and found that freeglut was once again under active development and that they have a release pending. That doesn't change my feeling that it may still be a potentially limited choice.
My question isn't on how it's done but on whether or not freeglut is still a viable choice for something that could potentially get big and whether or not there are more "modern" solutions that might ease development a bit.
EDIT: It would help if other alternatives have better mutli-threading support (not for rendering objects but for processing data and so forth).
EDIT: To elaborate a bit more... the client must work in at least linux and windows.
Thanks!
I don't think there's anything wrong with freeglut. It is being actively developed, and there is an active board for support on Nabble.
That said, it is not difficult to create an OpenGL context in Windows, so why not just use it directly? I always thought people used Glut/FreeGlut because that was what the Red Book used. (though the callbacks for mouse and keyboard do simplify things) I never timed it, but Glut always felt a little slower than using OpenGL through interop.
The Tao project has a good OpenGL wrapper if you want to use OpenGL directly. It also has nice .Net bindings for FreeGlut and GLFW, a Glut alternative which offers mouse and keyboard callbacks too.
I'd go for libsdl, its multimedia capabilities make it easier to work with audio hardware as well, it has native bindings to C# and a variety of other languages, and can also be of use if you ever decide to integrate a mobile interface for your project.
OpenGL with C# is done via wrappers. Most of them are not actively developed for anymore.
The canonical choice for 3d development with c# is either using managed directX, or using the XNA libraries.
R