API Question Panel2D help

[jedidia]

Since the original code of IMS was written for Orbiter 2006, it doesn't yet have a sketchpad, so I'm about to switch all drawing events from WinAPI.

The trouble is, I don't really know how to define a sketchpad. Usually, functions provide it directly, like for example MFD::update. But already when it comes to drawing the text for MFD buttons, I hit a wall, as there seems to be no version of clbkPanelRedrawEvent that would pass me a sketchpad. I assume I have to define and register one myself (I'll need to do that anyways for drawing the custom displays), but I am unable to find a tutorial or other documentation on it.

---------- Post added 01-26-12 at 09:16 AM ---------- Previous post was 01-25-12 at 10:24 AM ----------

Sorry for posting this in the wrong place initially, completely forgott that we have a dedicated SDK forum.

Anyways, I took a good look at the DG sample, and to be honest, it confuses me.

So far, I learned that there is clbkLoadPanel2D, which is the newer version. What I don't get is why the DG uses both clbkLoadPanel and clbkLoadPanel2D. It seems that clbkLoadPanel2d is only responsible for the scaling, is that correct?

Also, I figured by now that sketchpad is used exclusively for MFDs, and that on a panel, I have to use oapiBlt even for text. That might complicate things a bit, but should be doable (although I'm not yet exactly sure how the DG sample converts its text into bitmaps, but I guess I'll figure it out with some trial and error). The only question left is: Did I get this right, or am I missing something?

 

[martins]

So far, I learned that there is clbkLoadPanel2D, which is the newer version. What I don't get is why the DG uses both clbkLoadPanel and clbkLoadPanel2D.

It doesn't. clbkLoadPanel is commented out, it's just a leftover from the old panel version. Sorry for the confusion, I should remember to remove that bit of code.

Also, I figured by now that sketchpad is used exclusively for MFDs, and that on a panel, I have to use oapiBlt even for text. That might complicate things a bit, but should be doable (although I'm not yet exactly sure how the DG sample converts its text into bitmaps, but I guess I'll figure it out with some trial and error). The only question left is: Did I get this right, or am I missing something?

A sketchpad handle can be obtained from any surface by means of oapiGetSketchpad. The DG example however avoids creating sketchpads where possible for performance reasons and instead constructs text by blitting characters individually from a texture.

 

[n122vu]

When developing the Cortez, I converted the UMMU HUD message to use sketchpad for compatibility with the D3D9 client without the need for enabling GDI compatibility.

Check this post in the D3D9 development thread to see exactly how I did the UMMU message. Not sure if it will help for the MFD buttons, but hopefully will help get you headed in the right direction.
http://orbiter-forum.com/showthread.php?p=328111&postcount=1049

 

[jedidia]

clbkLoadPanel is commented out, it's just a leftover from the old panel version.

Not in the sample that comes with Orbiter2010 p1 it isn't, both functions are active in the code and indeed contain completely different instructions (all the active areas are registered in clbkLoadPanel, but not in clbkLoadPanel2D, for example). Probably an oversight, then. So, everything goes into clbkLoadPanel2D now. got it.

EDIT: Oh right, now I see. It's only commented out in the header, and the registering of panel areas is passed to a dedicated function. So that's that.

A sketchpad handle can be obtained from any surface by means of oapiGetSketchpad.

Ah! That's exactly what I've been looking for, thanks! I'll have some drawing going on in the menus, so I think I won't be able to evade Sketchpad, although most of the menu backgrounds could be created as bitmap resources and then blited... but that might bloat the file. I'll have to see what makes most sense...

---------- Post added 01-27-12 at 09:57 AM ---------- Previous post was 01-26-12 at 01:46 PM ----------

ohhhhkay... Changed the title, as my major problems now really aren't with sketchpad anymore. They're with the new panel architecture, or maybe more precisely the lack of tutorial therefore.

Frankly, a tutorial would be what I need, so I'll just ask bluntly: Are there any tutorials about making a Panel with the new architecture? I have the samples alright, but it isn't really easy for me to understand what's going on. I can see that the new method works by projecting a texture onto a mesh that is created at runtime, I see that obviously the MFDs themselfes get different meshes defined, but so far I haven't been able to get the new panel to even show on the screen without registering any instrumentation (well, at least I don't get build errors...)

Also, what are the requirements for the textures? does a 1280x960 texture work? I would assume not, at least not in DX 7, so I'll probably have to resize my backgrounds to powers of 2?

 

[Notebook]

Not sure if this is what you are looking for?

Developer masterclass: Creating 2-D panels the new way

http://www.orbiter-forum.com/blog.php?b=574

You can follow my attempts here from #23:
http://www.orbiter-forum.com/showthread.php?t=19866&highlight=westcott&page=2
Probably won't help much, but you could avoid some of my mistakes...!

N.

 

[jedidia]

Yes, that looks like a very good start! thanks a lot!

---------- Post added at 11:37 AM ---------- Previous post was at 10:58 AM ----------

Yep, that helped a lot, finally seeing something, although I haven't yet managed to create an MFD without getting a crash. I guess they should have they're own meshes defined so there's something to draw on... One question, it seems that the default transparency color is set to (0,0,0), is there a way to change that?

---------- Post added at 10:04 PM ---------- Previous post was at 11:37 AM ----------

After practically working on it the whole day, I finally have a panel working and an MFD and buttons displayed for it, but I'm still having trouble with transparency. Some parts that really shouldn't be transparent are transparent. When I look at those parts in Photoshop they are 0,0,0 but there are other parts that are 0,0,0 that are not transparent. I have no Idea what's going on there.

The other thing is trouble with the stuff that should be tranparent. I.E. the white background of my font. I tried to define transparency color via the colorkey in oapiBlt, but all that's doing is not blitting anything at all. If I don't enter a colorkey I get the letters correctly, just with a white background, if I enter white (or any other color I tried) nothing gets blited at all. THe line currently looks like this, which should be ok, but maybe I am doing something wrong with that DWORD...

oapiBlt (surf, surf, x, ytop+dy*btn, MFD_font_xpos, MFD_font_ypos, w, MFD_font_height, 0xffffff);

---------- Post added 01-28-12 at 01:23 PM ---------- Previous post was 01-27-12 at 10:04 PM ----------

Figured out how to configure the Alpha chanel to get rid of the involuntary transparency, but it seems like there can be no transparent blitting. If I blit a transparent background onto the panel, the panel itself becomes transparent at these places. Oh well, I can maneuvre around that, I guess.

Now, what I really can't figure out is why the MFD labels seems to use character code 107 and 109 for + and - instead of 43 and 45. I can replace them on the bitmap to solve the problem, but if any MFD label ever throws small letters at me I'll be screwed. Is this a known issue?

---------- Post added at 04:47 PM ---------- Previous post was at 01:23 PM ----------

Here goes another one from me, I hope I'm not getting boring.

I figured out most of my problems (including why + and - were exchanged with k and m, I realised that my font started at position 32...), but I'm still stuck with two.

MFD buttons are working as they should now, but the three display buttons below the MFD make trouble. Registration and recognition is working all fine, but it seems that the clicks don't get consumed after the event is processed. I.E. It usually happens that if I click the power button, the MFD shuts down, and jumps immediately back on. Same for the other buttons.
Event handling is initialised with the same flags as the MFD buttons, for which the problem doesn't exist:

PANEL_MOUSE_LBDOWN|PANEL_MOUSE_LBPRESSED|PANEL_MOUSE_ONREPLAY

I assume that oapiProcessMFDButton consumes the event, and since there's no call to that I have to consume the event myself. Trouble is, I don't know how. Here's what the function currently looks like:

bool MFDButtonRow::ProcessMouse2D (int event, int mx, int my)
{
  if (mx % dx < 30) {
		int btn = mx/dx;
		switch (btn) 
		{
		case 0:
			oapiToggleMFD_on (MFDid);
			break;
		case 1:
			oapiSendMFDKey (MFDid, OAPI_KEY_F1);
			break;
		case 2:
			oapiSendMFDKey (MFDid, OAPI_KEY_GRAVE);
			break;
		}
		return true;
	} 

	else return false;
}

As I said, the thing practically works, all buttons get recognised as they should, they just overreact a bit...

 

[orb]

As I said, the thing practically works, all buttons get recognised as they should, they just overreact a bit...

And if you set a breakpoint or send a message to log file for code with oapiToggleMFD_on or oapiSendMFDKey, is the breakpoint getting hit twice or the message logged to file twice?

 

[jedidia]

-removed due to irrelevance-

---------- Post added 01-30-12 at 01:10 PM ---------- Previous post was 01-29-12 at 05:30 PM ----------

And just when I think I have it all together, I can't get my sketchpad to draw a rectangle... Which is rather weird, considering it draws text correctly, so there can't be anything wrong with my implementation per se.

My test code looks as follows:

void Display::Paint(SURFHANDLE surf) {

	oapi::Sketchpad *skp = oapiGetSketchpad(DispSurf);
	skp->SetTextAlign (oapi::Sketchpad::CENTER, oapi::Sketchpad::BASELINE);
	skp->SetTextColor (RGB(200,200,250));
	skp->SetPen(g_Param.hPen[2]);
	skp->SetTextColor( RGB(200, 200, 250));
	skp->SetBackgroundMode(oapi::Sketchpad::BK_TRANSPARENT);
	
	skp->Text(60,20, "Sketchpad Test", 14);
	skp->Rectangle(10,10,60,60);

	oapiReleaseSketchpad(skp);
	
	oapiBlt(surf, DispSurf, xpos,ypos,0,0,displayWidth,displayHeight);

}

Pen definition:

	g_Param.hPen[2] = oapiCreatePen(PS_SOLID, 1, RGB(200, 200, 250));

I get "Sketchpad Test" on my display, but I can't get the rectangle outline. If I set a brush instead of a pen, I get a filled rectangle, so that seems to work. Is there something wrong with my Pen definition?

 

[n122vu]

Following this thread intently as I'm getting ready to start making panels myself. Good stuff!

 

[Urwumpe]

Why you can't draw rectangles: You try to draw in a surface in GPU memory. This supports only limited functions for optimization, you need to create a surface in normal memory and paint on it. I have example code somewhere, not sure if I find it soon.

 

[jedidia]

Why you can't draw rectangles: You try to draw in a surface in GPU memory. This supports only limited functions for optimization, you need to create a surface in normal memory and paint on it. I have example code somewhere, not sure if I find it soon.

Actually, it was because the standard GDI parameter PS_SOLID has value 0. Which, in sketchpad, is invisible (one of the few parameters that are not directly portable from GDI to sketchpad. I must give martin credit for the great portability otherwise, though. Once I figured out how stuff works, moving from GDI to sketchpad was basically auto-replace). Took me a time to figure out, but it's all working now, but thanks anyways.

Following this thread intently as I'm getting ready to start making panels myself. Good stuff!

Since you're following it, I might as well give the solution of the above repeated mouseclick problem. Set the redraw event only to PANEL_MOUSE_LBPRESSED|PANEL_MOUSE_ONREPLAY, NOT to LBDOWN. LBDOWN works for MFDs, which seem to have their own way of dealing with the event, but it doesn't work very well with standard panel events.

And the transparency was due to a dirty alpha channel when exporting the image to dds. I didn't get the transparent color to work, but seeing that it won't work with graphic clients anyways it's best not to use it.

What can be a real pain is creating the font, though... luckily irrlicht3d comes with a tool to create bitmap fonts from truetype fonts, that made work a lot easier. I'm pretty sure there other programs around that do the same.

 

[Mandella]

Following this thread intently as I'm getting ready to start making panels myself. Good stuff!

Me too! And I thought the panel making part of the addon was going to be the easy part! :facepalm:

I must give martin credit for the great portability otherwise, though. Once I figured out how stuff works, moving from GDI to sketchpad was basically auto-replace).

Hmmm.. Does that mean that perhaps one of the leet coders in the community might be able to put together a program that just converts it, like Artlav's SC3 to dll converter?

 

[jedidia]

Me too! And I thought the panel making part of the addon was going to be the easy part!

Getting the new panels to work is sure more effort than the old ones. Once you set up the basics, however, handling them is a lot easier.
Besides that, GUI programming always turns out to be be more work than you expected no matter what for...

Hmmm.. Does that mean that perhaps one of the leet coders in the community might be able to put together a program that just converts it, like Artlav's SC3 to dll converter?

A search and replace script for VS maybe (if there are such things in VS), but I think it would be too much effort. It's not so often that old panels get ported, and most of the time you should use static bitmaps rather than sketchpad, which is a whole different animal. I just had an awful lot of dynamic screens in this special case, so I totally needed sketchpad.