I'm considering using a GUIR Custom rendering routine to handle the in-game Star Trek graphics.

1. First off, do you recommend using the GUI system for stuff that will need to be dynamically redrawn?

2. If the answer to #1 is yes, then how exactly does one create a routine? What is the data format, or do you control that yourself?

Ok to start have you read http://dcs.cemetech.net/index.php/GUI_API this explains pretty much everything there is to know except a few special cases that most users will never encounter

That just talks about Pushing, popping, and navigating items...

that is all the routines are. To make a routine as you are suggesting you would push the items to the stack and render them. That's really all there is to it.

And now to explain what is Explained online I think in a different link but what ever.

GUIRCustom calls a routine in side the GUIRender subroutine When it is poped off the stack to be rendered. So you can draw your own graphics inside the window frames with out the need to use the dcs gui scripts. Now the dcs gui Is in my opinion a little slow once it gets past about 8 elements or so. So to decide on if its fast enough for you you will just have to test it. I honestly do not know how fast Star Trek is with its actual gameplay but in order to have high fps graphics you will have to have the render be external as in like an interrupt and you will have to handle the mouse input on your own. As in the DCS Gui mouse routines wont let your game run outside of it. I believe it is a blocking loop.

Oh, well let me explain to you a bit about the graphics for the game...

- There is no mouse. It's key press only.
- I'm assuming we will be reflashing the screen about 4+ times per second, but I may be wrong. I can't make any speed assumptions yet.
- Object oriented rendering. I'm trying to implement a system, where I can call a single routine on an "object" where you are given center coords and a radius, and the calculator figures out, with respect to your current position, how much of it you should be seeing, and sizes down or up the sprite as necessary.

I'm kind of at a loss as to how to implement this (I can get the data in the correct place, but I'm pretty sure quick full-screen copy routines like iFastCopy will not serve me well here).

If you dont plan on using a mouse or anything i would say that the dcs Gui routines really are not for you they are a lot harder to use with out a mouse. I know I have done it But for the sake of saying you are going to go with them.

4fps Might be feasable as long as you dont have a lot of GUI elements on the stack it takes about an eight of a second each iirc. Really depends on the element tho. Pretty much what you need todo is get that rendering routine done then come back to this. because that decides on how you would handle the whole GUI subroutines. And you may find it easier to implement your own static HUD or such instead making the dcs gui do something that it may not originally be intended for. They can be used for dynamic content but it is hard to implement.

Although I never got around to replying to this topic, hopefully we already convinced you that using the GUI system and a GUIRCustom item is not the right way to draw a game's "real-time" graphics. The GUI system is most often used for things that then use the GUIMouse, and it's too slow and complex for real-time game graphics.