diff options
Diffstat (limited to '')
| -rw-r--r-- | results/scraper/box64/259 | 5 | ||||
| -rw-r--r-- | results/scraper/box64/2590 | 15 | ||||
| -rw-r--r-- | results/scraper/box64/2591 | 6 | ||||
| -rw-r--r-- | results/scraper/box64/2592 | 12 | ||||
| -rw-r--r-- | results/scraper/box64/2593 | 12 | ||||
| -rw-r--r-- | results/scraper/box64/2594 | 8 | ||||
| -rw-r--r-- | results/scraper/box64/2595 | 81 | ||||
| -rw-r--r-- | results/scraper/box64/2596 | 32 | ||||
| -rw-r--r-- | results/scraper/box64/2597 | 2 | ||||
| -rw-r--r-- | results/scraper/box64/2598 | 33 |
10 files changed, 206 insertions, 0 deletions
diff --git a/results/scraper/box64/259 b/results/scraper/box64/259 new file mode 100644 index 000000000..a799ec59d --- /dev/null +++ b/results/scraper/box64/259 @@ -0,0 +1,5 @@ +Running bedrock_server (Minecraft Private Server App) on Ubuntu Arm with Box64 - got some bugs inside server +(for reference, I'm opening a replica here, because I've mistaken and created it on box86 repo, [original link](https://github.com/ptitSeb/box86/issues/595)) + +So, for the Op Code you said, it seems to be ok now! But the skin issue is the same, just to point it. + diff --git a/results/scraper/box64/2590 b/results/scraper/box64/2590 new file mode 100644 index 000000000..9efcf9fb8 --- /dev/null +++ b/results/scraper/box64/2590 @@ -0,0 +1,15 @@ +Installation error Lav filters + + +Winlator@Frost 10.0 V3 +Wine: 9.2 +Box64: 0.3.5 +Device: xiaomi pad 6s pro + +[logs.txt](https://github.com/user-attachments/files/19999541/logs.txt) + +<!-- Failed to upload "IMG_20250501_144644_475.jpg" - + +Little nightmares 2 Crashes on loading + +[logs.txt](https://github.com/user-attachments/files/19999832/logs.txt) \ No newline at end of file diff --git a/results/scraper/box64/2591 b/results/scraper/box64/2591 new file mode 100644 index 000000000..d0ccb8792 --- /dev/null +++ b/results/scraper/box64/2591 @@ -0,0 +1,6 @@ +`cannot execute binary file: Exec format error` AFTER Steam successfully downloads and installs itself +I built and installed Box64 with Box32 enabled, and then ran the `install_steam.sh` script. Afterwards, I ran `box64 steam` and the Steam download window opened, it downloaded an extracted itself, and then began starting. Afterwards it got stuck in a loop where it would repeatedly try to start various Steam executables with the error `cannot execute binary file: Exec format error`, despite the Steam setup process working just fine with no such error. + +I `rm -rf`ed ~/steam and ~/.local/share/Steam and re-ran the whole process, this time outputting to a text file, and that file is attached below: + +[steam_box64_log.txt](https://github.com/user-attachments/files/19999829/steam_box64_log.txt) \ No newline at end of file diff --git a/results/scraper/box64/2592 b/results/scraper/box64/2592 new file mode 100644 index 000000000..97c4ea927 --- /dev/null +++ b/results/scraper/box64/2592 @@ -0,0 +1,12 @@ +The game does not determine +Little nightmares 2 Winlator frost 9.0 v3 Works, Winlator 10.0 v3 frost It doesn't work, the game requires installation Dx12 , I posted Vkd3d, But the game still requires an argument -dx12 , Why is it unknown possible dll Files have changed with version 9.0 V3 Logs + +[logs.txt](https://github.com/user-attachments/files/20002247/logs.txt) + + + + + + + + diff --git a/results/scraper/box64/2593 b/results/scraper/box64/2593 new file mode 100644 index 000000000..4af99f672 --- /dev/null +++ b/results/scraper/box64/2593 @@ -0,0 +1,12 @@ +Graphical Issues with MiSide on Newer Box64 Builds +Starting from 57f0744, MiSide have graphical issues with fastnan=0 + + + +Now with fastnan=1 + + + +On 7b2e084 works normally + + \ No newline at end of file diff --git a/results/scraper/box64/2594 b/results/scraper/box64/2594 new file mode 100644 index 000000000..0ea3c0f3f --- /dev/null +++ b/results/scraper/box64/2594 @@ -0,0 +1,8 @@ +There will be support Box64 For iOS + + + + + + +If it will be possible to adapt it will be great but due to limitations iOS It will be difficult to make an emulator \ No newline at end of file diff --git a/results/scraper/box64/2595 b/results/scraper/box64/2595 new file mode 100644 index 000000000..519279af3 --- /dev/null +++ b/results/scraper/box64/2595 @@ -0,0 +1,81 @@ +Question/Request: About Box64 x87 reduced precison info and comparison vs new "rosettax87" project hack? +Hi, +very new to Box32/64 and finding that Box64 supports some kinds of x87 reduced precision.. + +from docs: +https://github.com/ptitSeb/box64/blob/main/docs/USAGE.md +https://github.com/ptitSeb/box64/blob/main/docs/box64.pod +we have: +BOX64_X87_NO80BITS +BOX64_DYNAREC_X87DOUBLE + +I see with BOX64_DYNAREC_X87DOUBLE that you even allow/default to single precision using this option.. +0: Try to use float when possible for x87 emulation. [Default] +1: Only use Double for x87 emulation. +2: Check Precision Control low precision on x87 emulation. + +so question is if you can share what perf can we gain vs non reduced x87 precision on targeted microtests? + + +I say this because for Rosetta since recently we have project: +https://github.com/Lifeisawful/rosettax87 +which acceleretes x87 computation in some cases 10X at least on M4: +https://github.com/Lifeisawful/rosettax87/issues/2 + +at least on the simple sample benchmark shared on this project (using x87 for calculating fsqrt seems): +clang -v -arch x86_64 -mno-sse -mfpmath=387 ./sample/math.c -o ./build/math + +at least +Rosetta M4: +Average time: 123040 ticks + +Rosettax87 M4: +Average time: 12222 ticks + +part of code: + +``` +#define TIMES 1000000 +#define RUNS 10 +#define METHOD run_fsqrt + +clock_t run_fsqrt() { + float sixteen = 16.0f; + + clock_t start = clock(); + + // Run fsqrt many times to get measurable time + float four; + for(int i = 0; i < TIMES; i++) { + four = __builtin_sqrtf(sixteen); + } + + clock_t end = clock(); + clock_t time_spent = (end - start); + + printf("Result: %x\n", *(uint32_t*)&four); + return time_spent; +} + +int main() { + clock_t times[RUNS]; + clock_t sum = 0; + + printf("benchmark %s\n", STRINGIFY(METHOD)); + + // Perform multiple runs + for(int i = 0; i < RUNS; i++) { + times[i] = METHOD(); + sum += times[i]; + printf("Run %d time: %lu ticks\n", i+1, times[i]); + } + + // Calculate average using integer math + clock_t avg = sum / RUNS; + printf("\nAverage time: %lu ticks\n", avg); + + return 0; +} + + +``` \ No newline at end of file diff --git a/results/scraper/box64/2596 b/results/scraper/box64/2596 new file mode 100644 index 000000000..cf900ac54 --- /dev/null +++ b/results/scraper/box64/2596 @@ -0,0 +1,32 @@ +Battle Brothers on box32 +Hi @ptitSeb, +I'm opening this issue because I believe you might be my last hope to get this game running decently on my smartphone. + +Device specifications: OnePlus 12R - SD8Gen2 - 16GB RAM - Android 15 (OxygenOS) +Videogame: Battle Brothers, a 2D OpenGL 3.3 32-bit game + +Problem: Severe frame rate fluctuations; FPS on the world map vary between 10 and 40, and in battles between 15 and 50, making the game playable but with a noticeably poor experience. + +Apps through which I used Box64/Box32: + +Winlator Official by brunodev85 (latest build - Winlator 10 Final (hotfix)) + +Winlator Box32 Mod by alexvorxx (https://github.com/alexvorxx/winlator/releases/tag/v7.1.5-mod3) + +With Winlator Official, I tried running the game with Box64 and WOW64. I kept the default "Intermediate" settings, only changing the parameter BOX64_DYNAREC_FORWARD to 1024. I did this because leaving it at 128 made the game run with such low FPS that it was practically unplayable. As the graphic driver, I initially used Turnip and the DXVK wrapper. I also tried all other combinations, but even when the game managed to start (not all configurations did), the issue persisted. + +With Winlator Box32 Mod, I obviously used the only configuration that allows Box32: Turnip and WineD3D as the DX wrapper. In this specific case, besides the aforementioned BOX64_DYNAREC_FORWARD, I also modified other variables: + +BOX64_DYNAREC_BIGBLOCK set to 3 + +BOX64_DYNAREC_WAIT set to 0 + +BOX64_RESERVE_HIGH set to 1 + +With this latter setup, I got about 5 or 6 more FPS compared to the one achieved with Winlator Official. So, it's likely that Box32 emulates this game better than Box64. However, the FPS instability issue persists: it's as if during certain screen transitions or specific moments, FPS drops sharply for several seconds. + +I'm attaching all the logs I was able to produce with Winlator Box32 Mod, hoping you might give me some guidance or find them useful in case there’s something that needs fixing. + +Looking forward to your feedback, and I want to sincerely thank you for everything you do. If needed, I’m available for any kind of testing. I truly hope to get Battle Brothers running decently because it's a fantastic game that fits the mobile context extremely well. + +[Winlator.zip](https://github.com/user-attachments/files/20011363/Winlator.zip) \ No newline at end of file diff --git a/results/scraper/box64/2597 b/results/scraper/box64/2597 new file mode 100644 index 000000000..084276a81 --- /dev/null +++ b/results/scraper/box64/2597 @@ -0,0 +1,2 @@ +Good news for Linux + diff --git a/results/scraper/box64/2598 b/results/scraper/box64/2598 new file mode 100644 index 000000000..7fb75dd92 --- /dev/null +++ b/results/scraper/box64/2598 @@ -0,0 +1,33 @@ +Should `NewBrick()` use `setProtection_mmap` to correctly track mmap regions? +In `NewBrick()`, after allocating memory via `box_mmap()`, the code currently uses `setProtection()`: +```c +brick_t* NewBrick(void* old) +{ + brick_t* ret = (brick_t*)box_calloc(1, sizeof(brick_t)); + static void* load_addr_32bits = NULL; + if(box64_is32bits) + old = load_addr_32bits; + else { + if(old) + old = old + NBRICK * sizeof(onebridge_t); + } + void* ptr = box_mmap(old, NBRICK * sizeof(onebridge_t), PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | ((!box64_is32bits && box64_wine)?0:0x40) | MAP_ANONYMOUS, -1, 0); // 0x40 is MAP_32BIT + if(ptr == MAP_FAILED) + ptr = box_mmap(NULL, NBRICK * sizeof(onebridge_t), PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | ((!box64_is32bits && box64_wine)?0:0x40) | MAP_ANONYMOUS, -1, 0); + if(ptr == MAP_FAILED) { + printf_log(LOG_NONE, "Warning, cannot allocate 0x%lx aligned bytes for bridge, will probably crash later\n", NBRICK*sizeof(onebridge_t)); + } + setProtection((uintptr_t)ptr, NBRICK * sizeof(onebridge_t), PROT_READ | PROT_WRITE | PROT_EXEC | PROT_NOPROT); + dynarec_log(LOG_INFO, "New Bridge brick at %p (size 0x%zx)\n", ptr, NBRICK*sizeof(onebridge_t)); + if(box64_is32bits) load_addr_32bits = ptr + NBRICK*sizeof(onebridge_t); + ret->b = ptr; + return ret; +} +``` + +However, `setProtection()` does not label the region as `MEM_MMAP`. +As a result, `getMmapped()` returns 0, even though the region was mmap-allocated. + +I've already pushed a [local commit](https://github.com/devarajabc/box64/commit/0a2042a427c3bf6eaffa88124a84930a18126d06) that applies this change. + +Before opening a PR, I’d like to confirm: Are there any design considerations that explain why `setProtection()` was originally used instead of `setProtection_mmap()`? \ No newline at end of file |