YAME64 suite
-
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
-
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
Known issue: see https://www.yame64.com/how-to/ for more details
-
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 worked. Thanks.[/i][/i][/i][/i][/font]
-
That worked. Thanks.
Is there any chance for a fixed build of the current YAME64 version?
Thank you very much
MircoGesendet von iPhone mit Tapatalk
-
+1 to that
-
please:mrgreen:
-
+100000000000
-
+1
-
+0 plenty of alternatives
Gesendet von meinem SM-G930F mit Tapatalk
-
+0 plenty of alternatives
Gesendet von meinem SM-G930F mit Tapatalk
None that include the ATD option, afaik.
-
None that include the ATD option, afaik.
-
Well shut my mouth.
Thanks for enlightening me.
it’s been a long time since I last used MFDE.
Time to give it another look. -
Show me a public available version with CPD then
-
+0 plenty of alternatives
Gesendet von meinem SM-G930F mit Tapatalk
Got the MFD extraction of BMS 4.35 set up at the day of release, but some features are unique and I would highly appreciate a fixed version if it’s just a small adjustment in code.
Good for you you have alternatives, there is none for me at the time being using a CPD and a LAN based Interface system with different PCs.
ThanksGesendet von iPhone mit Tapatalk
-
Got the MFD extraction of BMS 4.35 set up at the day of release, but some features are unique and I would highly appreciate a fixed version if it’s just a small adjustment in code.
Good for you you have alternatives, there is none for me at the time being using a CPD and a LAN based Interface system with different PCs.
ThanksGesendet von iPhone mit Tapatalk
Helios ICe profile with integrated CPD even more as Helios is a building platform you could change your CPD. Second alternative is