Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Feb 2007
Offline Last Active Yesterday, 12:26 PM

Posts I've Made

In Topic: Why C# all of a sudden?

26 September 2016 - 05:06 PM

Slightly off-topic, but apropos of C++ overhead compared to C, the things that a modern C++ compiler can do with well-written C++ (that is, code that takes care to give the compiler the full and correct context of the code) is just amazing. Correct use of const (and volatile), constexpr, inlining, and templates, together with idiomatic code that's simple rather than clever give the compiler tons of information it can use to make the best possible decisions. Armed with that knowlege, a compiler can entirely optimize away many or most of its "expensive" features, deeply-recursive functions, and more.


A case in point: Rich Code for Tiny Computers: A Simple Commodore 64 game in C++17


It may have been more true in the past, before C++ compilers got really good, but these days the argument that C is somehow fundamentally faster than C++ is no longer true in the general case. C had a reputation for being faster because the compiler simply wasn't doing a lot of work for you in secret, compared to C++ compilers which do; when C++ compilers were immature they sometime did this secret work more poorly than a C programmer could role their own equivalent, but now that C++ compilers have matured a great deal and become very good at doing this secret work, the C++ programmer can unlock that potential by writing good-quality C++ code for a much lower cost than what the C programmer would have to endure.

In Topic: How to handle 2D tiles with different sizes

26 September 2016 - 04:21 PM

First, if you have a large number of tiles of one particular size that are in a regular grid (for example, the tilemap itself), keep that separate if you've already got an efficient way to handle that. If you're mixing all these map tiles into what are probably a much smaller number of odd-sized sprites/tiles, then your problem is really that you're paying the high cost of your search-a-single-list approach for probably several times as many graphics as you need to. You only want to pay that cost for the items that you don't have a better solution for.


A quad-tree or similar spacial-partitioning system is the general approach and if you have a fairly even mix of tile sizes and such it might be the best fit. But it comes at some complexity -- for example, if a movable image like an NPC or enemy moves between partitions, you have to update those lists. Its not especially hard, but other solutions are simpler if you don't need the full generality of that solution, and if the number of odd-sized/non-gridded objects is relatively low.


Sorting your list in various ways can help too, so that you don't have to iterate the entire thing every frame. For example, you could sort the entire list based on distance to the viewport, and decide on some larger-than-the-viewport distance that includes the entities you need to consider every frame. Now, you iterate through only those "near" objects every frame, and periodically you resort the whole list -- maybe once per second. You don't even need to do a full sort, you just need to partition the list into 'near' and 'far' parts -- in C++ that would be std::partition or std::stable_partition, but I'm not sure what the best C# equivalent would be.


Some other implementation details to be aware of are:

  • You don't want to literally move the list contents around if they're expensive to copy, you'd probably want to sort a list of references. In C# this is probably already taken care of, just be sure you know about how structs/classes differ. In C++ this would be an issue you'd have to deal with yourself, either by sorting through a list of references, or possibly by making the objects cheap to move.
  • You probably don't care about the *actual* distance for this sorting, so save yourself the cost of a square-root per object by just squaring the threshhold (once) instead. You'll get the same order/partition out regardless.

In Topic: Alternative to DirectX and XNA?

23 September 2016 - 06:05 PM

I'm primarily a C# guy anyway so that would be my first choice, but I think it's probably fair to say the game industry is  still C++

I live around 60 seconds away from Epic and they're still using C++. I'm not going to walk in there and get a C# job anytime soon LOL


You might be surprised. Yes, C++ is for now and in the future the go-to language for developing the guts of the game, but at the same time its becoming less and less the go-to language for writing gameplay code, tools, network services, and other things. You can be certain that Epic has members of its staff writing code in C# right now -- not the guys responsible for the guts of their engine, no, but others for sure. Probably a significant number of them. IIRC, Unreal 4 is not C# scripting like Unity is, but C# is not an uncommon choice for scripting languages in other engines (probably being second to Lua).


It really depends on what you want to do. If your interest is tools, online services, or gameplay then C# skills can absolutely land you a job. If your interest is rendering or other core engine systems then C++ is probably the right bet, especially if you want to do bleeding-edge technology. If you're content making games that aren't bleeding edge, a good number of people and studios are making those in C# now, and have been for years -- and I'm not talking ultra-casual, simple games. You can quite handily create a game in C# today that's to the standard of contemporary AAA titles.


If advancing your C++ skills aligns to your goals, then by all means use it. If its your preference, use it. If you're choosing it for whatever your own reasons are, use it. But don't use it just because you think its a hard requirement now or in the future, because that's becoming less and less true except for the niche of developing the game engine systems themselves. I love C++, and I'm a low-level kind of guy myself, but its really not the only gig in town anymore.

In Topic: Alternative to DirectX and XNA?

23 September 2016 - 12:14 PM

XNA was a really unfortunate and premature casualty. Killing it counts among Microsoft's significant blunders, IMO. Thankfully Monogame has picked up that torch, and is well-supported on all platforms -- the Xbox One is getting its first Monogame title, Axiom Verge, very soon.


DirectX isn't going anywhere. You no doubt have heard of Direct3D12 and Vulkan, which are great and are the way forward long-term, but Direct3D11 and classic OpenGL aren't going anywhere. They're not dead, they're not dying. We're just getting more options.


Then you have other frameworks like Cocos2D, SFML, SDL 2, and more, as well as cheap and readily available commercial game engines like Unity, Unreal Engine 4, Lumberyard, Gamemaker, and even specialized ones like RPG Maker. All of which can be and have been used commercially.



For C++ I'd probably recommend you look into SFML, SDL 2, and Cocos2D, go through some tutorials and then choose the one you like best. For C#, Monogame is pretty great, and put aside any silly notion that "real game programmers" only use C++; unless learning C++ is an explicit goal or you already have *serious* C++ skills, there's little reason to choose it over C#, and you're giving up a great many productivity advantages of C# in doing so.

In Topic: Why C# all of a sudden?

23 September 2016 - 11:58 AM

C# is a rather ergonomic language coupled with expansive, inter-operable libraries and generally great tooling. It performs well enough, and even though highly-tuned C++ will never lose to even highly-tuned C#, a great deal of typical code will never receive that kind of attention -- in many non-gaming applications, perhaps no code at all gets that kind of attention. I would argue that non-performance-critical code created by a typical C# developer is cleaner, more maintainable, and makes better use of libraries than the typical C++ developer likewise creates for non-performance-critical code. I would further argue that the C# developer can do it in less time and be within a reasonable margin of performance, even winning in some cases. I would note that idiomatic use of the latest C++ language/library features can mitigate, or perhaps even overturn that relationship, but almost no one is really embracing that yet and there's a ton of legacy C++ out there that's difficult to move off of the old idioms. CPU cycles aren't infinite, but they're abundant and cheap -- If I've got more cycles available than what I need, its perfectly reasonable to spend some of  them on my own improved productivity as a developer.


Neither language is going anywhere though--C++ stalled and even retreated a bit during the period between about 1998 and 2011, but the recent standards work has put its prospects on a steeper upward trajectory than ever before. That's not hyperbole, that's what the stats and trends are showing. Recent and upcoming standard advancements have really made it a better language.


C# is doing similarly well -- .Net Core and the open-sourcing of pretty much all of the C#/CLR/.Net Framework ecosystem is going to make for a better future too. Its effects are already feeding into Mono, Unity, and in other ways. All the desperate .Net implementations are moving towards parity, if not unity.


And its not zero-sum -- a rising C# isn't going to cannibalize C++ entirely, nor is a renewed C++ going to cannibalize C# entirely. They'll each be given as much work as they're fit for, and there's plenty of work to go around. Its a symbiotic relationship when you think about it -- A competent C# allows for C++ experts to focus their attention where its most beneficial, expands the hiring pool, and has allowed people and teams to create a wealth and variety of games that never would be created with C++ because the expertise or efforts required are too high a hurdle.