6 ms·
I really love time restricted environments, in my opinion they truly liberate programmers: instead of using language/library/tech/pattern/etc-of-choice they sud
by dmytroi 10y ago
I really love time restricted environments, in my opinion they truly liberate programmers: instead of using language/library/tech/pattern/etc-of-choice they suddenly realize "oh, we don't have time for that". Do we need GC? We don't have time for that. Do we need to allocate memory? We don't have time for that. Can we maybe do this enterprise-like tens thousands source code files OOP hierarchy thing? We don't have time for that.
Realtime forces people write less, writing only what actually matters, and all this in my opinion helps people to be better engineers (in-a-way). I just wish it looked more attractable for people - hacking your way out in time/resources constrained systems (like MCU's for example) can be as fun as hacking html/js to make your site behave as you want.
- davedx 10y agoIf only that was what actually happened... I spent a few years working in the games industry, and let me tell you, enterprise-like tens of thousands of lines of code files with massive OOP hierarchies were all too common. That's why I think Unity3D is fantastic -- they do the OO (composition) in their engine libs, you write simple scripts. In my experience, what really forces people to write more code "that matters" is programming languages and frameworks that constrain them.
- dmytroi 10y agoI also work in gaming industry and IMHO it depends on games, usually the biggest fun is on consoles market, people start making AAA games with engines like Unity, Unreal Engine 3/4, Autodesk Stingray (recently was bitsquid) and then they suddenly realize "oh, we are not getting 30 fps here, because of Lua/C++/etc" and then the fun starts: IIRC one game company was even asking Microsoft to add missing intrinsics to xbox one compiler because they were used in PS4 code, and PS4 and X1 are basically almost the same chip :)
- davedx 10y agoyeah. The biggest, ugliest C++ code bases I've seen were for AAA games. Some of the best programmers work in games, but you also see lots of grads and staff churn. TBH I have never seen a big C++ code base I liked. Unity may have its detractors and genuine deficiencies but the Unity projects I worked on were much more maintainable due to the constraints of working inside Unity itself.
- theseatoms 10y ago> TBH I have never seen a big C++ code base I liked. In what languages have you seen a big code base that you liked? Just curious.
- nitrogen 10y agoNot the OP, but in C I've liked Linux well enough (though it's not perfect), and PostgreSQL and SQLite are supposed to be examples of very well structured code.
- golergka 10y ago> Unity may have its detractors and genuine deficiencies but the Unity projects I worked on were much more maintainable due to the constraints of working inside Unity itself. As a game developer who mostly worked in Unity, this is horrifying. Unity-based projects are pile of horseshit in terms of architecture and organization, and I honestly hoped that AAA stuff is held to a higher standard.
- Someone 10y agoAFAIK, the main requirement for AAA games is to ship something in time (Christmas doesn't wait) that runs fast enough. And the thing to ship is the game, not libraries that will help making the next game easier. It may have changed a bit now that hardware speed doesn't increase that much anymore, but historically, that even applied to game series. Even if you knew there would be a sequel, that sequel would target vastly improved hardware, which means new graphics effects, higher-resolution textures, etc. That is not an environment that leads to high-quality code. The ability to update a game over the Internet hasn't improved that situation, to state it mildly.
- agumonkey 10y agoConstraints are limits you think against. Like grounding. Paradox of choice somehow.
- zeta0134 10y agoI've been spending a great deal of time working on a game engine for a Nintendo DS unit, which is a very constrained little system. Source here if anyone's interested. https://github.com/zeta0134/pikmin-nds https://github.com/zeta0134/pikmin-nds The NDS is an odd little system. Despite supporting 3D graphics, it entirely lacks useful things like a floating point unit, or a hardware divide. All of your math ends up being done in 12.20bit fixed point. Square roots are already slow on normal systems, and they're just ridiculously slow on this thing, plus you've only got something like 550k hardware cycles per frame to get everything done. Getting over 100 objects to draw, have basic physics applied to them, and perform AI in a reasonable amount of time has led to some eye opening revelations. Right at the start of the project I spent ages trying to come up with the fastest way to sort all of my objects back to front, to make the renderer work. I was just sure this was going to be the slowest part of the draw, so I spent probably two weeks on sorting implementations alone before finally giving up and choosing a std::priority_queue just to have something that worked. Then I actually tested the thing, and came to the (obvious?) conclusion that I had wasted a great deal of time. The std::priority_queue was handling 100 or so objects really really fast, and the system was lagging badly because the drawing itself was poorly optimized and needed to be revisited. I had to start actually profiling my code, and the recurring theme was that the bottlenecks were almost never where I thought they would be, and usually surprised me. It's a whole ton of fun, I'll say that much. Not sure if I'll end up doing anything useful with the engine once it's done (obviously I cannot do anything meaningful with a Pikmin clone due to IP reasons) but I'm enjoying just being able to push the limits of the system.
- Dylan16807 10y agoWhen your time budget is a million cycles to handle a few dozen samples, you absolutely can use careful GC and careful allocation. A complicated OOP hierarchy doesn't require any thought at all. It just works, without any care needed. Some realtime is truly restrictive. Realtime audio on a GHz-class processor is not.
- drewm1980 10y agoOOP isn't a problem, IF you're talking about C++ code using purely stack allocated objects, that you wrote yourself to not use any memory allocation, taking care with locks, etc... If you're not experiencing performance issues every day despite your smartphone being "ghz class", I want your phone!
- Dylan16807 10y agoMy phone has lots of performance issues. None of them are in the audio processing.
- rasz_pl 10y agoThis also works in reverse, take google full of fresh graduates filtered thru a process of 20 whiteboard interviews and you end up with 150ms audio/input subsystems lag