-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Native vs WHDload 060 compatibility bugs #52
Comments
Ok... |
Can you try the same with the 1.07 version? |
The mem allocs are not that hacky. But very greedy. I think limiting them to a certain amount wouldn't hurt. I am not sure about the 5120 byte minimum restriction. @nicode Do you have a clue why they only considered blocks of at least that size in Ambermoon? And maybe why they alloc all memory but ensure 10240 bytes of free mem afterwards? Are those some magic values like "the OS needs that much to print an error" or something like that? |
When you say random gurus, do you mean they are different all the time? Can you track a list of the guru types. I guess only a few guru types will occur. |
Is this solved by the recent whdload slave? |
Yes and no... Castle Godsbane still has memory issues even using WHDLoad, see my recent comments on: http://mantis.whdload.de/view.php?id=5716#c11507 |
As we discuss this in #66 and it might not be related to my patches or whdload, I will close this one. |
New issue for compatibility issues. See #22
@a1exh @Hexaae Please continue here now.
The text was updated successfully, but these errors were encountered: