Menu
My brain tends to favor structuring concepts in hierarchical, object-oriented, component-like ways. Unfortunately, this is preventing me from understanding OpenGL--and i suspect the source of my confusion is in my misunderstanding of what the "OpenGL state machine" is. You got the graphics pipeline, but that is really specific to the individual program objects that draw the user's graphical components, right?
300
What is this state machine?
Imagine a switchboard with a couple dozen of switches dials. This switchboard is connected to machines in a processing plant and depending on how the switches are toggled, stuff that enteres processing plant on one side will travel through the plant in a certain path. Change the state of some of these switches and things will go another way.
There are also state machines, where the switches and dials are changed when stuff passes through a certain processing step; OpenGL is not of that kind.
A OpenGL context is such a switchboard with a processing plant behind it. The switchboard is what you control through the API, the processing plant is what makes the pictures.
What are the different states it can exist in?
Too many to list. For every switch the number of states multiplies by the number of positions that switch can be in. Say you've got 20 toggle switches, one dial with 5 positions and one dial with 7 positions, then you've got 2^20 * 5 * 7 = 36700160 possible different states. Some versions of OpenGL have over 300 state variables and many of them are not just boolean. So it's a futile endeavour trying to list each and every possible state.
Is it also event-driven?
No!
What inputs affect the different states the machine can be in?
Explicit calls of state changing functions of the OpenGL API; that and the default initial state.
Can hierarchical, OOP concepts be applied to this state machine?
No. Or rather, you can try, but truth to be told, the only truthfull representation would be that of a single OpenGL context class holding all the state.
There are a few things within a OpenGL context, that behave like individual objects with their own state. Textures for example, however these objects are closely tied to the OpenGL context itself and can not be looked at independently.
A personal note on your remark
My brain tends to favor structuring concepts in hierarchical, object-oriented, component-like ways.
Stop doing that! Computers don't work like that. OOP is a method to structure projects, but its not a very good tool to understand some preexisting system. Especially systems that are inherently nonheirachical.
I strongly suggest you expand your horizon by learning other ways to structure projects. How about learning functional programming? Haskell would be one of the popular FP languages right now and for the learning experience its exceptionally good, due to its focus on being a pure language. Here's a very good online book/tutorial: http://learnyouahaskell.com/chapters – be prepared to have your mind bent; some things may look like they are OOP, but they're not; running up against those walls may seem frustrating, but the benefit, when it finally clicks in your head and "you get it" (= have epiphanies) are truely worth it.
Note that OpenGL is neither functional nor truely OOP. And due to not being functional it doesn't map very well into purely functional programming. There are OpenGL bindings for Haskell, but they are implemented through something called a "monad"; monads is what functional programs use to get in touch with state or even driven environments.
Another resource I recommend is https://mitpress.mit.edu/sicp/full-text/book/book.html – every programmer out there should have read it.
169
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
