For an optimal performance you need to be very careful concerning the way you draw your graphics. Most of Hollywood's drawing commands are implemented in software only, i.e. they draw using the CPU instead of the GPU. This can become quite a bottleneck especially on slower CPUs. Thus, you should draw directly using the OpenGL commands offered by GL Galore whenever and whereever possible.
Nevertheless, there are a few Hollywood commands which are redirected to use OpenGL directly when GL Galore has been activated. These are the following:
Box() Cls() Line() Plot() DisplayBrush() |
You can use these commands with OpenGL without any performance penalty. However, there are
some restrictions: Box(), Line(), and WritePixel() will only be redirected to OpenGL
in case the fill style is either #FILLNONE or #FILLCOLOR and no other form styles like #EDGE or
#SHADOW are active. As soon as you want to draw with other fill or form styles, these
commands will fall back to their software counterparts and thus will be very slow.
DisplayBrush() will only use OpenGL directly when called with a hardware brush.
See Using hardware brushes for details. When used with a software brush, i.e. a brush
that doesn't reside in video memory, DisplayBrush() will draw the brush using the CPU
which is much slower.
When mixing Hollywood and OpenGL drawing commands, however, there is another potential problem that you have to be aware of: Since OpenGL is a state machine, changes to the GL state made by one of Hollywood's drawing commands can affect subsequent calls to OpenGL commands. Thus, you might need to restore certain states after calling a Hollywood command which is redirected to OpenGL, e.g. the current color, transformation matrix, matrix mode, enable texturing, blending or depth test again, etc. This can get quite tedious so it is often easier to use only OpenGL commands in order to avoid having to restore states after calling Hollywood commands.
Finally, don't forget that you should do all your drawing inside a hardware double buffer loop. See Using a hardware double buffer for details.