diff options
Diffstat (limited to '')
| -rw-r--r-- | results/scraper/box64/203 | 9 | ||||
| -rw-r--r-- | results/scraper/box64/2034 | 2 | ||||
| -rw-r--r-- | results/scraper/box64/2039 | 8 |
3 files changed, 19 insertions, 0 deletions
diff --git a/results/scraper/box64/203 b/results/scraper/box64/203 new file mode 100644 index 000000000..0f48ceadc --- /dev/null +++ b/results/scraper/box64/203 @@ -0,0 +1,9 @@ +error: unknown type name '__uint128_t' +When trying to compile using the make -j$(nproc) command, I keep encountering the following error: + +error: unknown type name '__uint128_t' + +I have followed all of the steps listed on [pymylifeup](https://pimylifeup.com/raspberry-pi-x64/) to the letter and am curious what may be causing this problem. I am currently running Raspbian GNU/Linux 11 (bullseye). + +Please let me know if you need any additional information. I have attached a text version of the compiler output to this issue if that helps. +[error message.txt](https://github.com/ptitSeb/box64/files/7805909/error.message.txt) diff --git a/results/scraper/box64/2034 b/results/scraper/box64/2034 new file mode 100644 index 000000000..5bc57b851 --- /dev/null +++ b/results/scraper/box64/2034 @@ -0,0 +1,2 @@ +[WOW64] Mass Effect 2 EA app crashes +The game wont open at all with DXVK or OpenGL \ No newline at end of file diff --git a/results/scraper/box64/2039 b/results/scraper/box64/2039 new file mode 100644 index 000000000..dfa177b0f --- /dev/null +++ b/results/scraper/box64/2039 @@ -0,0 +1,8 @@ +Clarification on the Purpose of Red-Black Trees in Box64 +I have noticed that in `custommem.c`, memory ranges mapped by mmap are simultaneously recorded and removed in multiple red-black trees. +Each node encapsulate a memory range along with detailed information about that range. +My question pertains to the necessity of using three distinct red-black tree nodes to record the same memory range. +Is this approach taken solely to maintain three separate pieces of information related to each memory range? + + If that's the case, could a bitwise operation be implemented to consolidate the information, potentially reducing the number of trees required? + |