Question/Letter to the devs
-
Hello BMS devs (And anyone else who has information about this!).
Thanks for continuing your work on making BMS a better sim.
A long time ago I made a software called GPT (https://github.com/gigurra/gpt)
for grabbing and sending mfd/display texture data to remote computers. This worked
through a d3d hook. I made it to offload extra rendering to other computers and to
keep full screen ingame - in short for performance (which was greatly improved vs
running game windowed + builtin external mfd renderer)Recently I’ve wanted to remove my d3d hook - especially since people have informed me
that bms has gone 64bit (4.33) and GPT’s native code uses some rather evil 32bit-only-librariesQuestion: Does BMS expose the offscreen rendering surface/FBO containing mfd texture
data in some named shared memory? If so - What is the name/path to/of that shared
memory and its format, size, etc? If I could grab the data from there instead I wouldn’t
need to attach a d3d hook to the game.I’m doing this mostly as a courtesy to everyone using GPT atm (Myself I’ve taken a break from siming)
-
the answer is yes. there is a TEX shared mem.
to save you some of the reworking needed.
IIRC, lightning’s MFDE allows server/client option
check it out. -
the answer is yes. there is a TEX shared mem.
to save you some of the reworking needed.
IIRC, lightning’s MFDE allows server/client option
check it out.Thanks but I’m only interested in getting the data source for now. I already have the rest solved. Just the named shared memory that is used as a source is more than enough. Unless that is Lightning’s data source and there is public source code available that shows this use.
-
it’s above my pay grade,
but try “FalconTexturesSharedMemoryArea”however,
I’m pretty sure it still in the same place it has been -
For info, windowed mode is also not a performance problem anymore.
Gr Falcas
-
For info, windowed mode is also not a performance problem anymore.
Gr Falcas
Good to know, but being a GSync monitor used I still have to have fullscreen ;).
Also I want the displays rendered by a secondary computer. I have too many other uses (non-bms) for my primary computer and dont want to connect multiple screens to it. -
it’s above my pay grade,
but try “FalconTexturesSharedMemoryArea”however,
I’m pretty sure it still in the same place it has beenOk - I will try and see if there is any data there. Anyone know the format of this area?
Like… any Header at the start of it saying what resolution of the data it contains?Or should I just assume some resolution and a straight up rgba blob of bytes?
-
Yes, having the option to export to a different PC is good.
I have 6 screens connected to one single PC running BMSGr Falcas
-
FalconTexturesSharedMemoryArea
Any support you need past that is probably a question of reading the code that lightning generously shares for the working tool that already does what you are describing and is maintained (so really perhaps you don’t have to if your interests lie elsewhere now; up to you but anyone using your tool can flip to MFDE quite easily, either way: thank you for sharing your work to this point!).
-
Searching google for that string I ended up finding out that:
"- Fixed exporting displays to shared texture memory area (will work again in the same way that it did for OpenFalcon and BMS 2): Setting g_bExportRTTTextures to 1 will create a shared texture memory area (even w/o external displays enabled), named “FalconTexturesSharedMemoryArea”. This does work as well with double RTT resolution! The shared mem area is not updated every frame, but every g_nRTTExportBatchSize frame (defaults to 2). "
A bit more searching ended up at github where it indicates it’s using a Microsoft format called DDS:
With some example code here:
https://github.com/Karethoth/MFDExtractorServer/blob/master/src/ImageCache.cppLooks fairly straight forward. Now the only interesting part is how nasty enabling the shm might be for ingame fps ;).
Thanks for answering - This is all I need!
-
what you doing
-
This post is deleted! -
Hey Yoda,
Searching google for that string I ended up finding out that:
Looks fairly straight forward. Now the only interesting part is how nasty enabling the shm might be for ingame fps ;).Make your own copy and release mutex. Then process your own copy. Then perf isn’t as bad as it used to. memcpy is cheap too. You can also use an extremely short or instant mutex timeout to step on Falcon’s toes less.
Make sure to profile memory usage. Ideally your Java code shouldn’t make memory allocations other than on program startup. I’m not kidding, on Android app that I co-developed it murdered performance by 3x or more.
sh