YAME64 suite
-
For BMS 4.35 :
Yame64 doesn’t extract mfd’s, rwr, ded. All the other gauges work . ( BMS 4.33 is installed and 4.34)Same issue MFDE has. It seems the switch to DX11 gives issues regarding extractions, mostly to Nvidia users, some others report no issues.
Is already mentioned here: https://www.yame64.com/how-to/Which buttons on keyboard can i use for the CPD ?
There’s no 1 answer to this. It depends on the BMS keyfile you use.
-
Same issue MFDE has. It seems the switch to DX11 gives issues regarding extractions, mostly to Nvidia users, some others report no issues.
Is already mentioned here: https://www.yame64.com/how-to/There’s no 1 answer to this. It depends on the BMS keyfile you use.
no issues with MFDE on Nvidia apart of the freeze issue which is not related to to tool used but a bug in BMS shared memory thread safety. So any tool using F4TexSharedMemory might face that issue at the moment
-
so if in a future 4.35 update the extraction problem( that causes RTT freezing) is solved, does this mean that YAME MFD’s extraction will carry on normally?
or it’s DX11 related issue? -
YAME MFDs will not work after the freeze fix.
-
YAME MFDs will not work after the freeze fix.
What is changed? In my dev version of yame the extraction works well.
-
What is changed? In my dev version of yame the extraction works well.
even on 4.35? the MFD’s not working since the 4.35 release…all other gauges work fine
-
even on 4.35? the MFD’s not working since the 4.35 release…all other gauges work fine
Yes on 4.35, but on my yame version, not the public one
-
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