Shared memory documentation
-
The supposed shared memory texture area is just full of zeroes, even after doing the stuff in the zip
(add the config file settings, set 512 512 in the ckpitart, enable normal mfd extractors )There is a shared memory area created named âFalconTexturesSharedMemoryAreaâ (of about 4 MB size), but it just contains zeros.
Apparently my viperpits account has disappeared in their site reset, sigh, last time I applied for membership it took 2 mths :).
Anyway if you can see some error in hwo i read shared memory please tell me:void doRgbExport(const char * name, const char * outputFile) {
const HANDLE handle = OpenFileMapping(FILE_MAP_READ, FALSE, name);
if (handle != NULL) {
const void * view = MapViewOfFile(handle, FILE_MAP_READ, 0, 0, 0);
if (view != NULL) {MEMORY_BASIC_INFORMATION info;
memset(&info, 0, sizeof(MEMORY_BASIC_INFORMATION));
VirtualQuery(view, &info, sizeof(MEMORY_BASIC_INFORMATION));printf(âShared memory size of %s is %ld bytes\nâ, name, info.RegionSize);
//memcpy(s_bmsTexArea, view, info.RegionSize);
int i;
for (i = 0; i < info.RegionSize; i++) {
unsigned int v = ((unsigned char *) view)_;
if (v != 0) {
printf(âThere is data in %s\nâ, name);
break;
}
}UnmapViewOfFile(view);
} else {
printf(âUnable to get view for %s\nâ, name);
}
CloseHandle(handle);
} else {
printf(âUnable to get handle for %s\nâ, name);
}
fflush(stdout);}
void display() {
printf(â\n\nâ);
doRgbExport(âFalconSharedOsbMemoryAreaâ, âFalconSharedOsbMemoryArea.smemâ);
doRgbExport(âFalconSharedMemoryAreaâ, âFalconSharedMemoryArea.smemâ);
doRgbExport(âFalconSharedMemoryArea2â, âFalconSharedMemoryArea2.smemâ);
doRgbExport(âFalconTexturesSharedMemoryAreaâ, âFalconTexturesSharedMemoryArea.rgbâ);}
result:
Shared memory size of FalconSharedOsbMemoryArea is 4096 bytes
There is data in FalconSharedOsbMemoryArea
Shared memory size of FalconSharedMemoryArea is 4096 bytes
There is data in FalconSharedMemoryArea
Shared memory size of FalconSharedMemoryArea2 is 4096 bytes
There is data in FalconSharedMemoryArea2
Shared memory size of FalconTexturesSharedMemoryArea is 4198400 bytesFalconTexturesSharedMemoryArea only contain zeroes!
Update:
I know now, it will not work. That program simply just copies drawn pixels from one desktop to another :/. What I need is to be able to get the texture data without it being drawn in a separate window :/_ -
âFalconTexturesSharedMemoryAreaâ is as you say blank, its not until it is activated by adding a line to the FalconBMS.cfg
Set g-bExportRTTTextures 1
once started falcon begins to draw images to this area, and it is this! that drags the FPS down, Not the extractor program its self.
the size of this area and the size and position of the MFDâs, HUD, and some gauges
is set in the 3Dcockpit.dat file.some thing like this (This is from Falcon OF)
MED-extractor and also Jshepardâs program can take a copy from this area and show on another screen.
Lightningâs, Jshepardâs program and falcon BMS, all extract MFDâs in exactly the same way by copying images from this area.
Update:
I know now, it will not work. That program simply just copies drawn pixels from one desktop to another :/. What I need is to be able to get the texture data without it being drawn in a separate windowYes, it copyâs from one desktop to another 2D, and it also copyâs from the SharedMemoryArea to the desktop 3D.
RebootâŚâŚ
-
Lightningâs, Jshepardâs program and falcon BMS, all extract MFDâs in exactly the same way by copying images from this area.
Actually thatâs not completely correctâŚthe built in display extraction uses a different approach. That is how, for some cards and drivers, the frame rate hit for using extraction is rather less than when you turn on the texture export capability. Itâs not really material to your main point of courseâŚjust adding information.
-
Thanks for the correction Mark, (very interesting) but is it still not just copying images from the one place to the other, or is it more advanced than that, capturing data before itâs drawn ???⌠just what GiGurra is asking about.
-
After reading the help.txt in the zip it seems like you still have to enable the built in extractor for bmsâŚhmmâŚwhich defeats my purposeâŚBut I will see what happens anyway for fun
When MFD-Extractor first started, it could only capture 2D images from a set of screen coordinateâs,
(then the next version) after manually turning on the âtexture exportâ could capture 3D images from âagainâ another set of manually in-tested coordinateâs this time from the âSharedMemoryAreaâ,
latter, MFD-Extractor could automatically switch-on âtexture exportâ and get the coordinateâs its-self from the 3Dcockpit.dat file.so by using MFD-Extractor to turn on the âtexture exportâ was just a tidy way of doing it and again in Falcon BMS. turning on âtexture exportâ can be done ether manually or by activating it with the built in extractor.
-
âFalconTexturesSharedMemoryAreaâ is as you say blank, its not until it is activated by adding a line to the FalconBMS.cfg
Set g-bExportRTTTextures 1
once started falcon begins to draw images to this area, and it is this! that drags the FPS down, Not the extractor program its self.
the size of this area and the size and position of the MFDâs, HUD, and some gauges
is set in the 3Dcockpit.dat file.some thing like this (This is from Falcon OF)
MED-extractor and also Jshepardâs program can take a copy from this area and show on another screen.
Lightningâs, Jshepardâs program and falcon BMS, all extract MFDâs in exactly the same way by copying images from this area.
Yes, it copyâs from one desktop to another 2D, and it also copyâs from the SharedMemoryArea to the desktop 3D.
RebootâŚâŚ
Iâm sorry but the FalconTexturesSharedMemoryArea still just contains zeroes for me (the other areas I can read fine.)
Here is my falcon bms.cfg from the config folder : http://gigurra.se/falcon/falcon%20bms.cfg
and here is my 3dcockpit.dat : http://gigurra.se/falcon/3dckpit.datIâve also tried editing the spelling to
set g_bExportRTTTextures 1
set g_nRTTExportBatchSize n (tried n = 1,2 and 5)Iâve also tried setting (for ALL F-16 3dcockpit files and the root one)
rttTarget 600 600 32;But still, FalconTexturesSharedMemoryArea = 00000âŚ. (4 MB of zeros)
Lightningâs programâs MFDs donât work for the new bms afaik (They are blank. Other data is read fine)
-
What is this âYoda crazy shitâ at the bottom of your .cfg file ?
-
Just a little info,
the rttTarget (in red) is the size of the SharedMemoryArea
the numbers (in red) are the positioning and size of the left and right MFDâsâŚâŚ 225x225 pixels
// 3-d cockpit description
// N-pit
// Last change May 17 2007
// by Nanard// Boresight cross height
boresighty 0.75;// Shared render to texture target size. width height depth. depth needs to be 32 for texture alpha to work default is primary
rttTarget 512 512 16;// 3-d coords for Upper left. Upper Right and Lower Left // Rtt Top. Left. Right. Bottom. BlendMode. Alpha
// BlendModes are a = alpha blending. c = color blending. g = texture gouraud. t = texture. default = g
// example hud with 0.5 vertex alpha: hud 20.0 -2.0 0.0 20.0 2.0 0.0 20.0 -2.0 4.0 5 5 260 260 a 0.5;
// first number is toward you / away from you
// second number is left and right + number is right. - number is left
// third number is up / down - number is up. + number is down
// 0. 0 is in the middle of the screen (apprxomiately)hud 20063.0 -2750.0 -618.0 20063.0 2750.0 -618.0 20063.0 -2750.0 4902.0 0 0 280 280 c;
pfl 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 281 0 481 70 c;
ded 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 281 71 481 141 c;
rwr 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 482 0 600 118 c;
mfdleft 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 375 375 600 600 c;
mfdright 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 375 145 600 370 c;
hms 20.063 -4.000 -4.000 20.063 4.000 -4.000 20.063 -4.000 4.000 0 314 286 600 c; -
Just a little info,
the rttTarget (in red) is the size of the SharedMemoryArea
the numbers (in red) are the positioning and size of the left and right MFDâs
// 3-d cockpit description
// N-pit
// Last change May 17 2007
// by Nanard// Boresight cross height
boresighty 0.75;// Shared render to texture target size. width height depth. depth needs to be 32 for texture alpha to work default is primary
rttTarget 512 512 16;// 3-d coords for Upper left. Upper Right and Lower Left // Rtt Top. Left. Right. Bottom. BlendMode. Alpha
// BlendModes are a = alpha blending. c = color blending. g = texture gouraud. t = texture. default = g
// example hud with 0.5 vertex alpha: hud 20.0 -2.0 0.0 20.0 2.0 0.0 20.0 -2.0 4.0 5 5 260 260 a 0.5;
// first number is toward you / away from you
// second number is left and right + number is right. - number is left
// third number is up / down - number is up. + number is down
// 0. 0 is in the middle of the screen (apprxomiately)hud 20063.0 -2750.0 -618.0 20063.0 2750.0 -618.0 20063.0 -2750.0 4902.0 0 0 280 280 c;
pfl 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 281 0 481 70 c;
ded 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 281 71 481 141 c;
rwr 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 482 0 600 118 c;
mfdleft 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 375 375 600 600 c;
mfdright 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 375 145 600 370 c;
hms 20.063 -4.000 -4.000 20.063 4.000 -4.000 20.063 -4.000 4.000 0 314 286 600 c;Yes I know these positions are outside, BUT: I also tried size 600 600 32 but it made no difference whatsoever. (rttTarget 600 600 32);
-
Lightningâs programâs MFDs donât work for the new bms afaik
That is why I posted Jshepardâs program, now that works fine in BMS.
-
That is why I posted Jshepardâs program, now that works fine in BMS.
Yes but I believe he actually doesnât use shared memory. He relies on the built in extractor windows being up and running, and then he can use windows APIs to read the pixels of those windows.
Btw here is a sample source code to test shared memory
http://gigurra.se/falcon/src.txt
It reports data in all areas except the texture area. I can also program my own shared memory areas and it would report data there as well. -
I also tried size 600 600 32 but it made no difference
Be careful changing the rttTarget it is very sensitive about size.
-
He relies on the built in extractor windows being up and running,
Now youâve lost me, what is this âbuilt in extractor windowsâ .
-
Be careful changing the rttTarget it is very sensitive about size.
Same result when keeping rttTarget 512 512 and limiting the paint areas to <512
-
Now youâve lost me, what is this âbuilt in extractor windowsâ .
BMS has a built in mfd extractor. It opens its own mfd windows.
-
Yes but I believe he actually doesnât use shared memory. He relies on the built in extractor windows being up and running, and then he can use windows APIs to read the pixels of those windows.
Iâm still lost
Jshepardâs program is copying images from the âshared memory areaâ, just like Lightningâs MFD-E. nether of these programs getâs its data from shared memory, because there isnât any MFD data in shared memory.
-
Falcon MFD-Extractor read-me
http://dl.dropbox.com/u/5918219/Stephen/Falcon%20MFD%20Extractor%20v0.1.10.0%20User%20Manual.docx
http://dl.dropbox.com/u/5918219/Stephen/Falcon_MFD_Extractor_v0.2.0.2_User_Manual.doc
Edit: from LightningâŚâŚread-me v0.1.10.0
Enabling 3D Exporting in OpenFalcon
To use Falcon MFD Extractor in 3D Cockpit Mode with OpenFalcon, you need to configure OpenFalcon to export image data from the 3D cockpit to shared memory. This involves editing the FalconBMS.cfg file, located in your OpenFalcon installation folder.
Telling OpenFalcon to export images from the 3D cockpit
To enable 3D Cockpit image exporting from OpenFalcon, you will need to add the following line to the end of your FalconBMS.cfg file:set g_bExportRTTTextures 1
This will tell OpenFalcon to export certain pieces of the 3D cockpitâs sensor/instrument imagery, to a bitmap in shared memory, at the coordinates defined in the 3dckpit.dat file (see the section in this document, entitled Obtaining 3D Cockpit Image Source Coordinates from OpenFalconâs 3D Cockpit Definition Files, for more details on the 3dckpit.dat file)
Telling OpenFalcon How Often to Update the Exported Image
OpenFalcon has another setting that you can add to your FalconBMS.cfg file, which determines how often OpenFalcon updates the shared memory image. This setting looks like this:set g_nRTTExportBatchSize 5
The g_nRTTExportBatchSize parameter works like this: Suppose we use the symbol n to refer to the value that youâve assigned to this parameter. OpenFalcon then says, every (2^n) +1 frames â that is, every ((2 to the power of n) +1) frames â Iâll export a new image to shared memory. Letâs look at a couple possible values and their effects:
Parameter Value Effect
set g_nRTTExportBatchSize 1 Shared memory image gets updated every 3 frames
set g_nRTTExportBatchSize 2 Shared memory image gets updated every 5 frames
set g_nRTTExportBatchSize 3 Shared memory image gets updated every 9 frames
set g_nRTTExportBatchSize 4 Shared memory image gets updated every 17 frames
set g_nRTTExportBatchSize 5 Shared memory image gets updated every 33 frames
set g_nRTTExportBatchSize 6 Shared memory image gets updated every 65 frames
set g_nRTTExportBatchSize 7 Shared memory image gets updated every 129 frames
set g_nRTTExportBatchSize 8 Shared memory image gets updated every 257 frames
set g_nRTTExportBatchSize 9 Shared memory image gets updated every 513 frames
set g_nRTTExportBatchSize 15 Shared memory image gets updated every 32769 framesSince exporting these images to shared memory tends to have quite an impact on your in-simulation Frames-Per-Second display rate, OpenFalcon lets you, the user, decide how often you want these shared-memory images to be updated.
Setting the g_nRTTExportBatchSize parameter to low values (resulting in frequent refreshes of the shared memory bitmap) will have definite adverse effects on your in-game FPS rates in Falcon; setting the g_nRTTExportBatchSize parameter to higher values will result in slow output rates. Thatâs the tradeoff.
If you do not specify a value for this parameter, the default value is :
set g_nRTTExportBatchSize 9PS: Iâm not a programer, Iâm just one of the Beta Testers that helped Lightning with MFD-Extractor.
Reboot.
-
Thanks for the correction Mark, (very interesting) but is it still not just copying images from the one place to the other, or is it more advanced than that, capturing data before itâs drawn ???⌠just what GiGurra is asking about.
Weâre stepping perilously close to the edge of my knowledge here but I think the point is that the internal display export uses swap chains which avoids having to render to textures held in system memory. The latter is computationally expensive and painful and increasingly poorly supported by the graphics devices (the normal case is to you want zap bits to the card super fast and donât care about getting bits back to main memory more or less ever so why make that path optimized at allâŚor some such logic). At any rate, thatâs my weak understanding and would go to explaining why the render to texture thing is generally going to be slower in performance terms.
-
âŚâŚperilously closeâŚknowledgeâŚswap chainsâŚcomputationally expensiveâŚpainfulâŚpoorly supportedâŚzap bitsâŚsuch logicâŚunderstandingâŚtexture thingâŚperformanceâŚ
So what your saying, its more advanced than just copying an image from A to B
Thanks Mark.
WellâŚâŚ GiGurra, did you get all of that, if you quickly put together an extractor app then I will volunteer as your beta tester,
what do say to that.
Reboot.
-
In the sense that Phileas Fogg and the space shuttle can both claim to have circumnavigated the earth, yes, different technology same result on your screenâŚeventually.