Jump to content
Sign in to follow this  
  • entries
    45
  • comments
    44
  • views
    51199

insights and tips on hi performance game programming

Sign in to follow this  
Norman Barrows

1312 views

insights and tips on hi performance game programming.

an excellent lecture series of 5 videos on the development of a programming language specifically for hi performance games.

By Johnathan Blow, developer of Braid and The Witness.

when you listen to the guy talk, you can tell he's done his time in the trenches.

whether you think we need our own language or not, the insights and tips alone (from Blow, C++con, Carmack, and others) seem to make it worth watching (i'm only half way through the 2nd video so far). i've already seen a couple of things i might investigate further (inlining external functions when you can, and locally scoping those you don't inline, if possible).

this is relatively new stuff, the first lecture was given live online about 3 and a half months ago.

Sign in to follow this  


6 Comments


Recommended Comments

Well, I got about half way through and I'm afraid he's not really convinced me. Everything he is proposing up to that point is so easily solved with standard library methods in C++ its a non-issue. I take his point that is memory management were more integrated into the language, it would give the compiler and debug runtime more clues as to what was going on, but is that really sufficient gain to justify a movement over to a new language?

 

I personally believe C and C++ got things right - (with a few exception) don't add to the language what can be expressed with a library. That said, memory management is so fundamental that I can see his argument for some built-in features.

 

An interesting talk anyway.

Share this comment


Link to comment

Well, I got about half way through and I'm afraid he's not really convinced me. Everything he is proposing up to that point is so easily solved with standard library methods in C++ its a non-issue. I take his point that is memory management were more integrated into the language, it would give the compiler and debug runtime more clues as to what was going on, but is that really sufficient gain to justify a movement over to a new language?

 

I personally believe C and C++ got things right - (with a few exception) don't add to the language what can be expressed with a library. That said, memory management is so fundamental that I can see his argument for some built-in features.

 

An interesting talk anyway.

 

What type of memory management features would you want to add that aren't already available in C++?  Their method for allowing you to go in and control the memory system seems fairly extensive to me already...

 

I am with you 100% about not wanting to have another language though...  there really needs to be huge gains before I would consider putting my project on an island where developers had to learn a new language before contributing!

Share this comment


Link to comment

 

Well, I got about half way through and I'm afraid he's not really convinced me. Everything he is proposing up to that point is so easily solved with standard library methods in C++ its a non-issue. I take his point that is memory management were more integrated into the language, it would give the compiler and debug runtime more clues as to what was going on, but is that really sufficient gain to justify a movement over to a new language?

 

I personally believe C and C++ got things right - (with a few exception) don't add to the language what can be expressed with a library. That said, memory management is so fundamental that I can see his argument for some built-in features.

 

An interesting talk anyway.

 

What type of memory management features would you want to add that aren't already available in C++?  Their method for allowing you to go in and control the memory system seems fairly extensive to me already...

 

I am with you 100% about not wanting to have another language though...  there really needs to be huge gains before I would consider putting my project on an island where developers had to learn a new language before contributing!

 

 

I don't personally see the need for any. I think we can do whatever we want with libraries. I just guess I'm trying to understand where the guy is coming from, and I can see his point that debugging and error output and so on might be improved if some of this stuff was integrated into the language. I'm just trying to be nice since he wrote Braid :)

 

I actually found most of his examples pretty strawman. His statement that he knew a load of professionals that would rather have:

 

Vec3 *p;

int count;

 

rather than

 

std::vector<Vec3> p;

 

makes me question the people he is working with more than question C++'s design.

Share this comment


Link to comment

I didn't even like Braid... but I'll take Vec3 *p; over stdlib any day. C is a great OLD language and C++ is just plain fugly... it's basically a corrupted old religion that says: write these meaningless words/symbols and good things will happen. A new language could be really nice. Easier to learn than a particular C++ coding style too. Fact is, every sizable project is an island.

 

I'm not planning to use Jon Blow's language.. it sounds too much like C++. I'm rolling my own : )

 

If that fails, well, there's always C++... because if you can't have everything you want, you might as well use something popular.

Share this comment


Link to comment

He places a particular emphasis on "the joy of programming", which I think is so important. Yeah, C and C++ can do all these things, but they do them in silly, unstable, outdated ways. I absolutely would jump to a new language if for no other reason than to eliminate #include and the rest of the prepocessor. It is an absolute win/win -- no more forward declarations, and compile times go way down.

 

I think we'll be forever trapped by compatibility with C (too much existing useful software), but we can make progress in a new direction with a language designed for the 21st century.

Share this comment


Link to comment

i think i depends on where one's productivity issues are.

 

for Blow, he seems to want help tracking memory errors. 

 

for me, its all about speeding up code entry. reducing the time and effort involved for me to core dump ready to compile code from my brain to the editor. 

 

i once started down the path of making my own language and compiler, but decided it was a lot of work.

 

i figured out that a macro processor that uses a shorthand syntax that translates to c++ code was the best way to go.

 

now i have my own custom language (Cscript), and all the power of c++, debugger, profiler, lint, compiler optimizations, etc.

 

being a macro processor you can freely mix c++ and Cscript commands in a single file. so you can start with legacy c++ code, and add Cscript code as you learn Cscript. and you can always fall back to c++ syntax for anything Cscript doesn't support directly. so the learning curve is very shallow.

 

and yes, the joy of programming with such a tool vs c++ is unbelivable. 

 

FYI, i'm thinking of releasing Cscript to the dev community for free.

Share this comment


Link to comment

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
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!