Maybe the QA folks are worse off in game dev companies, but they seem to be second class citizens everywhere else too. Which is a pity, since as stated they are worth their weight in gold. A developer has a mindset of how do I make this work, a QA person has a mindset of how do I make this break - they are completely complimentary.
Thoughts on Modern C++ and Game Dev
131–140 of 143 posts
Re: Thoughts on Modern C++ and Game Dev
#132Earlier quoted context omitted.
Yes, given the graphical tooling for multi-core, GPGPU, data visualization, edit-and-continue, mixing Assembly with code (even on .NET), interaction with GUI components on WPF/UWP apps,...
At least for the Qt ecosystem, apps like Heaptrack, Hotspot, Gammaray are in my opinion miles better than what VS provides.
Have you ever used IntelliTrace in Visual Studio Ultimate?
Re: Thoughts on Modern C++ and Game Dev
#133Earlier quoted context omitted.
> That's not true. From my experience unit tests are great for agile. Not when you're constantly prototyping, which is what game dev essentially is for the most part of the process...
> which is what game dev essentially is for the most part of the process... Except that it isn't. You don't maintain the equal velocity of changes throughout the process, even for indie games. And there are always portions of the game amenable to tests.
Sure, menus and networking. Maybe loot distribution, level generation, etc.
Not so much actual gameplay though. That does constantly get tweaked.
Re: Thoughts on Modern C++ and Game Dev
#134Is Visual Studio really the best debugger? Every time I use it I get really frustrated by the difficulty of entering complex instructions. The GUI is more discoverable but I find myself missing gdb ‘s functions and parser. However, one thing in gdb that’s become steadily worse is the ability to evaluate STL’s operator[] and the like in optimized code, with the debugger frequently whining about inlining. It’s pretty h…
I can't speak to the comparison with gdb, but as a game developer I have had the misfortune of working with a lot of second rate debuggers that were the only option because they were part of the toolset for that particular game console. Most of these are pieces of software that the console maker would contract out to a smaller company to build custom and provide as part of the development kit, and they would be riddled with bugs, poorly supported, often poorly translated from Japanese (I recently worked with a debugger which had "Go" and "Come" as a couple of the primary menu items, I think those were supposed to mean start and stop), and lacking in important features.
Basically it was such a pain to debug on the actual game console platform that we made a PC build of the game just so that we could have the pleasure of debugging in Visual Studio and avoid having to debug on the console, even though we were not planning to ship on PC. Maintaining a separate PC rendering engine and other platform specific libraries at a fair expense, but it was always worth it in terms of being able to solve problems faster. We had other motivations as well, on some game platforms the tools for linking and building an executable "ROM" could be quite slow, so having a PC build would save quite a bit of turnaround time.
I have always had a very high opinion of Visual Studio's debugger because it has a few features that are invaluable that other debuggers lack:
- "Immediate Mode", a.k.a., the ability to run C++ functions while stopped at a breakpoint. We use this a lot for writing functions which log out a bunch of useful information which would otherwise be tricky or time consuming to find via the debugger's usual interface (watch window, or whatever). In particular, we encode all our strings in the game as 32-byte hashes but in debug modes we keep a u32-->string lookup table around, and calling functions in the immediate window is invaluable for getting identifying information from out of those string-hashes.
- Data Breakpoints, i.e. stop when a particular memory address is written to. Critical for debugging "memory stomp" bugs such as array-overflow issues or writes to dangling pointers.
- Custom "visualization". Visual Studio's debugger has an XML language called .natvis which allows you to define a custom way to pretty-print specific types. Basically the equivalent of defining a custom "ToString" in a language like C#. The .natvis language is kind of annoying to use, but without it certain data types would be a real pain to look at in the debugger. (e.g. rather than using pointers everywhere, we have a safer Handle type which is essentially a lookup into a table that has a pointer. These indirections would be a pain to follow manually in the debugger, but .natvis allows us to present the target object in the debugger automatically, so that it is as easy as following a normal pointer)
- Automation. There's a fairly rich automation API ("ENVDTE") which allows you to drive the debugger from outside tools. I'm currently using this with Python to provide a convenient way for non-technical people (e.g. QA testers) to bundle up and send all of the relevant details from a crash to other members of the team. (e.g. callstack with all the locals, and contents of log)
Re: Thoughts on Modern C++ and Game Dev
#135Earlier quoted context omitted.
You just mentioned 2 garbage collected languages on a game dev topic. I don't think they're adequate. Remember how the article was very insistent about being able to control memory and CPU resources. Those are one of the few reasons C++ is not dead. Rust? I don't see it either.
Garbage Collection is not per default something bad, even in game development, its a method of memory management, just like reference counting, or manual memory management. If you are allocating memory in your renderloop, your likely doing it wrong. Allocation outside of this critical path, well, chose your poison. GC will consume more memory, but likely to be faster when it comes to allocating and deallocating large…
You can allocate stuff on the stack instead, or keep things in a game state.
Re: Thoughts on Modern C++ and Game Dev
#136Game developers should start using more Rust.
For console development (Sony, Nintendo, XBox), anything but C++ has never seemed like an option because all of the development tools and libraries provided for working on those consoles are C++ centric.
But I'm curious if there are any console development companies that are successfully using Rust or other languages which perhaps can link with C++ libraries?
We use C# in our studio for tools, and are able to link it with our game C++ so that we can run some of the game's subsystems within the tools (e.g. animation engine) but shipping the game with C# code is not an option for several reasons, performance being the most important, but also we need to build our game for the console using CLang/LLVM, and I suspect it's not possible to write C# which interfaces with C++ using LLVM, only with Microsoft's compiler.
Re: Thoughts on Modern C++ and Game Dev
#137Earlier quoted context omitted.
I find reading medical "standards" papers onerous and feel like they're written in a way that's deliberately inaccessible. I don't much like the idea of going to Medical Conferences -- even if my company funded it, which maybe they would, I feel like I'd be marginalized for not knowing basic medical techniques, not knowing the new hotness by heart, and generally being a proponent of bleeding with leeches. I just feel…
You're being flippant, but your paragraph is the reason we have pharmaceutical sales reps, and the reason they are so well paid.
Except the information to inform himself is everywhere. All the CppCon talks are on YouTube. There are tons of great resources for learning modern C++, or learning about what's going on in the C++ world - there are plenty of teachers, among them even Stroustrup. If he isn't interested in putting in anything more than zero effort into defeating his own ignorance, why should anybody else care about him?
Re: Thoughts on Modern C++ and Game Dev
#138Earlier quoted context omitted.
I was in an IST 5/-/21 committee meeting last month, and sat next to committee members who were talking about the same things as you are. None of them came from academia. The truth is that C++ standardization is not full of "academics", and people involved voice these same concerns. One of my fellow committee members, Guy Davidson, is in the games industry, and the subject of the 2D graphics proposal has been a regul…
I'm not a fan of the 2d graphics proposal, some for reasons specific to it (I think it's too like the HTML5 Canvas API) some for more philosophical reasons like 2D graphics is a big subject that may not be possible to standardize in a way that pleases enough people. It's true that the existence of the proposal demonstrates the committee has realized graphics programmers had needs! The discussion around it too does a…
The end of the blog literally lists some ways it's possible to get involved without already being best friends with Herb Sutter. I'm not sure what else you need. An engraved invitation?
https://groups.google.com/a/isocpp.org/forum/#!forum/std-pro... https://groups.google.com/a/isocpp.org/forum/#!forum/sg14
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/ All the papers here provide the email address of the author, so you can contact them if you have concerns.
Re: Thoughts on Modern C++ and Game Dev
#139Game developers should start using more Rust.
For console development (Sony, Nintendo, XBox), anything but C++ has never seemed like an option because all of the development tools and libraries provided for working on those consoles are C++ centric. But I'm curious if there are any console development companies that are successfully using Rust or other languages which perhaps can link with C++ libraries? We use C# in our studio for tools, and are able to link it…
For Rust, Chucklefish has written rust for all the current generation of consoles: https://github.com/rust-lang/prev.rust-lang.org/blob/master/...
There are other game companies doing stuff, but we have less details including platform: EA’s SEED division, Ready At Dawn, and Embark (some ex-SEED devs making a new studio where Rust is the primary language.)
Re: Thoughts on Modern C++ and Game Dev
#140Earlier quoted context omitted.
I'm curious if this comment stays true once you build debug with -Og since that's an actual optimization level now that ensures the code remains debuggable while still applying a meaningful number of optimizations. Most people turn off all optimizations in debug builds but that's silly for 99% of problems unless you're tracking down a potential compiler bug.
QEMU briefly used -Og for its debug build setting, but switched back to -O0, because in practice using -Og results in a lot more situations where gdb just says " " rather than being able to tell you the values of variables, arguments in stack backtraces, and so on. If -Og really was "optimize where possible without breaking the debug illusion", that would be great, but in my experience it absolutely was not, and now…
What version of GCC/GDB were they using? I've been using GCC/GDB 7 for embedded development and haven't really seen a problem with it. It's also almost a hard requirement because otherwise the generated code is much larger & much slow which impacts the runtime behaviour to a significant extent.