What are the differences in interaction with hardware in system programming and game engine development?

Question

IT education

Good day!
The question is quite unusual and may seem strange to you (yes, it seems strange to me), but I'll try anyway.
I would like to learn more about the differences in interaction with hardware when creating an engine and when system programming.
Both areas are interesting.
I would also like to know which of the areas requires more knowledge and skills (this in no way repels me, on the contrary).
Well, specifically for gamedev. What place does the C language take when creating the same engines?
Of course, the question is still the same, but I will be glad if someone accepts it and answers;)
Thank you in advance!

Answer 1

If you mean writing an OS, excluding writing drivers, then in both cases there is no interaction with the hardware. The OS is a set of clever algorithms for accessing resources. The game is essentially the same, only obeys the OS, which has more power, but usually the OS provides the game with everything that is possible (except for system files, perhaps).
In system programming, there is more emphasis on compatibility, bugs are not allowed, especially critical ones, because they put personal data, card numbers, etc. at risk. In game development, the emphasis is on speed, if the game is "cool", as they say, with an overabundance of graphics, individual objects and npc brains. Bugs are considered the norm (unfortunately) and are simply fixed as complaints accumulate, and sometimes they are even slaughtered.
If the game is not very loaded, then there is no point in using C for it. Generally. Because other things come to the fore, such as gameplay and content. And also marketing. And this is already a dark area for a programmer who has not dealt with game development before. This is a very vast area that needs to be entered separately and with the understanding that from an idea to implementation - like to the moon. After all, for the OS there are specific requirements that it should be able to (with which it should be compatible). And there are no requirements for the game - complete freedom, what you do will be, that is, this is art. And without experience, hoping that the game will pay for itself is very naive. The game requires a wide range of skills, not only in programming, and it is not recommended to do it alone, because there will be no profit from the division of labor (i.e. you will have to study a lot). And in the case of the OS, everything rests simply on the implementation time, which, obviously, is long. In both cases, friends are more fun, which is important.
When it comes to low-level programming, this essentially means performing a task unusual for a programmer, because it is better to transfer the subtleties of optimization to writing drivers. And at the beginning of my opus, I specifically excluded this topic. But sometimes you have to, yes. Actually, the first games were essentially based on self-written engines, after which the whole movement began with graphics acceleration. But today there are all sorts of directx opengl vulkan, and a bunch of more complex game engines above them, so it makes no sense to reinvent the wheel.
As for C in general, I would really doubt it. Some of the shortcomings of C and C++ are obvious these days. These languages ​​will exist for a long time, because they have a lot of baggage behind them, and a lot of old things need to be supported. The main feature of C\C++ is the speed of the finished program. But now new languages ​​are marked as leaders in terms of simplicity, convenience, security and compilation speed. And some have been for years. It's only the beginning. I think one day C, even in NASA, will give the palm to another language.

Answer 2

Where did you get such ancient information from?
There is no interaction with iron when creating a game. All interaction goes through the driver, and not directly. And it's been like that for 20 years, I guess.
But up until the end of the 20th century, your question still made sense.
This is very different knowledge.
Your question sounds something like this: what requires more knowledge - driving a car or shooting a sniper rifle?
Incomparably.
Yes, the same as C# or JS or Kotlin, for example.