Yes! Thanks a lot, that did it!! :) :cheers:
For anyone's reference, this is what you have to do:
SURFHANDLE Surface = skp->GetSurface();
oapiReleaseSketchpad(skp);
// Draw on Surface here!
skp = oapiGetSketchpad(Surface);
// Here you can resume using skp.
I'm just finishing off the code...
Hm, are you sure? I've tried writing to Orbiter's log and oapiDebugString() from within Update(HDC), with no output from either. I also tried commenting out all of Update(Sketchpad), just in case Orbiter checked if that was implemented before calling Update(HDC), but still nothing in the log. I...
Tschachim's solution uses GDI. If possible, I'd like to avoid that for a number of reasons. I'd have to "downgrade" from MFD2 to MFD class, and then convert all my drawing code into GDI from oapi::Sketchpad. Also, it's... slow.
Yes, GetSurface() does not like being blitted onto at all, or any...
I'm displaying a 2D representation of a vessel's mesh inside an MFD:
Obviously saving all the lines into an array and drawing them with oapi::Sketchpad's Line function is proving quite costly.
Reducing the number of sampled vertices will improve performance, but not enough. I think the best...
We could do that, but all the structures you need to tell the AI what to do (lua scripts, order system, AI Behaviours and instructions) form a large part of OBSP so we may as well keep it as the same project.
Note that since the code is structured with components that can be removed, enabled...
Progress Report 2 (New Video - Airfield AI and Autopilots!)
Here's a video of RisingFury's latest work - An Airfield AI that can taxi vessels between any two points on an Airfield. For example, if you have an XR2 on the runway and want to taxi to a hangar, the AI will find the shortest route...
I tested out the D3D9 client with OBSP a few months ago and there were no problems. As RisingFury said, we're just using functions from Orbiter's API. I'm unsure if this will still be the case when we begin to add more "eye-candy" (point lights at the centre of explosions, for example).
GLUT's my favourite. It condenses all the OS-specific tasks (like opening a window with an OpenGL view inside it, or capturing keypresses) into simple functions with syntax that's really easy to remember. The actual graphics-drawing part is just the usual OpenGL functions, so you can define...
Face, I think I've found a bug in your hooking library. I'm posting it here so anyone else who uses your code knows about it too.
VesselHook::hookVtable has the line:
HANDLE hSelf = OpenProcess(PROCESS_ALL_ACCESS, FALSE, ::GetCurrentProcessId());
This uses the flag PROCESS_ALL_ACCESS, which is...
That's true. Can you think of any way to hook VESSEL2 functions for both pure VESSEL2 and pure VESSEL3, but also hook the exclusive VESSEL3 functions for pure VESSEL3?
Thanks for the help :)
I've already modified the for loops so that clbkDrawHUD is called (which it is) - the problem is that the arguments that are passed to it seem to be invalid. I can't draw on the hDC, even if I try to do so directly in the HookMethods' clbkDrawHUD.
Do you multiply the...
Thanks for the help.
I originally had them all set to EAX, and then tried changing them when I realised hDC wasn't being passed.
Either way it seemingly makes no difference - I'm still unable to draw on the hDC. There's no crash to desktop or anything, just nothing shows up on the HUD. It's...
Face, I'm trying out your hooking library and it's working brilliantly! :)
I'm attempting to modify the HookMethods class so that it works for clbkDrawHUD. I've managed so far to get it to call the function and pass the mode argument, but I can't get it to pass the hDC argument :(
This is...
I've been thinking about using hooking myself, perhaps in OBSP. It definitely seems to be a cheaper way to do things than "simulating" callbacks (checking for events manually in the Module's own global callback functions, then calling a fake callback function in a class associated with the...