Hello. I'm a complete newbie on game programming. Did a little demo of a color and music concept that got positive feedback & am hoping to scale up the concept for investors that have signed on, hopefully by using C++ and using 3D rendering. Rapidly changing color under very controlled rules is the essence of the game, and vector graphics with Action Script worked to an extent while music sequences played back. The load on the machine was manageable.

Could any of you please give advice on what tools, if any, will allow me to control rapid color changes of objects in 3-D, while appearing to do so on multiple textured objects simultaneously, based upon real time data like a spontaneous mouse movement, pitch bend event in MIDI, or the like? Is this even possible using an existing open source game engine or Open GL? Or could it possibly be done for fast enough PCs by creating a new engine. I just want to spontaneously & quickly vary color simultaneously and independently over several well textured objects like metal balls comprising a tunnel of shiny metal balls. I was thinking of making a library of 100 or so 'alpha maps' (forgive me, i know not what i say) that could be applied over the ball texture, each one successively farther around a hue wheel; then, when play the individually or sequentially from that library, according to the mouse or pitch bend data series.

Thank u for your answer; I'm gratified that hue, sat, lightness/brightness should be easy to quickly & independently change.

Let me explain where that question came from.. I tend to think up backward sounding stuff. I had asked a programmer how feasable it would be to program a shader to "edit" texture elements quickly enough that they could display a texture going through gradual changes.

Eg lets say you want to visibly alter a reflective surface depending upon a user-controlled game element or action. Eg specularity or reflection, or refraction index. I imagine that these things would need to be "canned" to a video of the event, but direct control in todays shaders that use a GPU and stored/compressed textures in memory would be going against the grain.

He seemed to respond that something like a reflected surface level of reflection wouldn't be quickly alterable without swapping out the object's; I interpreted this to also mean that anything within the texel level wouldn't be quickly alterable.

I was hoping to get near real time interaction with a texture, not necessarily for today's computers but maybe high end computers of 2015. Today that would seem to me to mean getting a texture element, be it color's individual components, but also , including specularity, reflecton, etc., even maybe incremental bump-map changes (this adds to my confusion on what can be done at shader level, since the wiki shader article lists bump mapping, phong shading and other things I would have expected to exist more in the texture than in what the shader does) , , to be refected at 100 milliseconds or 50 milliseconds or something. I assume, since one purpose of the GPU is storing and loading textures, but is NOT to store & access a texture series and control a cycle-through of it at some rate; nor, & more importantly, if a user happened to have 2 elements of a texture & be editing both (inadvertantly through game-play [so no "canned" series of a 2-D representation can exist because its not just a playback rate that is changing, but the order of the rate of two elements]), that would require the shader to be accessed while it was drawing output for composing into the screen image.

If this sounds overly complicated, i apologize. I really haven't got a clue what I'm talking about, but I want to hire some programmers to make this possible, if not for a large number of screen elements at one time at first, maybe just one element. And maybe also a texture that could be frozen; ie keep the reflection existing prior to the edit, so computing of reflection turns into just recompositing the image on the object/s with that texture.

When you hire a programmer, if they say:

- "It's impossible" -> don't hire them

- "It's no problem" -> don't hire them

- "It sounds possible, but I need to ask you a bunch more questions so that it is very clear what you want", and then goes on to describe the limitations/constraints of the approach they want to take -> hire them!

This is fantastic news for me. Thank u for such a concise, clear answer.

There are a lot of programmers who have responded to ads I put out these past months. The job requirements voiced in the ads were, in retrospect, overly broad & included midi/audio-dedicated software goals as well as game goals. Me thinks that was my big mistake. I needed to break the ads into individual tasks to find the right people to take on topic 1, 2, and 3. Its a steep learning curve just to develop a project. I can't imagine how difficult it is to take on the real under-the-hood programming like u all do. So Glad to find helpful people like yourself here. On we go to the top!