This is a simple question: Does anybody compiled the jfBuild engine in a Windows DLL and/or *NIX .so file?
If you're guessing, I want to do a game. I was playing with several engines, including jfBuild, for years but I never start it because I wanted to create my own engine (vain :P ). Finally I decided that I shouldn't create another 3D engine if I want to finish the game some day, so I'll use jfBuild (may be with few changes). But I don't want to use C or C++, so compile it in a dynamic library will make the linking easer.
Thanks ;D
[edit] I've used the forum search but it doesn't work. :-\
Edited by Ñuño Martínez at
JonoF at
Re: Build engine in a DLL/so file
Ñuño Martínez said at
Does anybody compiled the jfBuild engine in a Windows DLL and/or *NIX .so file?
I personally haven't bothered doing a DLL/so/dylib version and I doubt anyone else has either, but it certainly ought to be possible. Making a Build-to-Python binding would be an interesting academic exercise at least.
Jonathon
Ñuño Martínez at
Build engine in a DLL, try one
Thanks for the reply. I see.
I did a first try and I've find it will be hard because there are some mixed code (game, engine and SDL) so it's not possible to create the dynamic library directly. I'll start again step by step cleaning the code (just separate game code and engine code). I'll tell you when I finish.
Ñuño Martínez at
Build engine in a DLL/so file, try two, take one.
Almost done 8)
Well, actually it creates a 715K DLL file but Mr. Silverman's game doesn't compile since I didn't defined the export/inport functions yet. The code is messed up and I'm afraid I should change the API a bit to make it run (i.e.: the faketimerhandler, the sdlappicon, etc.).
If somebody else is interested let me know and I'll send/attach the current version (remember that now it's unusable).
I'll tell you when I make this run.
Ñuño Martínez at
Re: Build engine in a DLL/so file
Hi everybody.
I didn't finished with the dll, personal issues (AKA real lifetm) will throw me out of business for a while so I'm afraid I'll not finish this before next year :'(. Anyway, I can tell you some tips about how to create a build.dll/so file if anybody else has time to do the job. Let's go with the:
Build.dll first try FAQ (or something...)
Is possible to create a dll/so file? Yes, it is. At least I've compiled and linked a dll file that almost contains the engine. By the way, it doesn't work yet...
Is it easy? No, because there are some engine code mixed with the game's code and the map editor's code. A way to fix this would be to define some hooks/callback pointers. An example for this is the "faketimerhandler" function defined in "game.c" but called from "engine.c".
Another problem is the lack of internal documentation (I mean: What does "faketimerhandler" means for? What it does? Is it really necessary? As far as I understood the actual game.c's implementation it shouldn't be called from the engine but from the game's play loop. Or don't I understand it? and that's only one example). This can be fixed asking Ken, Jonathon or with try-and-fail test.
Will be the final dll/so file compatible with old Build/Polymost games? If you read the previous answer you know this will be impossible. But there are more issues (variables, parameters, etc.) that would change to make the conversion easer.
It's worth to put Build in a dll/so file? That's a good question. :-\
The engine is old, the API is a big crap (Ken, don't get mad with me but it remembers me when I start to code BASIC twenty years ago, and I'm one year younger than you :P), there are tons of 3D engines with better renderers, more powerful scripting, control...
In the other hand, I love challenge and I said that I'll use Polymost in a game (may be two) and I will even if this is the latest thing I'll do in my life.
Well, that's all at the moment.
[p.s] Ken, please, don't get mad with me. You're a genius, sure, but nobody is perfect.
Edited by Ñuño Martínez at
Awesoken at
I could never figure out how to receive network packets through an interrupt handler. I don't know if IPX was meant to support this, or if maybe I just never found the right example code. Either way, I had to find a solution. And that solution was faketimerhandler(). The function basically simulated an interrupt handler. It worked pretty well as long as it was called often enough throughout the code. I didn't write the client-side prediction code until a year later, so every millisecond counted. A slow machine getting only 20fps would have added up to 50ms to everybody's ping time! This is quite noticable for a LAN game. To reduce the wait for slow machines, I added lots of calls to faketimerhandler() from inside the rendering core.
If you have a fast machine, you really don't need all those faketimerhandler() calls. You could probably remove all of them except for one - which you call once per frame.