Continously called DoUpdate method, that allows to handle TUIControl.Update. This is something different than LCL "idle" event, as it's guaranteed to be run continously, even when your application is clogged with events (like when using TWalkCamera.MouseLook).
Capture the current control contents to an image. These functions take care of flushing any pending redraw operations and capturing the screen contents correctly.
Be cafeful about comments in the published section. They are picked up and shown automatically by Lazarus Object Inspector, and it has it's own logic, much much dumber than what PasDoc sees. There seems no way to hide comment there.
We publish most, but not all, stuff from inherited TCustomOpenGLControl.
Exceptions: - Don't publish, as not every widgetset has them. property RedBits; property GreenBits; property BlueBits; - Don't publish, as we have our own event for this. property OnResize;
Event called when the OpenGL context is created, you can initialize things that require OpenGL context now. Often you do not need to use this callback (engine components will automatically create/release OpenGL resource when necessary), but sometimes it may be handy (e.g. TGLImage requires OpenGL context). You usually will also want to implement OnClose callback that releases stuff created here.
Even when you really need to initialize some OpenGL resource (like TGLImage), instead of using this callback it's usually better to derive new classes from TUIControl class or it's descendants, and override their GLContextOpen / GLContextClose methods to react to context being open/closed. Using such TUIControl classes is usually easier, as you add/remove them from controls whenever you want (e.g. you add them in ApplicationInitialize), and underneath they create/release/create again the OpenGL resources when necessary.
Event called when the context is closed, right before the OpenGL context is destroyed. This is your last chance to release OpenGL resources, like textures, shaders, display lists etc. This is a counterpart to OnOpen event.
Event always called right before OnRender. These two events, OnBeforeRender and OnRender, will be always called sequentially as a pair.
The only difference between these two events is that time spent in OnBeforeRender is NOT counted as "frame time" by Fps.FrameTime. This is useful when you have something that needs to be done from time to time right before OnRender and that is very time-consuming. It such cases it is not desirable to put such time-consuming task inside OnRender because this would cause a sudden big change in Fps.FrameTime value. So you can avoid this by putting this in OnBeforeRender.
Called when window contents must be redrawn, e.g. after creating a window, after resizing a window, after uncovering the window etc. You can also request yourself a redraw of the window by the Invalidate method, which will cause this event to be called at nearest good time.
Note that calling Invalidate while in OnRender is not ignored. It means that in a short time next OnRender will be called.
Called when the control size (Width, Height) changes. It's also guaranteed to be called right after the OnOpen event.
Our OpenGL context is already "current" when this event is called (MakeCurrent is done right before), like for other events. This is a good place to set OpenGL viewport and projection matrix.
In the usual case, the SceneManager takes care of setting appropriate OpenGL projection, so you don't need to do anything here.
Called when user releases a pressed key or mouse button.
It's called right after Pressed[Key] changed from true to false.
The TInputPressRelease structure, passed as a parameter to this event, contains the exact information what was released.
Note that reporting characters for "key release" messages is not perfect, as various key combinations (sometimes more than one?) may lead to generating given character. We have some intelligent algorithm for this, used to make Characters table and to detect this C for OnRelease callback. The idea is that a character is released when the key that initially caused the press of this character is also released.
This solves in a determined way problems like "what happens if I press Shift, then X, then release Shift, then release X". (will "X" be correctly released as pressed and then released? yes. will small "x" be reported as released at the end? no, as it was never pressed.)
For a mouse, remember you always have the currently pressed mouse buttons in MousePressed. When this is called, the MousePosition property records the previous mouse position, while callback parameter NewMousePosition gives the new mouse position.
Continously occuring event. This event is called at least as regularly as redraw, so it is continously called even when your game is overwhelmed by messages (like mouse moves) and redraws.