SDK Question Night Vision simulation

JMW

Aspiring Addon Developer
Joined
Aug 5, 2008
Messages
670
Reaction score
89
Points
43
Location
Happy Wherever
Hi all.

I want to have night vision in a .dll I'm compiling.

Did anyone ever find out how Vanguard coded this in his CameraMfd?

Regards,

JMW
 
Last edited:
This is not night vision, but I can guess it was calculation of luminosity of the points of the surface (possibly through transformation into HSL) and then mapping it back into the green subspace.
 
calculation of luminosity of the points of the surface (possibly through transformation into HSL) and then mapping it back into the green subspace.

Now this line would easily qualify for a star trek episode! :lol:
 
Now this line would easily qualify for a star trek episode! :lol:
P: Commander Data report.
D: Captain, an interesting phenomenon has occurred. Apparently a programmer is trying to map subspace using a...
P: What is it Data?
D: Using an archaic piece of software from the 21st early century.
P: Commander Troi are you getting anything?
T: Sir, I'm sensing, green...

I need to make a scenario for that :P
 
Right - so I guess the answer is no - from you guys anyhow.:rolleyes:
 
Have I not answered your question? No I did not disassemble the Camera MFD, but I told you the way to do it as I see fit:
1. Convert a RGB point into HSL.
2. Set the green component of the transformed point equal to the L component.
 
Thanks Wishbone - but that just flew over my head initially ! (not being qualified in such higher meta-physics :thumbup:)
I'll look into it - but I may need your help !
 
P: Commander Data report.
D: Captain, an interesting phenomenon has occurred. Apparently a programmer is trying to map subspace using a...
P: What is it Data?
D: Using an archaic piece of software from the 21st early century.
P: Commander Troi are you getting anything?
T: Sir, I'm sensing, green...

I need to make a scenario for that :P

G: Captain I'm seeing a lot of fluctuations in luminosity from several points on the surface. It's almost enough to overload my visor.
W: Captain, they're hailing us. They think we're some sort of..."probe."
 
Hi all.

I want to have night vision in a .dll I'm compiling.

Did anyone ever find out how Vanguard coded this in his CameraMfd?

Regards,

JMW

:tiphat:
SOURSE: Decompiling by IDA...
ANSWER: In the "device" night vision is realized by means of ambient_color change. Easily and simply :). Only it is necessary to reach orbiter's call IDirect3DDevice7::SetRenderState function interception .
Substitution

Code:
DWORD __stdcall fqSetRenderState (DWORD p,D3DRENDERSTATETYPE dwRenderStateType,  DWORD dwRenderState)
{
 if(dwRenderStateType == D3DRENDERSTATE_AMBIENT)
 {
  ISC.d3dcol_ambient_Save = dwRenderState;
  if(ISC.sToPoR &&  ISC.bSubstRwork && ISC.bStep2)
   if(ISC.d3dcol_ambient)
    dwRenderState =ISC.d3dcol_ambient; //0x0FF00FF00;
 }
 LPDIRECT3DDEVICE7 tr = (LPDIRECT3DDEVICE7)((DWORD*)p)[1];
 return tr->SetRenderState(dwRenderStateType,dwRenderState);
}
Return of old value
Code:
DWORD __stdcall fqEndScene(DWORD p)
{
 LPDIRECT3DDEVICE7 tr = (LPDIRECT3DDEVICE7)((DWORD*)p)[1];
 LPDIRECT3DDEVICE7 fq = (LPDIRECT3DDEVICE7)p; 
 if (ISC.sToPoR && ISC.bSubstRwork)
 {
  DWORD rez;
  rez = tr->EndScene();
  fq->SetRenderTarget(ISC.CorePr_RenSurf,0);
  fq->SetViewport(&ISC.ViewPort_Save);
  tr->SetTransform(D3DTRANSFORMSTATE_VIEW,&ISC.ViewTransformMatrix_Save);
  tr->SetRenderState(D3DRENDERSTATE_AMBIENT,ISC.d3dcol_ambient_Save);
  return rez;
 }
 return tr->EndScene();
}
PS Core principle of work of the CameraMFD - interception DX calls.
 
Thank you Bloodest - but WOW! That's way above my understanding threshold !!
Is there anyway you could explain (in my "cut & paste" programmers' language) what I should do next ? Please don't anyone say 'learn C++' ....

I've searched for the various terms in the code snippet, and very few come up anywhere - I'm lost!:confused:

Regards,

JMW
 
Some learning is required nonetheless. First off, have you got DirectX SDK? If not, please download and install. Then paste the snippet into your VS project, and fire the help by pressing F1 on the function names you don't understand. Remember to link to the Direct X libraries if you feel confident enough to compile stuff.
 
2SiberianTiger
Yes, yes ОБХСС... :cheers:

2JMW
The first and main - author CameraMFD hasn't published source codes. Hence an initial code - the closed property of the author. The copyright in Russia doesn't forbid studying of another's machine code and doesn't extend on the description of "a way of the decision of algorithmic problems". So here I can describe in general algorithm, without mentioning the key private moments of the realization, allowing to reproduce CameraMFD simple compilation.
It is very long road...
For example, DX it is necessary partially: only Includes DX7, Libs - aren't necessary. If you understand as it is possible to work with DX without Libs...
general algorithm
1. Orbiter call InitModule MFD module function.Here.
1.1. We work with import table in the loaded Orbiter module(
codeguru.earthweb.com/cpp/w-p/system/processesmodules/article.php/c12253/
paragraph 5.8, function RedirectAPI )
Us interest DDRAW.DLL and further an address field for DirectDrawCreateEx (Pointer #1 further P1).
1.2. We change value *P1 for the function-substitute address (F1), defined in module MFD.
2. At start of the scenario of Orbiter, for connection to DX causes DirectDrawCreateEx. As in P1 value F1 Orbiter causes not DirectDrawCreateEx and F1 lies.
F1 causes present DirectDrawCreateEx, but in Orbiter returns a substitute for the pointer on IDirectDraw7.
Approximately here so
Code:
#typedef DWORD (WINAPI *SS)(DWORD,DWORD, DWORD,DWORD); 
SS ptrDDrawLib_CrEx;
 
//step1
...
HMODULE ptrDDrawLib = LoadLibraryA("DDRAW.DLL");
ptrDDrawLib_CrEx = (SS)GetProcAddress(ptrDDrawLib,"DirectDrawCreateEx"); 
 
....
*(DWORD*)P1 = (DWORD)(DWORD*)F1; //change import table
 
//step2
int __stdcall F1(DWORD A1,DWORD A2, DWORD A3,DWORD A4)
{
DWORD rez = (ptrDDrawLib_CrEx)(A1,A2,A3,A4); // call true 
if(memcmp(ISC.guidIID_IDirectDraw7,(BYTE*)A3,sizeof(DWORD)*4) || rez)
return rez; //test GUID
DWORD * a = new DWORD[2];
a[0] = (DWORD)&ISC.fqVTBL_DirectDraw7;
a[1] = *(DWORD*)A2;
ISC.fqIDirectDraw7 = (DWORD)a;
*(DWORD*)A2= ISC.fqIDirectDraw7; //substitute
ISC.bStep1 = true;
return rez;
}

3. ISC.fqIDirectDraw7 it is the pointer on the virtual table of the class constructed by a technique
http:// www.codeguru.com/cpp/g-m/directx/directx8/article.php/c11453
Tables are accordingly redefined for
IDirectDraw7::
IDirect3D7::
IDirect3DDevice7::
IDirectDrawSurface7::
IDirect3DVertexBuffer7::


4. Thus in the previous post two functions from virtual tables are presented. Except a call of functions of interfaces DX corresponding to them they make "collateral" actions.



Here, in general, and all theory...



 
Last edited:
And will this work with other than D3D7 graphics clients? I guess not, and it needs to be rewritten for OGLA and D3D9 to make it working.
 
You mean something like that?
ogla-091024-2.jpg

No problem for OpenGL and DX9+, but no idea how to do it nicely in DX7.
 
The native graphic client of the Orbiter:
77.JPG
Certainly all works continuously. Two scenes on a 3D cocpit surface.
One of additional scenes ( that becomes a "conic mirror" of the VZOR) is deduced on the external MFD - for debugging. It is visible that the chamber position is chosen not absolutely successfully - the tail part of the Vostok can get to the review.
PS. Nevertheless DX7 bears in itself set of restrictions. Even having bypassed "soft restriction" of the Orbiter to draw everything - it will not turn out. I will notice that architecture DX 10 is opened with just the same "can opener" as DX7 :).
 
Back
Top