Talk:Daodan DLL: Difference between revisions

From OniGalore
Jump to navigation Jump to search
No edit summary
No edit summary
Line 3: Line 3:
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 ;)
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 ;)
:[[User:Geyser|geyser]] 14:54, 9 November 2008 (CET)
:[[User:Geyser|geyser]] 14:54, 9 November 2008 (CET)
 
GCC supports fastcall, if it didn't then none of my code would work. As for updates, when the school certificate's over, maybe.
:[[User:RossyMiles|rossy]] 07:06, 10 November 2008 (CET)


----
----

Revision as of 06:06, 10 November 2008

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. 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)