[API Question] I need help with cockpit redraw events.

[Hlynkacg]

So in clbkLoadVC I call

SURFHANDLE tex_p1Display = oapiGetTextureHandle (mh_cockpit, 4);

to get the texture handle for my panel redraw map. The slot is already marked as dynamic in the .msh so from here all I have to do is call

oapiCreateSurface (LOADBMP (p1displays));

and the bitmap will be printed to the display correct?

from there I can just paint on it using sketchpad yes?

...No because it didn't work. can somebody please help me understand GDI?

[Hlynkacg]

So I'm stealin the "paint individual vessel markings" code from the stock delta glider as it seem to have the functionality I need. (printing a string to a mesh)

I have every thing set up but I'm confused about this line here...

insignia_tex = oapiCreateTextureSurface (256, 256);
SURFHANDLE hTex = oapiGetTextureHandle (VCMFDSPEC , 5);
if (hTex) oapiBlt (insignia_tex, hTex, 0, 0, 0, 0, 256, 256);

how is it calling VCMFDSPEC as a mesh handle?

Not only does it make no sense but my compiler marks it as an illegal operation.

It compiles in the Dg SDK sample but not my own code, what gives?

[csanders]

In my SDK example, it's:

// **************** vessel-specific insignia ****************

insignia_tex = oapiCreateTextureSurface (256, 256);
SURFHANDLE hTex = oapiGetTextureHandle (exmesh_tpl, 5);
if (hTex) oapiBlt (insignia_tex, hTex, 0, 0, 0, 0, 256, 256);

[jedidia]

Quote:

@Jedia would you mind explaining what's happening in your IMS_MFC::MFCprint function?

Sure. It's a direct adaptation from the code included in the tutorial, really.

void IMS_MFC::MFCprint(SURFHANDLE surf, char* text, int _length, int _x, int _y, MFC_TEXT_POS tpos)

In the header, I pass the surface the text should be drawn on (passed to your redraw function from the draw event calback), the text itself, the number of characters in the text, target x and y coordinates and a basic format identifier that modifies the x coordinate. Y coordinate is always upper edge, ad for x-coordinate I have the modifiers T_LEFT, T_cENTER and T_RIGHT, specifying wheather the x coordinate denotes the left edge, the center or the right edge of the text.

Quote:

{
int fWidth = 9;
int fHeight = 13;
int textwidth = fWidth * _length;

here I define font width, font height and calculate the length of the whole string in pixels (since I have only one font size).

	for (int i = 0; i < _length; ++i)
	{
		int srcx = (text[i] - 32) * fWidth;
		int tgtx;
		switch (tpos)

here I start the drawing loop, from the first character of the string to the last. The first and most important thing is to find the the x and y coordinates on the source texture. This won't work for your bitmap quite as easily, unfortunately. The simplest way is to have the whole text on one line in order of their ASCII codes. Mine starts with the space character, which is ASCII 32, (that is, the numerical value of the character will be 32 if it is a space), and then progresses through to the tilde (~) in order of their ascii codes, starting at x zero of my texture. So, all I have to do is substract 32 from the value of the current character in the string and multiply it with my character width to get the x position of the character on my texture.

For your bitmap, this will be a bit more complicated... you can look the values up on an ASCII table and assign them manually, you can make a more practical bitmap, or you can figure out some logic to let the computer calculate the position in your current bitmap (you should put the bitmap into your panel texture, by the way, if that wasn't clear so far).

	{
		case T_LEFT:
			tgtx = _x + i * fWidth;
			break;
		case T_RIGHT:
			tgtx = _x - textwidth + i * fWidth;
			break;
		case T_CENTER:
			tgtx = _x - textwidth / 2 + i * fWidth;
		}
		oapiBlt(surf, Src, tgtx, _y, srcx, 0, fWidth, fHeight);
	}
}

All that's left to do now is figure out the x position of the current character on your panel. In my case, this is of course different depending on the format identifier. T_LEFT takes the passed value as the left edge of the first character and moves every character to the right by the character width. T_RIGHT does the opposite, and T_CENTER takes the passed x value as the middle of the string and calculates the characters target position from there. And then there's of course the blitting, which just uses all the values we calculated so far to blit the character from the right source position to the right target position. Finito!

[Hlynkacg]

Ok I generated a new bitmap that is in proper ASCII order, and much closer to the effect that I eventually want.

That said is it really better to make it a single row? I need the full alphabet and I'm worried that having a texture that is 64x1024 (or similar) might be a bit much.

I'm working on adapting what you have so here goes nothing...

void Spider::LCDPrint(SURFHANDLE surf, char* text, int _length, int _x, int _y, MFC_TEXT_POS tpos)
{

int cHeight = 40; // Character height [pixles]
int cWidth = 24; // Character width [pixels] 
int cRow, cCol; // Character's position in bitmap [row / column]
int textwidth = cWidth * _length;

for (int i = 0; i < _length; ++i)
{
  cRow = (text[i] - 32) / 10;
  cCol = (text[i] - 32) % 10;

  int srcx = cCol * cWidth;
  int srcy = cRow * cHeight;

  int tgtx, tgty;

...

Now I have no intention of changing my text's justification so i can ignore the T_Pos switch correct?

Anyway, where do I go from here. don't I need four x/y coordinates to define an area not just two?

once I have my coordinates what do I do with them?

[jedidia]

Quote:

That said is it really better to make it a single row? I need the full alphabet and I'm worried that having a texture that is 64x1024 (or similar) might be a bit much.

You shouldn't make too many different texture files. The more you get into the same file, the better (up to a certain size, of course). Since this font is most likely not the only texture you're going to need, make a file where you can put all the stuff in (for panels, you usually seperate this by panel. Every panel a texture file. For VCs you can use a similar sorting mechanic, if you need more than one texture). My panel textures are 2048 x 1024, so there should be plenty of space to put your font.

But of course you don't have to do it, it's just important that you have a means of finding the correct corner points for a given ASCII code.

Quote:

Now I have no intention of changing my text's justification so i can ignore the T_Pos switch correct?

You can ignore the switch, but you still have to calculate the target position of your text. That is, the T_LEFT entry.

Quote:

Anyway, where do I go from here. don't I need four x/y coordinates to define an area not just two?

Because the other two are derived from your xharacter width and height. Take a look at oapiBlt, you'll see that it takes tgtX, tgtY, srcX, srcY, width, and height. I think there is also a version of it that allows for scaling where you can enter two different dimensions for target and source surface, but I'd only use that if there is no humanly possible way to do what you want to do, as it is slow and the interpolation can look crappy.

Quote:

once I have my coordinates what do I do with them?

oapiBlt(surf, Src, tgtx, _y, srcx, 0, fWidth, fHeight);

[Hlynkacg]

Quote:

Originally Posted by jedidia

 Because the other two are derived from your xharacter width and height. Take a look at oapiBlt, you'll see that it takes tgtX, tgtY, srcX, srcY, width, and height...

Which corner am I passing it then? Top left? Bottom right?

as for the rest...

Ok so you're saing that all of my displays, (or at least the LCD ones) should be a single texture?

Something like this for instance?

[jedidia]

Quote:

Which corner am I passing it then? Top left?

Yes, Top left. It's pretty much standard for any and all bliting operations that you orient yourself at the top left corner, since by file logic, top left is 0/0.

Quote:

Ok so you're saing that all of my displays, (or at least the LCD ones) should be a single texture?

I'm saying that your whole cockpit should be a single texture, as long as you can reasonably fit all elements into one single texture. It's not strictly speaking necessary, but its usually faster, as there has to be less read/write accesses to different surfaces. At least I think so, I'm not exactly an expert on the topic. But it's what I've been told so far.

[csanders]

Quote:

Originally Posted by Hlynkacg

 Which corner am I passing it then? Top left? Bottom right?

Should be top left. Don't forget the top left pixel is 0,0.
X increases to the right, but Y increases going down.

0,0 -> 1,0
|
v
0,1 -> 1,1

[Hlynkacg]

Quote:

Originally Posted by jedidia

 I'm saying that your whole cockpit should be a single texture, as long as you can reasonably fit all elements into one single texture. It's not strictly speaking necessary, but its usually faster, as there has to be less read/write accesses to different surfaces. At least I think so, I'm not exactly an expert on the topic. But it's what I've been told so far.

The thing is that I'm doing a VC not a 2D panel so I'm dealing with painting multiple mesh groups and the documentation is rather vague about it all. VCs were clearly an afterthought.


In the end though this should work yes?

void Spider::LCDPrint(SURFHANDLE (displaysurface), char* text, int _length)
{
int cHeight = 40;	// Character height [pixles]
int cWidth = 24;	// Character width [pixels] 
int cRow, cCol;	// Character's position in bitmap [row / column]
int textwidth = cWidth * _length;

for (int i = 0; i < _length; ++i)
{
	cRow = (text[i] - 32) / 10;
	cCol = (text[i] - 32) % 10;

	int srcX = cCol * cWidth;
	int srcY = cRow * cHeight;

	int tgtX = i * cWidth; 
	int	tgtY = 0; // for single line display only, multi-linedisplays would need adiditional function here

	oapiBlt( (displaysurface), (mybitmap), tgtX, tgtY, srcX, srcY, cWidth, cHeight);
}

then in my cockpit redraw event i'd call...

LCDPrint( (displaysurface), "(string)", (string length) );

[jedidia]

Quote:

The thing is that I'm doing a VC not a 2D panel so I'm dealing with painting multiple mesh groups and the documentation is rather vague about it all.

It merely means that you have more different target surfaces, it's not any different in anything else. You could define all the panel elements as meshgroups n 2d panel too, it's just not a necessity.

Quote:

In the end though this should work yes?

Can't find anything wrong with it when reading through it, at least.

[Hlynkacg]

Ok but I'm still unclear about how exactly I go about including bitmaps in a C++ project.

Do I have need to have a "Panels.dds" in my orbiter/textures folder which I blit things onto?

How does this play into more complicated panel elements such as an ADI or other gauge?

Basically, once I've generated this texture what steps do I need to take to apply it to the mesh?

---------- Post added 07-04-12 at 01:15 AM ---------- Previous post was 07-03-12 at 09:20 PM ----------

I have my bitmap sitting as a resource in my VC2010 project how do I actually call it for use in a function?

also, what is this g.param.hDll that I see getting called in pretty much all the SDK samples? It seems to have something to do with this.

---------- Post added at 05:34 AM ---------- Previous post was at 01:15 AM ----------

ok I've marked LCDfont.bmp as a resource and copy/pasted all instances of g_Param and hDll from the DG sample into my code.

the code compiles but I'm getting the following error on the .bmp itself.

1>Bitmaps\LCDfont.bmp : fatal error LNK1136: invalid or corrupt file

Is there a specific format (other than simply *.bmp) that it needs to be in?

[csanders]

Generally, you import a .bmp into Visual Studios as a resource, and assign it an ID, usually something like IDB_BITMAP. Then you can load it and get a handle with somethinglike:
LoadBitmap(NULL, MAKEINTRESOURCE(IDB_BITMAP))

Not sure on the first parameter that I put a NULL in for...

More here:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

[Hlynkacg]

Quote:

Originally Posted by csanders

 Generally, you import a .bmp into Visual Studios as a resource, and assign it an ID, usually something like IDB_BITMAP. Then you can load it and get a handle with somethinglike:
LoadBitmap(NULL, MAKEINTRESOURCE(IDB_BITMAP))

Not sure on the first parameter that I put a NULL in for...

More here:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

How do I import and give it the ID?

Is this seperate from simply going into the file menu and clicking "add existing file to project"?

[jedidia]

Quote:

Generally, you import a .bmp into Visual Studios as a resource, and assign it an ID, usually something like IDB_BITMAP. Then you can load it and get a handle with somethinglike:
LoadBitmap(NULL, MAKEINTRESOURCE(IDB_BITMAP))

No, that's the old way of doing it, when we still used winAPI functions to blit panel bitmaps. as of Orbiter 2010, we have functions provided by the Orbiter API that use DirectX, so includng every bitmap as a resource is not necessary. You can still do it if you want to incorporate your textures directly into the executable. Advantages of this are a bit faster loading times, and the textures are inaccessible to the user, but it is a big hassle during development (longer compilng times, need to recompile the whole thing everytime you make a change to the texture, etc).
Just make your textures a dds, drop it in the textures folder and load it as shown in the tutorial I posted.