Reply to Re: GNU Freedink - New Maintainer
If you don't have an account, just leave the password field blank.
Hey, nice timing!
We were just talking in a newly released DMOD thread about some BIG Freedink bug in 109.6, on 64 bit linux releases. http://www.dinknetwork.com/forum.cgi?MID=207767&Posts=60
Long story short, ghostknight discovered that the code uses "long" instead of "int" in some places and this leads to some things breaking when passing function parameters.
To start with, check line 50 in dinkc.cpp
I'm not at my freedink computer right now, but I remember there being other instances of misusing long instead of int too. Check out ghostknight's post in that thread, and I'll get back to you later with whatever else I can find.
I'm pretty sure that there shouldn't be *any* longs at all, since I don't think dink was developed with 64bit variables in mind. Most likely, I imagine that any use of "long" is some old legacy code where Seth wanted to make sure 32bit values were used instead of 16bit values...
There is one more REALLY annoying thing that we'd all be really happy if someone fixed it, but it's not exactly a bug or related to any of this, just a quality of life thing: When Freedink switched to SDL2, there was a change in the SDL code that causes "DEBUG: Surface doesn't have a colorkey" to be spammed to the debug console stream. This effectively floods the debug log and the onscreen debug info in the game. Beuc talked about this in this issue: https://github.com/libsdl-org/SDL/issues/2909
I don't know if this can be fixed by modifying calls to SDL_GetColorKey in some way, or it needs a custom SDL2 build where the debug message change gets reverted...
We were just talking in a newly released DMOD thread about some BIG Freedink bug in 109.6, on 64 bit linux releases. http://www.dinknetwork.com/forum.cgi?MID=207767&Posts=60
Long story short, ghostknight discovered that the code uses "long" instead of "int" in some places and this leads to some things breaking when passing function parameters.
To start with, check line 50 in dinkc.cpp
/* store current procedure arguments expanded values of type 'int' (see get_parms) */ static long nlist[10];
I'm not at my freedink computer right now, but I remember there being other instances of misusing long instead of int too. Check out ghostknight's post in that thread, and I'll get back to you later with whatever else I can find.
I'm pretty sure that there shouldn't be *any* longs at all, since I don't think dink was developed with 64bit variables in mind. Most likely, I imagine that any use of "long" is some old legacy code where Seth wanted to make sure 32bit values were used instead of 16bit values...
There is one more REALLY annoying thing that we'd all be really happy if someone fixed it, but it's not exactly a bug or related to any of this, just a quality of life thing: When Freedink switched to SDL2, there was a change in the SDL code that causes "DEBUG: Surface doesn't have a colorkey" to be spammed to the debug console stream. This effectively floods the debug log and the onscreen debug info in the game. Beuc talked about this in this issue: https://github.com/libsdl-org/SDL/issues/2909
I don't know if this can be fixed by modifying calls to SDL_GetColorKey in some way, or it needs a custom SDL2 build where the debug message change gets reverted...
