Now mostly retired, but I've been doing game dev for a couple of decades. I would say based on my career and that of my peers, it is more correct to say C or even assembler is the traditional graphics programming language with regard to games. It just depends on your definition. For that matter, if we consider things like CAD, 3D modeling/animation (using APIs/scripting), movie production, etc. to be graphics programming, again there are some differing results as to which language you use.

It also really depends on what time period we're counting as the "start" and if we value older games or periods of higher but simpler productions vs. now. For instance, I wrote quite a lot of code against NES, SNES, Genesis, Atari, Arcade machines, C64, and so on in assembler. 68000-based systems alone are such a huge chunk of sheer volume of games and most of us wrote quite a bit in pure assembler with regard to graphics.

On other systems that were faster or for different game requirements, we definitely used a ton of C, only moving to C++ later. In the case of C++, it's almost hard to even call things C++ at times. To be honest, most decent game engines I've worked on essentially use C++ to practically rewrite the language and go to great lengths to avoid some of the primary selling points of C++. It's sort of pick and choose some good things about C++ or at least powerful things while avoiding some of the burdens of C with regard to games. Obviously general C++ programming is different, so keep in mind I'm only referring to professional games programming. As things have progressed, people are indeed using more of what the newer C++ standards offer, but most of the same things still hold true. Where one has a tough argument with regard to graphics is the fact that so much now happens on the GPU, which one can argue is its own thing given stuff like shader languages.