mmarks

Capture One is an alternative, common with those using Sony Alpha

Unity builds are a big win in Unreal Engine and basically required w/Unreal, the actual win is surprising large.

EDIT: I'm sure lots of work has been done, not trying to degrade that. Just sharing my experience on my projects, never worked with Chrome.

Doom 3 actually used Scons across all the OSes (~2004). At the time, it was so nice to have a python build system. I sort of hoped it was the future, but it sort of died as it failed to scale. I've seen a few home-brewed python build systems work well, but typically we're back to CMake/Make

I would expect kernels to be quite small (#file, line-count) compared to major Applications like Unreal Games and Civilization 5. I've never worked on Chrome, but I can safely say the amount of source code in a few Unreal Games and Civilization5 dwarfs the drivers and OS code I've worked on. Take Unreal then add a team of developers adding onto it for multiple years thru multiple releases. Then add all the middleware (Havok, AudioEngines, NaturalMotion).

OS are much larger than kernel, I'd guess all the driver code exceeds the actual kernel.

People always think they code base is large, but having built most of the Call of Duties and many Unreal games, all the OS code I've worked on is trivial in size comparison. There is probably something bigger, but games seem bigger than many major apps in my experience.

Not to take away from your point, but in my experience the vast majority of C++ build pipelines even at major companies can still be improved. Few people enjoy 'improving the build', it often touches everything, and requires discipline to keep it working. Most of the projects I've worked on have been larger than Chrome, I've seen the compile time for BioShock Infinite go from 2 hours down to 15 minutes with serious work on header use, precompiled headers, and all the other tricks people use. Epic's build system is a pretty good example. There is even a older book, Large-scale C++ Design, that is specifically about this point.

Starting with a full build that initially takes hours and it shrinking to < 15-20 minutes and better seems pretty par for the course for truely large C++ projects. You don't get a fast build process for free, but if the team makes it a priority, alot can be done.

EDIT: Times mentioned were for a full build, often you rarely due a full build, incremental builds should be majority. Places that don't make incremental builds 100% reliable drive me crazy and waste so much developer time. This is common, but it's a lame excuse. Just do the work and fix it.

You're correct that I just meant a lower power state.

The author mentioned blinking cursor, so it reminded me of graphics issues. A more efficient CPU state has the possibility of slowing an app due to CPU-GPU sync points. A blocking CPU in an energy efficient state can reawaken slower from GPU done notifications, so FPS is lower. So both c-state and p-states can affect performance. General point was just utilization may not be utilization at max power.

I've worked on problems where utilization was 15% at lower power and it was a problem. But to compare different workloads, it'd be < 1% at max power.

13% cpu usage at the lowest c-state is a also very different than 13% at an elevated c-states. I've recently spent a lot of time analyzing c-states/p-states and the power mgmt modes of the GPU. After learning more about the complexity behind the clocks, bus speeds, etc. underlying each state, whenever I hear someone quote a utilization number of a minor workload, I want to know at what power state.

Not to take away but the author's point, just an aside that utilization numbers can be a lot more complicated when there are dozens of energy states and the utilization might be utilization at a particular state rather than utilization at maximum power

Hey ben, those were fun days! For others, Metrowerks hit the wall that many Mac developers hit and continue to hit. The Mac market size simply isn't big enough for a 3rd party developer, so they tried other platforms. As Metrowerks tried many embedded markets, the Mac product suffered. Also, since only Metrowerks had a PowerPC compiler, Apple was very dependent on Metrowerks while Metrowerks was heading towards Chapter 11. The tension between the execs (give me more money/support or else) created a 'complicated' relationship.

Motorola rescued Metrowerks from the brink of Chapter 11 with the Apple/Metrowerks relationship already tense. Motorola also gave many long-time employees an excuse to leave (pre dotcom crash). PalmOS took so many people that lawyers were involved at the HR level between Motorola/PalmOS

In 1995, we watched these 1979 videos of Smalltalk in my programming languages college computer science course, which focused on Scheme.

I vividly remember the reaction of my fellow students. Given the mockery and jokes from my fellow students, you'd think they were watching a bad sci-fi movie. Most students discounted everything they saw, 'real men and real programmers used C'. I remember being so disheartened that it seemed we'd evolved so little in tools/languages from 1979 - 1995.

At the time, everything was Unix and C programming (DEC Alpha were just being installed on campus, Windows 95 had just been released). There were a lot of reasons Unix/C succeeded, there is a great classic paper about why C beat Lisp, and I agree with the author.

However, what always troubled me, is how my fellow students completely ignored any potential learnings from those videos. In many ways, those early Smalltalk programs were far more impressive than anything they had created, but they just wrote them off.

At GDC 2014, a post-mortem was presented on the classic game Myst. That was written entirely in Hypercard.

>> Even Carbon has been dead for three years. <<<

With regard to only this point, probably half if not more of the the top 15 grossing games on the Mac AppStore Games page today are either Carbon Apps or at minimum require the Carbon framework.

In Rich's source article, he questions the future of SteamOS and the partners involved in some of the ports are also questioning. Some people have started using past tense. I have no idea what Valve is planning, but my guess is that it's a long term play with limited resources. I'm guessing some of the interest inside Valve has waned.

Remember SteamOS was born before Win8 was announced and Valve was scared where MS was going. Steam on Windows seems pretty safe, the pressure is off.

While the theory sounds good, the Steambox never evolved to a list of supported configs. Valve stated that Nvidia, AMD, and Intel would all be supported and Valve displayed great hesitancy in providing any specifics. Rich's earlier post on the state of Graphics Drivers remains mostly valid.

In addition, the release of a few Linux games such as Civ5 & Borderlands, have provided sales figures to those companies on whether the investment was worthwhile.

Many companies considered Linux primarily because SteamBox was an interesting market. While some companies were taking a wait-and-see audience, the slow play of SteamBox only makes more people take a wait-and-see attitude.

The OpenGL mess of "4.4 is good enough", while both AMD & Intel failed to deliver good drivers, is further muddled by OpenGL Next. Basically, accepting the OpenGL API needs a re-write and will become more Mantle/Metal/DX12 like. So will Intel & AMD deliver good-enough 4.4 drivers, or do we all wait for OpenGL-Next. Don't forget that AMD just did a 7% layoff, limited resources.

Society6 has a fun collection: http://society6.com/laptop-skins

I nod my head in agreement with most of these OpenGL are broken articles. I've work on the OpenGL version of Call of Duty, Civilization, and more for the Mac. I think Timothy misses the real point on driver quality.

https://medium.com/@michael_marks/opengl-for-real-world-game...