Problem oapiBlt not cooperating....

[Moach]

well then... i figured i had it all set properly, but something fails silently...


i loaded my resource bitmap like this:

vcRsc_reht_tape = oapiCreateSurface(LOADBMP(BMP_RHTTAPE));

the 24-bit bmp i intend to use as an engines-reheat-level gauge tape is loaded as resource and properly assigned the BMP_RHTTAPE identifier...

then, with a little copy-paste job from the delta-glider LOADBMP macro, which i duely modified to suit my code i placed the above line in the clbkLoadVC method... as is the case on the DG samples :hmm:

it compiled just fine, so i figure it's alright to move on to the next step...


so i proceed to call oapiBlt upon clbkVCRedrawEvent... i took care to do so AFTER releasing the sketchpad, as to avoid troubles mentioned in the docs related to this....

this following stretch of code seems adequate... but it just so happens, it ain't...

	                //  (...)
	
			int rhtLvl = GetThrusterLevel(RT66_burner_thgr[0])*86;
			
			
			sp->SetPen(G422DrawRes.spSet[PEN_WHITE]);
			sp->MoveTo(12, 495); sp->LineTo(10, 495-rhtLvl);
			sp->MoveTo(88, 495); sp->LineTo(86, 495-rhtLvl);
			
			//
			//
			oapiReleaseSketchpad(sp);
			
			
			
			oapiBlt(surf, vcRsc_reht_tape, 12, 495-rhtLvl, 0, 86-rhtLvl, 10, rhtLvl);
			oapiBlt(surf, vcRsc_reht_tape, 88, 495-rhtLvl, 0, 86-rhtLvl, 10, rhtLvl);

do notice, the tape-gauge is supposed to be drawn bottom-up as the reheater fires up - the tape reveals itself upwards in proportion to afterburner power

with the first few lines, prior to sketchpad release, i ran a little test-of-logic by drawng a white line where the bitmap tapes should be.... then i reuse the same values to try and blit the things to the target surface

i do it twice for there are two engines in question here... although at the time, the logic driving both is forcibly symmetric, so there's no need to calculate stuff separately for each of the two...

well, the lines appear, as expected, and are properly positioned too...
the bitmaps however, do no such thing...


so i'm led to the obvious conclusion that something is unnacounted for here, and what it could be continues to baffle me...


could i have loaded the bitmap resources "wrong"? what gives?


any help is appreciated... i thank you in advance

---------- Post added 06-14-11 at 10:39 AM ---------- Previous post was 06-13-11 at 12:25 PM ----------

well, new developments ensued...

i have discovered that oapiBlt IS in fact working... well, not they way i wanted it to, but working nonetheless...

i was set about investigating whether i could have it blit from the same surface being redrawn (which luckily has some spare pixel-estate on the bottom) and guess what? - it works


ok, so that narrows it down somewhat... my problem is with the loaded resource bitmap then...

but it remains being a problem, as i had other plans to those extra pixels (i got more screens to draw in that VC)


plus, i don't feel i fixed it unless i learn what i should have done to avoid it altogether (über-geek syndrome :lol



then let us review some code, shall we?

the G42 class contains a SURFHANDLE for the soon-to-be-loaded resource bitmap...
now, M$VC is indeed a piece of evil, so i have yet to ensure i "resourced it" right... :facepalm:

problem could very well be there, i figure... not too sure on how can i tell if that's the case, tho...

let's see, i have:


- drawn a pretty gauge using Flash (which i like to use for drawing, specially GUI stuff)

- converted that into .bmp with Photoshop... maybe if i used Paint.NET... worth checking...

- added that as a "resource" into MSVC... new resource -> import -> choose file -> ok


- altered the resource ID from IDB_BITMAP1 to a more self-explaining BMP_RHTTAPE


- compiled... (i had checked "show progress" in the resource tool options - it output something about a bitmap with 2k-something bytes of size, i was convinced...)


- added "vcRsc_reht_tape = oapiCreateSurface(LOADBMP(BMP_RHTTAPE));" to my clbkLoadVC method (vcRsc_reht_tape is the SURFHANDLE member var i mentioned)


- added the previously-mentioned oapiBlt code to the clbkVCRedrawEvent method AFTER having the sketchpad released


- compile... no velociraptor attack, good...


- tested it in orbiter... hmm, fail....


- investigated possibility of it working by blitting from the same surface... yep! that checks out :hmm:...


- wrote this post in search of a "real" answer to my problem....


- hit "Post Quick Reply"... now we wait...

 

[tblaxland]

I just noticed this. Does it help?

What is the oapiBlt() function doing when a source or a target rectangle is partially outside the surface. Does it clip ? Or does it quit ?

AFAIR quit, i.e. doing nothing.

 

[dbeachy1]

From what I can see your code is blitting the bitmap correctly and you imported the bitmap as a resource correctly as well. Are you 100% certain that surf and vcRsc_reht_tape are valid surface handles (i.e., is each initialized correctly)? Can you step through it in the debugger and examine each variable in the oapiBlt call? Triple-check that each coordinate and dimension is correct -- if anything is out-of-bounds, even by one pixel, it won't blit.

The other thing to double-check is that the VC texture to which you are blitting is marked as dynamic in the msh file (i.e., has a trailing 'D': "foo.dds D").

EDIT:
One more thing: double-check that your bitmap resource is a standard 24-bit-color bitmap.

 

[Moach]

From what I can see your code is blitting the bitmap correctly and you imported the bitmap as a resource correctly as well. Are you 100% certain that surf and vcRsc_reht_tape are valid surface handles (i.e., is each initialized correctly)? Can you step through it in the debugger and examine each variable in the oapiBlt call? Triple-check that each coordinate and dimension is correct -- if anything is out-of-bounds, even by one pixel, it won't blit.

The other thing to double-check is that the VC texture to which you are blitting is marked as dynamic in the msh file (i.e., has a trailing 'D': "foo.dds D").

lets see,

"D" - check! model-bound texture is dynamic and able for blit to/from itself
coords - check! tested by successful self-blitting (worth checking again with bitmap resource)
handle - not checked... will se about that (code checks out from samples comprasion, but worth checking again)

so that narrows things down a lot... i am most certain now that there's something off with those handles... i believe it's being init'ed in the clbkLoadVC function via oapiCreateSurface - by looking at sample code from the DG and Shuttle-A, i could not find any disparities that would imply a reason for failure in mine...
it seems i've done all that was done in the samples, but certainly i haven't, otherwise i wouldn't be having troubles

i'll check the handle for a NULL... i'm oretty certain that would be the case, but then, have also no idea why the thing is NULL, so that only pushes the question one step further...


so to keep things at a pace - assuming i do have a NULL handle - why is that so?
and above all -- how do i fix it?


thanks man!


**edit**

24-bit - check!

 

[dbeachy1]

If the handle is null it means that the resource didn't load for some reason. In that case, double-check that the resource is present in the DLL and that the resource ID in the code is using matches the ID in the .rc. file. You can set a breakpoint on where the resource loads and step across it in the debugger, checking that the handle returned by the load is OK.

If it still won't blit the bitmap, you can try to narrow it down further by drawing text to the same surface and seeing if that shows up: if so, then the destination surface is OK. You can also try (as a test) doubling the designated size of the area to which you are blitting just to rule out any "area-is-too-small-for-the-bitmap" conditions. You can also try blitting the same bitmap to another area on the panel where a bitmap blits successfully (if there are any others, that is ) to see if it blits to that area: if it does, then it points to a problem with the other area's surface handle, dimensions, or texture, but if it doesn't blit to the other area either then it points to a problem with the bitmap handle or the bitmap itself.

One other test you can do is grab a bitmap that you know works (e.g., one of the little indicator arrows from the default DG's panel) and blitting that bitmap to your area. That would rule out any problem with the bitmap itself.

Isn't troubleshooting fun? Hang in there, mate, you'll nail it. :thumbup: