Talk:Daodan DLL
Its cool that my version of Daodan got added to this page (I was going to add it myself, but I never got around to it) but I was wondering, why "Pelles C"? MinGW GCC is a very good compiler. As for assembly, both GCC and Pelles C support inline and external assembly (I don't know about MASM syntax, although MinGW's linker can take input from other compilers.) It doesn't really matter though as both compilers compile C99 and should be relatively compatible.
- -rossy 11:22, 9 November 2008 (CET)
According to SFeLi, GCC doesn't support fastcalls and Pelles-C does. He said, however, that we could stick to MinGW and emulate fastcalls with libraries written in ASM. I honestly am not familiar with the problem or the workaround, so I can't give a clear answer. Let's hope SFeLi is not dead, so he can comment on that when he's back. In the meantime, of course, just stick with MinGW, and keep those updates coming ;)
- geyser 14:54, 9 November 2008 (CET)
GCC supports fastcall, if it didn't then none of my code would work, however if there's a good reason to use Pelles-C then I'm ok with it. As for updates, when the school certificate's over, maybe.
- rossy 07:06, 10 November 2008 (CET)
The reason I changed C Daodan to replace binkw32.dll instead of adding vtuneapi.dll is that I had to patch a function that was called before vtuneapi was loaded. Turns out that the reason Alt-Tab and the Windows key didn't work is because the Oni developers specifically disabled them. (this is the part that prints "system sleep disabled, keystroke traps installed" in startup.txt.) The function that prints these is called before vtuneapi is loaded so I had to switch to replacing binkw32.dll. C Daodan still works as vtuneapi.dll however Alt-Tab and the Windows key don't work when it's used like this.
- -rossy 11:22, 9 November 2008 (CET)
Point taken about early DLL loading. One thing though: to avoid conflicts with previous versions of the Daodan, maybe prevent Oni from loading vtuneapi.dll, unless you're doing that already. And another thing, not like it really matters, but Iritscen has been nagging us about it, and just won't stop: our "press Shift at startup" feature is screwed up, and the reason SFeLi hasn't fixed it is because the fix has to come before vtuneapi.dll is loaded; would switching to binkw32.dll make it possible to fix that feature? Or maybe it's completely pointless, because the Daodan already has command-line parameters of its own (uncompatible with the in-engine dialog), and KeyConfig is more than enough to customize controls?
- geyser 14:54, 9 November 2008 (CET)
- Currently, enabling the command line editor makes it so that the C-Daodan doesn't work properly. The window\game is never drawn. I know the C-Daodan has command line parameters, I don't know how they work in relation to Oni.exe's command line code. Bink32.dll loads after the command line editor. And I can't find any mention of a control editor in the database. I don't think any dlls are loaded soon enough, but the engine could (maybe) be patched if it is _really_ neccessary. Gumby 23:26, 9 November 2008 (CET)
- binkw32.dll is loaded before the game is loaded by the windows loader. I kind of sort of hacked the new command line arguments in so even if the box is displayed the new arguments won't work anyway. rossy 07:26, 10 November 2008 (CET)
- Well we could probably make a new box if we wanted to, right? Gumby 07:50, 10 November 2008 (CET)
- binkw32.dll is loaded before the game is loaded by the windows loader. I kind of sort of hacked the new command line arguments in so even if the box is displayed the new arguments won't work anyway. rossy 07:26, 10 November 2008 (CET)
Daodan.ini documentation out of date
I notice that the information on the sections and attributes of Daodan.ini is no longer compatible with the most recent version and/or the one offered for download on this page. It seems that as of r1000 (v3.7), Daodan_Config.c no longer accepts the options in the Patches/Options/Language sections format, but rather splits it into separate sections. Should this page continue to reflect an older version, or is it ok to modify it with the new info?
--Dekarrin (talk) 16:37, 8 July 2014 (CEST)
Sure, go ahead :)