YAME64 suite
-
I think it’s DX11 related.
All the best,
Uwe
-
MFD extraction (basically everything texture-related) won’t work for me on the current beta that I’m using (2.0.0.43 I believe) when using BMS 4.35.
All the best & a happy new year to all!
Uwe
-
I wouldn’t say that this is DX11 related. Prior to 4.35 BMS was able to write the texture in either 600x600 or 1200x1200. With 4.35 it’s fixed to 1200x1200.
Can’t speak for Yame as I have no access to the code. But for MFDE there are 2 version of 0.6.3 the “older” one sets the resolution in the program code by reading the rttdoubleresolution parameter (Not present In 4.35) whereas newer version read the texture homage size from the memory data.
So older MFDE showed the same weired image as no doubleresolution in config defaulted back to 0 hence assuming 600x600 whereas BMS writes 1200x1200Gesendet von meinem SM-G930F mit Tapatalk
-
I’m the same as Uwe
Roccio must be continuing in secret mode. -
I’m the same as Uwe
Roccio must be continuing in secret mode.Eh eh eh no secret mode, just opened the project for a shot yesterday.
-
Sorry oakdesign, maybe I make some mistake :shock: but, using BMSFlightData.exe tools, it seems me that BMS 4.35 writes texture only in 600x600 mode, instead BMS 4.34 in 600x600 and 1200x1200 according setting into Falcon BMS.cfg .
-
Sorry oakdesign, maybe I make some mistake :shock: but, using BMSFlightData.exe tools, it seems me that BMS 4.35 writes texture only in 600x600 mode, instead BMS 4.34 in 600x600 and 1200x1200 according setting into Falcon BMS.cfg .
Nope 4.35 RTT size is fix 1200 1200
As well as the size reading directly from the F4TexSharedMemory
-
Tanks oakdesign. I see that BMS 4.35 export texture RTT 1200x1200 way.
Now I have another strange thing:
- I wrote a little windows app that the exports texture from the shared memory, transmit on usb and than a little linux app on Raspberry that shows them.
It works fine with BMS 4.34 ( working in 1200x1200 mode ), but it shows some weird image with BMS 4.35. I expected that it works fine also with BMS 4.35, and I cannot understand what it is my fault.
Using a stand alone windows program to show raw bit image that I saved, I see a strange thing: to see a good image i must declare that raw texture has width = 1216 point; if I declare 1200 it again shos strange weird image. My simple app only get a pointer to texture shared memory, adds 128 bytes to jump the header, and than copy the texture data only stripping the Alpha byte, changing from 32 to 24 bit and saving it in a file.
I remarks that it works fine with 4.34 but with 4.35 it need to handle bitmap like it was 1216x1200 pixel.
I attach two image of tha same file, using 1200x1200 and 1216x1200.
Thankyou in advance,
mauro
- I wrote a little windows app that the exports texture from the shared memory, transmit on usb and than a little linux app on Raspberry that shows them.
-
Hm, “invalid attachment”. Can you upload those images to imgur. com or similar? Thanks!
Uwe
-
Strange hoover, if I click on the Attachment it opens their…maybe because they are on my pc. They are only two capture ( .png file ) made with the windows10 native tool.
These are gdrive’s links
https://drive.google.com/file/d/1KDXQG2v8xqc7K4FMd02kFR8q4xKn9zHN/view?usp=sharing
https://drive.google.com/file/d/1Fy9YZdjVs_GN2HyNi_CspxfKXMDmxc8P/view?usp=sharing
Mauro -
I have the same issue , my mfds shown like the 1200x1200 pixture of yours…
can u please tell me step by step how you made it 1216x1200? -
Thanks for updating the attachments / links. That’s what the mfds look like on my end as well using the latest beta (2.0.0.46). I’ll forward your findings to the tester list.
All the best,
uwe
-
Hi giannis,
I opened a similar thread in the “Technical Support” section of forum with the hope that developers answer it. Maybe it should useful if also you post your question in that thread.I do not know if my solution can work for you: to extract textures from shared memory I used a my self made software, so i can, in simple way, apply the trick that I explain…I do not figure how you apply it using a third part software.
Let me know if also you use a your software and like to know the algorithm that I apply: in this case I’ll be very happy to explain it to you, but if you uses a third part sw, only hope is in developers’s answer.
Situation is very weird, because I know people that use Yame, or other extraction tool, without troubles; so I do not understand the situation: maybe also some different setting in Falcon configuration affects the way of working of shared mem.
Let me know if you like more info.
Mauro
-
Hi giannis,
I opened a similar thread in the “Technical Support” section of forum with the hope that developers answer it. Maybe it should useful if also you post your question in that thread.I do not know if my solution can work for you: to extract textures from shared memory I used a my self made software, so i can, in simple way, apply the trick that I explain…I do not figure how you apply it using a third part software.
Let me know if also you use a your software and like to know the algorithm that I apply: in this case I’ll be very happy to explain it to you, but if you uses a third part sw, only hope is in developers’s answer.
Situation is very weird, because I know people that use Yame, or other extraction tool, without troubles; so I do not understand the situation: maybe also some different setting in Falcon configuration affects the way of working of shared mem.
Let me know if you like more info.
Mauro
I don’t know how you access F4TextSharedMemory mapping file. What I can say that the tools/library I’m using and working with didn’t need any code changes to be operational with 4.35. So maybe have a look on one of the tools that is working out of the box with 4.34 and 4.35
https://github.com/lightningviper/lightningstools/tree/master/src/F4TexSharedMemTester
-
Thanks Oak.
-
Uwe, I noted that 1200x4=4800 it is not multiple integer of 256, instead adding 64 to 4800 we obtain 4864 that is multiple integer of 256: 4864/256 = 19…maybe it could be a simple misalignment problem handled in a different way from nvidia or amd drivers.
Ciao,
Mauro -
I don’t know how you access F4TextSharedMemory mapping file. What I can say that the tools/library I’m using and working with didn’t need any code changes to be operational with 4.35. So maybe have a look on one of the tools that is working out of the box with 4.34 and 4.35
https://github.com/lightningviper/lightningstools/tree/master/src/F4TexSharedMemTester
Hi oakdesign,
As suggested, I’ve downloaded the tool to test the “FalconTexturesSharedMemoryArea”, and all I get is a blackscreen (of course with BMS up and running). I’ve got an NVidia GPU.
Just to clarify and add infos, I’ve opened the shared memory for textures, and I’ve inspected the DDS header (the format the texture is offered in the shared memory, for whom it may concern…); the DDS header is a little bit messy (https://docs.microsoft.com/en-us/windows/win32/direct3ddds/dds-header) and I get the infamous 4864 value at the “DWORD dwPitchOrLinearSize;” field. I’ve read at a different link on MSDN, that field is defined “unreliable” (stated here: https://docs.microsoft.com/en-us/windows/win32/direct3ddds/dx-graphics-dds-pguide), and you should compute it by yourself. If I compute it by myself I obtain what I would expect, 4800, which divided by 4 yields the expected 1200 which is exaclty the number of columns in a row. But as mauro said, if I add 16 bytes each row, I obtain the correct image.
is this an alignment problem? is this the nvidia drivers (indeed @oakdesign, and whoever got this working: what GPU do you have?)
Thank you for your time!
Giuseppe -
Thanks to Mauro for the illuminating infos about this problem. I do have a NVIDIA GPU and I suffer the very same problem.
I’ve written a small C/C++ code, which shows the problem and implements the fix suggested by mauro: I don’t pretend you to compile it (it depends on several external libs, SFML, spdlog, headers from DX, etc…), but it’s a suggestion for the YAME developers: The code is here: https://gist.github.com/giupo/27dcf996609659a167b8de5ccaa6d717. When I copy the contents of the texture buffer every 1200 bytes, I pad 16 bytes from the source buffer.
The relevant code is here:
[font] for(unsigned int i = 0, j = 0; j < texture_size; i += bytes_per_pixel, j += bytes_per_pixel) { //changes from BGRA to RGBA texture_buffer[j] = texture_data[i]; // R texture_buffer[j + 1] = texture_data[i]; // G texture_buffer[j + 2] = texture_data[i]; // B texture_buffer[j + 3] = 0xFF; // texture_data[i]; // A 0xFF // -----> here is the trick <----- if(j % 1200 == 0) { i += 16; } } I will attach the results I get without and with the padding. [attach]42688[/attach][attach]42689[/attach] HTH, Giuseppe[/i][/i][/i][/i][/font]
-
Thanks to Mauro for the illuminating infos about this problem. I do have a NVIDIA GPU and I suffer the very same problem.
I’ve written a small C/C++ code, which shows the problem and implements the fix suggested by mauro: I don’t pretend you to compile it (it depends on several external libs, SFML, spdlog, headers from DX, etc…), but it’s a suggestion for the YAME developers: The code is here: https://gist.github.com/giupo/27dcf996609659a167b8de5ccaa6d717. When I copy the contents of the texture buffer every 1200 bytes, I pad 16 bytes from the source buffer.
The relevant code is here:
[font] for(unsigned int i = 0, j = 0; j < texture_size; i += bytes_per_pixel, j += bytes_per_pixel) { //changes from BGRA to RGBA texture_buffer[j] = texture_data[i]; // R texture_buffer[j + 1] = texture_data[i]; // G texture_buffer[j + 2] = texture_data[i]; // B texture_buffer[j + 3] = 0xFF; // texture_data[i]; // A 0xFF // -----> here is the trick <----- if(j % 1200 == 0) { i += 16; } } I will attach the results I get without and with the padding. [attach]42688[/attach][attach]42689[/attach] HTH, Giuseppe That's fantastic, now I hope the smart guys working on YAME 2.x can incorporate it!![/i][/i][/i][/i][/font]
-
Great looking program for a man my age with my vision.
I installed the latest version on the same drive as Falcon BMS 4.35 into folder E:\Program Files\YAME64. When I run the program the Global tab is blank and all the buttons on the bottom are greyed out. So it looks like the program can’t find Falcon and I can’t point it toward it.
Thanks,
Doug