aegidian Wrote:The .car file would have to specify any needle center offset (away from the center of the quad, and where none is specified this can be assumed to be 0,0: the quad center) and the zero and maximum (or zero and range) rotations of the needle. Plus the position and font/size of any digital read-outs. These would have to be associated with the gauge model file.
Right, so ... why do you say it would be more sensible to do something else?
Oh, re-reading you were probably replying to zimluura's description of how to draw the objects.
Regarding this bit:
Quote:I would have drawn to a separate SDL_GL surface and passed the resulting data to a texture, BUT you could instead use two passes to the main frame buffer - which would be faster - and then use glCopyTexSubImage2D(...) to copy the rendered image to a texture.
It's a lot faster to just draw the gauge/needle onto quads on the dash than to draw them into a texture (via glCopyTexSubImage2D or even via the faster method, FBOs) and then draw your texture onto a quad on the dash. So, basically like how the current HUD is drawn but instead of drawing them from an ortho2D modelview matrix, draw them on the dash. This isn't very different from what you're suggesting, it's just a bit faster because it cuts out the step of rendering to a texture... unless I'm totally missing your point.
Aside from the question of how to render is the question of how to specify positions and textures. My first thought is just to have separate .joe files (probably just 1 quad) for each dial, so the artist could position the dial quads in a sensible spot in a 3D app. The .car file would then specify, for each gauge, the .joe file, a texture, a needle texture, a needle position offset (where 0.0 = overlayed exactly with the dial quad), and a needle scale (where 1.0 = the same size as the dial quad). Later on we can get fancy with S2000-style digital bar-graph readouts, numbers, etc.
