• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
nimrodson

Is it such possible to create fast games without using C/C++ ?

51 posts in this topic

Hi,

 

I'm not dexterous in C/C++ programming and I'm starting to think that I never will be. So, how far can I go in the game industry bypassing these programming languages?

 

Thanks.

0

Share this post


Link to post
Share on other sites
Hi,

 

I'm not dexterous in C/C++ programming and I'm starting to think that I never will be. So, how far can I go in the game industry bypassing these programming languages?

 

Thanks.


From the point of view of working in the industry: You'll probably need some C/C++ knowledge.

From the point of view of just making a game: Things such as GLSL/HLSL shaders can make a huge difference to the performance of your game, and there's no reason why a shader uploaded to the GPU from C++ will be any faster than one uploaded from javascript / C# / python. For any core language you are using, algorithmic optimisations have the largest effect on a games performance, followed closely by memory optimisations (e.g. compression etc). A game written is something like python which uses the right data structures and algorithms, should be able to perform closely to an equivalent game written in 'vanilla' C++. You may find that computation heavy code will run slower than the equivalent C++ code, although you may be able to make use of middleware to claw back that difference (e.g. using a good physics engine). The biggest win from C++ is still the ability to use SIMD optimisations. Mono.SIMD goes someway to providing an alternative (although not sure if it's really worth the effort). The only other common optimisation is to make use of multiple threads, which you should be able to use on most decent languages these days without a problem. In a nutshell, your computer has a lot of horsepower available, and so the language choice shouldn't pose a barrier to accessing that.

1

Share this post


Link to post
Share on other sites
There is also a reason why shaders are not compiled into .NET intermediate bytecode rather than native machine code for the graphics card at runtime. You would think the same reason would hold true for the game itself... Oh.. it does ;) </troll>

On a more useful note...

@nimrodson, can you tell us why you can't get to grips with C++? Perhaps you should use a higher level library (like you would generally be forced to when using C# or Java).

If you use something like Irrlicht (with C++) or Irrlicht.NET (with C#), they should both be very similar in difficulty.

(Though unfortunately like most .NET bindings (XNA included) the Irrlicht.NET is quite unmaintained.) Edited by Karsten_
2

Share this post


Link to post
Share on other sites

[quote name='Karsten_' timestamp='1357753246' post='5019541']
@nimrodson, can you tell us why you can't get to grips with C++? Perhaps you should use a higher level library (like you would generally be forced to when using C# or Java).

[/quote]

 

I just was wondering if there are another options to design powerful games without falling in C++. I don't want to be misunderstood: I like C++ (I'm still learning it), but it seems that programming on it is the only way to get fastest games. It's a question, not an affirmation.

 

By the way, I thank all the past and future feedback.

0

Share this post


Link to post
Share on other sites

As mentioned by others, any language that compiles down to assembly and isn't running in a virtual machine would do decently. C++ (and plain C) have been the industry standard for awhile because they are very cross-platform and have a few features and benefits that let you eek even more speed out of computers with minimal effort (but at the cost of making the language more complex and easier to make mistakes with).

 

The two things that make C++ in general slightly faster than other languages is (A) C++'s ideology of "Don't pay for what you don't use" (empowering developers) and (B) C++'s language specification letting compilers implement the language however they choose (letting them taking interesting shortcuts and optimizations) as long as the result comes out the same (empowering compilers).

 

If you're learning C++, I strongly suggest you research the new features offered by the newest standard of the language: C++11

C++11 makes C++ safer and easier to learn, while actually improving speed in some common situations.

2

Share this post


Link to post
Share on other sites

Personally I think C/C++ is beautiful. You haven't learned programming until you are at the hardware level C/C++ allows you to be at. Still, for a newcomer - learning C++ (or even just C) is a bit overkill. As all the others, I do suggest starting with something more abstracted (Java/Python/C#/you name it).

1

Share this post


Link to post
Share on other sites

You should use whatever you like, however it will also change what kind of jobs you can do or you can't.

 

For example you can always go down the web development road (browser, flash, html5, webgl games) and nobody will care if you can use C/C++.

For mobile games C/C++ might be important or not, it depends. If you develop for android I believe C/C++ is not really important most of the time. I don't know how other mobile OS's work with C/C++.

 

Anything desktop related, C/C++ might be a requirement.

For big studios, probably, maybe they have game play programmer positions that only require some scripting language. Tools and pipeline development will probably also possible without C/C++. If you want to go down the engine development road, chances are getting smaller.

Smaller studios might not rely on C/C++ at all, maybe you have more luck there.

 

Anyhow, it's possible to work in gamedev without C/C++.

 

Besides if you want to write a really fast game and don't want to use C/C++, you can always use Assembly. biggrin.png

0

Share this post


Link to post
Share on other sites

When I was asking this question I decided to email and 'industry veteran'. He said that when he employs people he is looking for C++ developers. As a Java coder wanting to be a game developer, this kind of gave me the urge to learn C++. In my opinion, I think C++ gives you a lot more access to your machine and code (if that makes sense) whilst Java is a lot easier to code. But, this could just be because I've been coding in Java for two or so years.

 

The only problem I ever have with C++ is trying to use external libraries. The Windows SDK sucks ass and requires a lot more code than writing windows apps in Java. I always get compiler errors from Visual C++ and it usually takes me an hour or two (3 days in the case of CUDA) to get the IDE to stop being a pain in the ass. In the case of Java, it's just referencing a single file then writing your code. In the case of C++, add a bunch of DLLs to here and here then add these include files to your compiler's include folder.... It's just a pain in the ass. I wonder if there's a way to write straight to the graphics card in C++ so I don't have to bother with any external libraries.

 

My advice would be that C++ is a good choice but if it's too hard at the start you should try an easier language and move onto C++ later.

1

Share this post


Link to post
Share on other sites
There is also a reason why shaders are not compiled into .NET intermediate bytecode rather than native machine code for the graphics card at runtime. You would think the same reason would hold true for the game itself... Oh.. it does ;) </troll>

 

Except that shaders *are* compiled into intermediate code for distribution, or distributed as source. Its the graphics card driver that takes the IL or source code and produces GPU-specific hardware instructions.

 

IL gives you portability, and sometimes that's exactly what you need. The Just-In-Time compilation technology is getting better all the time, and it can do run-time optimizations that static compilers just can't. Likewise, static compilers can do other optimizations that JIT compilers just don't have the luxury of time to afford.

 

I actually prefer C++ for most things myself, because its what I know and am used to, but its not the case today that JIT-compiled languages are so much slower than native languages that the conclusion is foregone. Native languages mostly shine brightest when you have to get down really low and control/influence exactly how memory is organized and accessed, or to employ hardware features that a language like C# just doesn't expose at a low level (say, SIMD or intrinsic instructions). In other words, the really processing-intensive, big-data kind of things. For the 90% of your game code that just deals with mundane game logic, flow control, messaging queues, etc, native code doesn't offer any clear speed advantage, and a case can be made that a C# or Java-style language (or plain-jane C++ heavy on standard library usage) is easier to write and maintain. What I'm saying is that 90% or more of your game should be optimized for maintainability, rather than performance, so you can't use that as a metric for saying C++ is the best choice.

0

Share this post


Link to post
Share on other sites

I think when people advocate not using C++ its mostly cause in their mind they see examples of bad old C++ they had seen some time ago which were done the C way (sadly even books often do this). If you do it the modern C++ way there is probably not much difference in the difficulty level to other languages, but you still have the option of doing some other things if needed for optimization later.

Other than that you would just have to download some library _of_your_choice_ yourself and then for example #include "SFML.h", instead of hoping you get what you want when doing import java.awt.*; .

0

Share this post


Link to post
Share on other sites

To put things in simple terms I guess... It's not the language you choose, It's the language you are best at. For example, Assembly is more closer to the computer, but that does not necessarily mean it will be better. It's all about coding neatly and efficiently. I know a bit of java and a bit of C++. I find that I am much better at C++ and that I get much better results with my programs in C++ rather than Java. That is just me, that doesn't mean you should not learn java and pick up on C++ . You've got to explore a bit, see what suits you. And if your looking into getting games your going to have to know multiple languages anyway. So for your first language, choose the easiest for you so you can get your feet wet. Every language has its ups and downs.

Edited by demongunsman
1

Share this post


Link to post
Share on other sites



There is also a reason why shaders are not compiled into .NET intermediate bytecode rather than native machine code for the graphics card at runtime. You would think the same reason would hold true for the game itself... Oh.. it does ;)

Except that shaders *are* compiled into intermediate code for distribution, or distributed as source. Its the graphics card driver that takes the IL or source code and produces GPU-specific hardware instructions.
I did specifically say runtime (after all, most software is distributed in text form on UNIX). Though in some of the later specs of OpenGL, apparently you can use compiled (native) code rather than compiling it up from source at runtime.

Basically, if the shaders were JIT compiled as they were being used rather than being compiled natively up front. It is highly likely you would get worse performance. This is exactly the same with .NET.
For example, Assembly is more closer to the computer, but that does not necessarily mean it will be better
Except that C compilers (especially optimizing ones) *do* produce better ASM than a human (if asked to with -S in gcc). Whereas C# simply runs ontop of another (large) layer of software so can only ever be slower. It doesn't bring anything to the table speed wise. The only thing it (ahem.. Java) brought to the table was a (flawed) non-deterministic memory management system.

You can create fast games with vm languages... Just not as fast as native code... obviously Edited by Karsten_
1

Share this post


Link to post
Share on other sites

[quote name='Karsten_' timestamp='1357766574' post='5019631']
You can create fast games with vm languages... Just not as fast as native code... obviously[/quote]

Not so obviously.

 

There is no real evidence to suggest that JIT compilers are necessarily any slower than AOT (ahead-of-time) compilers. Most current implementations are slower, but they have been steadily gaining ground over the past few years, and in many areas approaching the speed of native code.

 

In addition, several JIT languages also provide an AOT option (for example, Mono's AOT compiler, or pretty much anything targeting LLVM), which renders moot the entire debate.

1

Share this post


Link to post
Share on other sites
Basically, if the shaders were JIT compiled as they were being used rather than being compiled natively up front. It is highly likely you would get worse performance. This is exactly the same with .NET.
If you do an offline shader compile the compiler will output bytecode and so will the CreateShader functions in D3D and this is also true for CG(I don't know enough about GL to comment on it). The shader assembly spit out by these compilers is intermediate code and is run in a JIT fashion, although the driver chaches the resulting commands for future use. That compiled shader code looks like ASM doesn't mean it is directly related to it like normal asm is to a CPU's ISA.
It's up to the driver to take this intermediate shader asm and transform that in to command buffer commands.
It's also this intermediate code that the offline HLSL/CG shader compilers store in binary object files which you can quickly load from disc. Edited by NightCreature83
0

Share this post


Link to post
Share on other sites

Java's VM is very efficient and has very little noticeable difference in speed from C++. Since it is "higher level" than C++, it may prove to be a better development path for many as it can seriously speed up development time. On the other hand, if you use a library such as SDL or SFML paired with C++ you can harness the speed and the rapid development.

0

Share this post


Link to post
Share on other sites

[quote name='Karsten_' timestamp='1357766574' post='5019631']
You can create fast games with vm languages... Just not as fast as native code... obviously
[/quote]

 

Fine, so how large is the gap between games written in vm languages and native-code languages? Because if is small, why bother making games using relative complex languages like C++ (as an example of native-code language) ?

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0