Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 06 Oct 2010
Offline Last Active Yesterday, 01:00 PM

#5188303 Spritebatch With SharpDx

Posted by Starnick on 21 October 2014 - 08:01 AM

It looks like you're not specifying a Viewport to the device context. Aside from needing to define a viewport, SpriteBatch will internally use that to create a projection matrix as input for the sprite shader.

#5170410 will you buy this?

Posted by Starnick on 30 July 2014 - 12:41 PM

The problem is you're trying to write a one-size-fits all solution for an application. Not just a library that loads a model (like Assimp) but also gets it on the screen, so you're locking in users into how things are formatted and function. Basically you're offering a platform, which can be problematic if a user wants to do something different. And you aren't going to get buyers unless if there are a lot of features that sets it apart from free/open source competitors.


I think you'd do better if you wrote plugins (for profit) for an already established and mature platform. E.g. write something useful for Unity and sell that.

#5164373 How to transition into Game Dev with Java

Posted by Starnick on 02 July 2014 - 01:02 PM

Edit: Java is not a language to use for large scale 3D games. Attempting to render complex 3D shapes with texture mapping and lighting can bring your game to a screeching halt.

 (( Java is a perfectly fine language to use for 2D MMOs, and non graphic intensive 3D games ))


Eh, I wouldn't worry too much about "rendering complex 3D shapes and texture mapping and lighting", and so on as that's going to be hardware accelerated. It's not like your choice of language is going to greatly impact that.


The biggest pain point in my opinion is the lack of structs in Java. All your math "objects" are exactly that, objects allocated on the heap. So you're going to have to worry about allocations during updating/rendering (gotta be smart about it, e.g. extensive use of pooling). Then of course concerns about performance with a managed language where code is being JIT'ed on the fly. Certainly not going to get the performance of native in that regard, but that doesn't mean you can't do serious graphics programming. Far from it!


If you want a more comprehensive package, jMonkeyEngine is a good platform. I used to use it back in the day, but they've made some big strides the last time I used it (or used Java...heh I'm mainly a .NET developer and personally prefer using C# over Java and Direct3D over OpenGL, but that's me). It has a lot of stuff out of the box, so you may not be finding yourself right from the get go doing complex low-level stuff (or writing shaders).


But if you really want to learn graphics programming I would go with the low-level wrappers around OpenGL or Direct3D (although, are there any D3D wrappers out there for Java?) such as LWJGL. And like Glass said, search for "Modern OpenGL", e.g. programmable pipeline.... --> OpenGL Bible 6th Edition. There's a plethora of tutorials and material out there that use fixed function, which at this point is legacy, so it can be confusing and overwhelming when first starting.

#5144348 Is the era of C# for game programming gone?

Posted by Starnick on 04 April 2014 - 07:52 AM

And....apparently SIMD is coming to .NET:




Microsoft's new 64-bit JIT compiler....


Sweet jesus, I think I might faint from the excitement!

#5144154 c# loop

Posted by Starnick on 03 April 2014 - 11:34 AM

I disagree as well, google is a fine tool to answer such a question. Maybe take issue with the "let me google that for you", but honestly it's kind of annoying to see a post like this with a bunch of smileys, please help me I'm new, when you could very well have find the answer by googling the topic title alone.


Sometimes a great search tool however is useless when you don't know what to search for. So to that I say, a better question would be "Can the community recommend some good resources to learn C#?". The definition of a basic construct like a loop is going to be covered realitively early in a beginner's guide on programming. And to that, I answer:


The official Microsoft documentation on MSDN is always my first go-to resource. Mostly about framework API docs, but they also have programming guides and other resources, e.g the C# Programming Guide




If you prefer a book, C# in Depth by Jon Skeet sometimes gets referred:




I don't know if that's a right fit for an absolute beginner though, probably more for someone who knows programming but not C#, but there are a ton of tutorials (and other absolute beginner books) all a search result away.


Consequently, I used google for those links. But I knew what to search for ;)

#5144094 How to communicate between c++ and c#?

Posted by Starnick on 03 April 2014 - 07:58 AM



Use something like SWIG as Colin mentioned, it basically is automatically creating bindings for you. Personally I don't like added dependencies.


What dependency are you talking about? AFAIK swig does not add any runtime dependency to your bindings, it's just a tool that you can drop in your project folder, you can even invoke it automatically whenever you rebuild your c++ project and have always up to date bindings. (note that I only used swig for python bindings, not C#).



Sorry, meant a project dependency on a third party tool in general. Not runtime dependencies.

#5144078 How to communicate between c++ and c#?

Posted by Starnick on 03 April 2014 - 06:54 AM

Your options are pretty much:


1. Use something like SWIG as Colin mentioned, it basically is automatically creating bindings for you. Personally I don't like added project dependencies.


2. Use C++/CLI to talk directly between your core and your GUI platform. This isn't so bad, but does introduce essentially a third language with its own syntax that is different from C++ and C#. We do this at work (our apps are a blend between native and managed, and we have a lot of C++/CLI going on).


3. Write a C-API to essentially wrap your C++ objects, then use P/Invoke to call those. How much interaction is really going to go on between your core system and the GUI? A small C wrapper to call into probably is enough.


4. COM as DvDMan mentioned...which I wouldn't do for this, the above solutions in my opinion are more desirable.



Personally I'd go with #2 or #3 (leaning on the latter since it doesn't require learning anything new from what I presume you already know), if you wanted to write your core system in C++. But honestly, if I was doing this, both the core system and GUI would be all C#. E.g. use SharpDX for graphics.

#5134318 How to get good fast?

Posted by Starnick on 24 February 2014 - 09:53 PM

FYI I read the "its plain" as "its pain" lol. The road is painful in the sense of the amount of time and energy you need to spend on honing your skills. I too like the painter/craftsman parallel, as that's how I see software development in general. Something you hone over many years, and really never stop refining. There isn't anything "fast" about it.

#5132120 Is C# still worth learning for game development now that XNA is dead?

Posted by Starnick on 17 February 2014 - 02:12 PM


XNA was not the only option for doing graphics programming in C#. SharpDX is currently the prevailing Direct3D wrapper (MonoGame uses it under the hood, as well as one of the openGL wrappers). For OpenGL there's OpenTK, although I don't know if that's been keeping current. There's also SharpGL, but I can't comment much beyond knowing it exists.[/quote] 




OpenTK is very much alive, it just had a new release that added OpenGL 4.4 and a SDL2 backend.



Good to know. I see you guys pushed out OpenTK 1.1 officially just yesterday, what timing :)

#5131912 Is C# still worth learning for game development now that XNA is dead?

Posted by Starnick on 16 February 2014 - 09:45 PM

XNA was not the only option for doing graphics programming in C#. SharpDX is currently the prevailing Direct3D wrapper (MonoGame uses it under the hood, as well as one of the openGL wrappers). For OpenGL there's OpenTK, although I don't know if that's been keeping current. There's also SharpGL, but I can't comment much beyond knowing it exists.


Or if you're crazy enough, just write your own wrapper to call into OpenGL or Direct3D with P/Invoke or C++/CLI. Although I would just recommend SharpDX, if you were interested in XNA (MonoGame if you want an API like XNA). However, don't go and assume that C# was relevant only because of XNA, because XNA is just one library. It's a very good language to know and use, whether it's a game you want to develop or something else.

#5122004 3D Lines with directx

Posted by Starnick on 07 January 2014 - 03:18 PM

Since you're using D3D9, you probably can use the D3DX line support. But really, thick lines are just a polygon strip (can be known as a "polyboard") that follows your polyline and which is oriented to give the impression that there is thickness (kind of like how particle effects traditionally are done).


Mathematics for 3D Game Programming and Computer Graphics by Eric Lengyel has a section describing the technique and math behind it.



#5118163 Model import adventures

Posted by Starnick on 19 December 2013 - 11:04 AM

So I'm confused by what you mean by updating SharpDX. The current released version should already have animation support. Are you modifying that? Or adding your own animation support? And what do you mean by displaying incorrectly? It may be something simple if more information is provided.


I would bet money that its the exporter or Assimp's collada importer (not unheard of). Certainly can't be AssimpNet cool.png (kidding...kidding!). Potentially, given to how the data is constructed, some post-processing flags need to be set that SharpDX isn't setting.


So while I'm thinking that I started to wonder - is there any data formats/ techniques, where you can get something like what you would call "intermediate runtime data format"? Something like .NET's msil that can be used to compile for different processors, but describing some memory data structure for different languages instead of processors?


I would imagine it work something like code and similar to XML+XML scheme. I would have something like XML scheme, that describes the constraints, but also includes support for references and typed data structures, I would have a language specific runtime type/class code generator, that makes runtime code/class from scheme. Then, given *ANY* scheme, any file that is written alongside this whole thing, and a file, that is a running instance of that scheme, I would just need to do 2 steps, that would not change for ANY model (or anything, for that matter) format, written in this way.


1. Generate language specific object/parser/whatever from any given scheme. Input universal scheme file -> Output code file containing language specific implementation of that scheme.

2. Initialize that object in runtime in trivial manner such as loading it from disk using common Load method (interface) available in all schemes.


Interesting, although I think you're basically describing (yet another) model format like collada and an overly generalized run-time component that people may find unusable if they want to do stray off the beaten path and do their own thing (often the problem with frameworks that "do everything" for you). Format's are only going to be as strong/useful as the importers/exporters that are available, and just because they are claimed to be interchange doesn't make it a standard by any means. And you're basically proposing a runtime component a la Assimp (which I'm sure exist out there), I could imagine a C-API that can be hooked into by different consumers...but I just have to ask, why? One size doesn't always fit all.


Content pipelines are inherently difficult, large parts of it can be generalized and componentized such as Assimp, but my opinion is once you're crossing into something very application specific (in the sense, it's specific to *your* application), trying to framework it or standardize it to be consumed by others is most likely going to turn out to be half baked for all parties. SharpDX's runtime model stuff is analogous to XNA's, it's a great generalization that can get the majority of users going and happy, but it's certainly not a catch-all nor was ever intended.

#5108358 DX11 - Updating global buffers?

Posted by Starnick on 10 November 2013 - 04:47 PM

The $Globals constant buffer is not anymore special than the ones you explicitly declare, it'll show up through the reflection interfaces (probably always index 0). So if you already have a scheme going with querying meta data, and updating buffers with your variables, it's the same exact procedure.

#5108345 which platform? which language?

Posted by Starnick on 10 November 2013 - 03:07 PM


4. Unlike Java, it's really easy to do unmanaged-to-managed interop, so it's a lot easier to use that native library you see your eye on.

Sorry to hijack the thread a bit but I wanted to ask this to a C# dev.


In Java making the JNI work is a bit of a mess, though there are utilities/libs made to make it easier (like Java Native Access ).


I've heard that its much easier on C# but someone made the point that its easier as long as you're on .NET world, that working with native libraries in Mono isn't as easy. Adding to that, you'd need to write Mono specific code, and .NET specific code.


Whats your take on that?



JNI is an absolute beast to work with and was one of the reasons why I jumped ship from Java many years ago (before JNA, which I believe is modeled after C#'s P/Invoke). In C# you have a few ways of calling into unmanaged code using P/Invoke, either through static DLLImports or loading the unmanaged DLL (e.g. LoadLibrary) and marshalling function pointers to managed delegates. These require the unmanaged library to have exported functions. Otherwise you would use C++/CLI (or do something extraordinarily fancy like SharpDX, which unlike SlimDX is not written in C++/CLI, but straight C# and with much of the interop generated at the IL level, or something like thatTM).


C++/CLI interop is a no go for Mono because they don't support it at all. So that's probably where you'd be writing specific code for different platforms. For example, say you want to use a library that you need to link to. You may have to write a C-API around it, then P/Invoke into that wrapper from your C# app. Honestly, I don't think this is a common use case.


For static DLLImports there's the issue of handling how library paths are found and library naming, which they have a mapping solution for. And obviously, if you're P/Invoking into kernel32 functions, then that isn't going to fly for a non-Windows platform (honestly, that's a non-issue in my book, if you design your application for platform flexibility).


Compared to JNI, P/Invoke is "easy" using static DLLImports, you declare the native function like so:

[DllImport ("MyLibrary")]
private static extern void Frobnicate ();

And then call it like you would any other. Easy is of course in quotations, because getting the signature right can be tricky for some functions. And ensuring data is marshalled correctly across the managed-unmanaged boundary is sometimes not trivial (but the runtime does offer a lot of support to get the job done).


A real life example would be my AssimpNet library. The native Assimp library is cross-platform already and exposes a C-API. The C# wrapper uses that second option I mentioned rather than straight up P/Invoke exemplified above - the native library is loaded dynamically at runtime and unmanaged function pointers get marshalled to managed delegates that you call to communicate with the native library. The loading scheme has different implementations for Win32 and Linux, which automatically are chosen depending on the runtime environment. The platform implementations, for example, P/Invokes into kernel32 or libdl functions to load the library/free it/do error reporting. So it's for whatever platform-dependent functions that need to get called outside of the Assimp library.


Of course, the sticking point in this is it doesn't work on iOS apparently (as reported by a Unity3D user), because you can't dynamically load DLLs or something, so they're still using an older version of the library which used static DLL Imports for the P/invoke. I'm digressing, but the point is interop is hard and tricky, but C# offers a lot of nice solutions where you don't go bat-crazy and want to pull your hair out just to do some simple interop.

#5108297 which platform? which language?

Posted by Starnick on 10 November 2013 - 09:58 AM

Honestly, I'm biased because professionally and personally I'm a C# developer, but I think it's a really good language to get into, especially if you're starting out. Reasons why:


1. Clean, modern syntax.


2. Learn C#, then it's not that hard to go to Java, or C++. Same can be said of those other two, I guess. But certainly better than learning Flash or BASIC, especially if you're interested in getting into general application development.


3. Unlike Java, you get more flexibility when dealing with memory (value types, non-heap allocated objects)


4. Unlike Java, it's really easy to do unmanaged-to-managed interop, so it's a lot easier to use that native library you see your eye on.


5. Unlike C++, the memory model is a bit easier because its managed, but of course you lose flexibility as a consequence (doesn't impact a beginner in my opinion, in fact quite the opposite! More apt to blow your foot off).


6. Like Java, C# has a rich standard library to draw upon.


7. .NET is limited to Microsoft platforms (Windows, and windows derivative). There is Mono, the open source implementation of .NET, as well as Xamarin which gets you Android and even iOS.


I'm not a game developer, I work on CAD products, which we use a combination of C++, C++/CLI, and C# (I lean more to the managed side of things on that spectrum). And in my own time, I use C# for graphics projects. So in my opinion, it's a great language for games, graphics, general applications, what have you.


Also since you're a beginner, I highly recommend starting small and sticking to one thing. Saying you want to develop for pc, for web, for mobile, etc can stretch you too thin where you're chasing too many rabbits and you wind up not learning a whole lot. I would stick with just one platform - PC, to gain experience in how to put together an application, then branch out. Especially if you're interested in general application development.