diff options
| author | fusion32 <marcopuzziello@gmail.com> | 2025-06-30 19:23:09 -0300 |
|---|---|---|
| committer | fusion32 <marcopuzziello@gmail.com> | 2025-06-30 19:23:09 -0300 |
| commit | 6c8aa85b8b578db03a8c5f0dc0b7e80605592d45 (patch) | |
| tree | 6734cf3d3c0e318a139f7d15d9a524c423833e22 /TODO.md | |
| parent | c09d30cb144ce421ef0e1a786d2965f9abcde0aa (diff) | |
| download | game-6c8aa85b8b578db03a8c5f0dc0b7e80605592d45.tar.gz game-6c8aa85b8b578db03a8c5f0dc0b7e80605592d45.zip | |
`writer.cc`
Diffstat (limited to 'TODO.md')
| -rw-r--r-- | TODO.md | 5 |
1 files changed, 2 insertions, 3 deletions
@@ -1,8 +1,7 @@ ## TODO NEXT -- QUERY.CC - READER.CC -- WRITER.CC - DBFUNCS.CC +- QUERY.CC - Include `x == 0xFFFF` inside `CheckVisibility`? - The map container uses type id zero but it seems to also be used as a "no type" @@ -21,7 +20,7 @@ instead of relying on `NARRAY`. ## Stack allocations -Any functions that use `alloca` or some other form of dynamic stack allocations will cause decompiled functions to be an absolute mess. It usually shows up in the decompiled code as both a size computation like `-(VAR + CONST & 0xfffffff0)`, followed by some assignment. It doesn't make total sense without looking at the disassembly. I've encountered ~30 such computations and expect the functions containing them to be amongt the most challenging/annoying to be properly decompiled. +Any functions that use `alloca` or some other form of dynamic stack allocations will cause it to be an absolute mess. It usually shows up in the decompiled code as both a size computation like `-(VAR + CONST & 0xfffffff0)`, followed by some assignment. It doesn't make total sense without looking at the disassembly. I've encountered ~30 such computations and expect the functions containing them to be amongt the most challenging/annoying to be properly decompiled. ## Exceptions It's absolute hell. |
