I had to make two modifications to Milton's code before it ran properly on my machine.
1)
Trying to allocate big_chunk_of_memory at address 1<<18 failed with error code 0x1E7 (ERROR_INVALID_ADDRESS).
My workaround: #define HEAP_BEGIN_ADDRESS ((LPVOID)(1ull<<34))
On my machine most memory below 0x7FFF0000 is already occupied right after starting the application. Things like user32.dll and kernel32.dll live there. The Milton.exe module lives somewhere around address 0x13XXXXXXX. After that I have a gap of about 8 GB free addresses followed by various DLLs (e.g. opengl32.dll) all the way up to 0x7FFFFFFE0000. It might be wiser to make HEAP_BEGIN_ADDRESS be a very high address like 1<<63. If I remember correctly, that's what Casey did in HMH. I don't know whether Windows actually guarantees any address ranges to be free.
2)
Vertex shader failed to compile with the following errors:
ERROR: error(#271) Explicit version number 120 not supported by GL3 forward compatible context
ERROR: error(#273) 1 compilation errors. No code generated
My workaround: Change #version 120 to #version 130 in imgui_impl_sdl_gl3.cpp and milton .cc
It seems like this wouldn't have been a problem in release mode, since Milton only uses a core profile context, #if MILTON_DEBUG.
It's interesting to see how subtle differences in memory layout and graphics driver can break a program. Once the program runs, it runs reasonably well. The amount of processing power used by Milton depends heavily on the speed of the stroke. I'm not an artist myself, but I am looking forward to have a closer look at Milton's code.
1)
Trying to allocate big_chunk_of_memory at address 1<<18 failed with error code 0x1E7 (ERROR_INVALID_ADDRESS).
My workaround: #define HEAP_BEGIN_ADDRESS ((LPVOID)(1ull<<34))
On my machine most memory below 0x7FFF0000 is already occupied right after starting the application. Things like user32.dll and kernel32.dll live there. The Milton.exe module lives somewhere around address 0x13XXXXXXX. After that I have a gap of about 8 GB free addresses followed by various DLLs (e.g. opengl32.dll) all the way up to 0x7FFFFFFE0000. It might be wiser to make HEAP_BEGIN_ADDRESS be a very high address like 1<<63. If I remember correctly, that's what Casey did in HMH. I don't know whether Windows actually guarantees any address ranges to be free.
2)
Vertex shader failed to compile with the following errors:
ERROR: error(#271) Explicit version number 120 not supported by GL3 forward compatible context
ERROR: error(#273) 1 compilation errors. No code generated
My workaround: Change #version 120 to #version 130 in imgui_impl_sdl_gl3.cpp and milton .cc
It seems like this wouldn't have been a problem in release mode, since Milton only uses a core profile context, #if MILTON_DEBUG.
It's interesting to see how subtle differences in memory layout and graphics driver can break a program. Once the program runs, it runs reasonably well. The amount of processing power used by Milton depends heavily on the speed of the stroke. I'm not an artist myself, but I am looking forward to have a closer look at Milton's code.
Edited by Tilmann R
on
Reason: milton.cc is not a URL.
Thanks for letting me know!
You're right. It wouldn't have been a problem in release. However, it makes me worry a little bit of the problems I will have when I finish the OpenGL renderer :). The Nvidia driver doesn't even give me a warning.
The HEAP_BEGIN_ADDRESS was more important before when I was using only my own allocators. Right now I'm using a mix of libc and arenas, which are on top of the big_chunk_of_memory.
If you end up taking a closer look at the source, please let me know if you find more problems!
You're right. It wouldn't have been a problem in release. However, it makes me worry a little bit of the problems I will have when I finish the OpenGL renderer :). The Nvidia driver doesn't even give me a warning.
The HEAP_BEGIN_ADDRESS was more important before when I was using only my own allocators. Right now I'm using a mix of libc and arenas, which are on top of the big_chunk_of_memory.
If you end up taking a closer look at the source, please let me know if you find more problems!