Sauerbraten in a dll

by PlateWolf on 07/24/2006 01:50, 45 messages, last message: 03/24/2008 16:27, 15522 views, last view: 05/05/2024 12:53

Hi, I want to access Sauerbraten externally, did anyone managed to compile it in a dll ?
(Like SDL for example).

   Board Index   

#26: ..

by 9382938475 on 03/18/2008 14:29

isn't making the engine a shared library a bit backwards? I'd imagine that it'd be much simpler instead to make the games sharedlibs and have the engine load them. basically just have the game code declare a func like:

const igame *_registergame(void)

which returns the game/mod. am I missing something?

reply to this message

#27: Re...

by StickyFeet on 03/18/2008 14:46

MovingTarget, not really following your description here, its very vague and generalised?

reply to this message

#28: Re: Re...

by MovingTarget on 03/18/2008 15:50, refers to #27

Go into the src/mingw subdirectory of the Sauer base folder. Duplicate the sauerbraten.cbp projectfile two times. Name one engine.cbp (the DLL project) and name the other one game.cbp (the game that loads/calls the DLL). In engine.cbp, expand the "Sources" folder, go into the "src" subdirectory, and delete the fpsgame and rpggame subdirs. Do the same in the "Headers" folder.

In game.cbp, reverse the process, deleting the enet and engine subdirs from "Sources" and "Headers".

I hope *someone* can figure out how to make engine.cbp build a DLL with a .def file! And they better know how to make game.cbp link to the library generated!!

reply to this message

#29: ..

by HashBox3 on 03/18/2008 23:00

This would be a great way to write games in Java :D You could get the graphical power of Sauerbraten, with the game friendly object orientedness of Java :D

reply to this message

#30: ..

by ezombie on 03/18/2008 23:05

'isn't making the engine a shared library a bit backwards? I'd imagine that it'd be much simpler instead to make the games shared libs and have the engine load them.'

This is how most ID engines do it. It's an effective system. I would personally love this.

'This would be a great way to write games in Java :D You could get the graphical power of Sauerbraten, with the game friendly object orientedness of Java :D'

Muzzah?!? Not sure you get get more OO then C++ - the native language of Sauerbraten. :D

reply to this message

#31: Re: ..

by yoopers on 03/19/2008 20:21, refers to #29

>> This would be a great way to write games in Java :D You could get the graphical power of Sauerbraten, with the game friendly object orientedness of Java :D

If this ever comes to fruition, I volunteer to help with Ruby and Perl bindings - someone else who doesn't cringe at the word "Java" can handle that. I've spent far too much time today debugging what I thought was a Tomcat issue, only to find out it was a Java keystore problem. *sigh*

reply to this message

#32: Re: ..

by MovingTarget on 03/19/2008 20:42, refers to #31

Want me to upload the engine dll?

reply to this message

#33: Re: ..

by yoopers on 03/19/2008 22:50, refers to #32

Upload would be appreciated. :]

Does anyone have a preference between Ruby and Perl? I'll start with whatever would get used by folks.

reply to this message

#34: Re: ..

by MovingTarget on 03/20/2008 00:59, refers to #33

I figured I wouldn't upload the dll directly, so you could tweak it, so I uploaded the two project files (engine.cbp and game.cbp). The only one you're really interested in is engine.cbp. Put 'em both in the src subdir, and you can open/build them.

Engine.cbp:
http://www.mediafire.com/?ymnzitkmbyg

Game.cbp:
http://www.mediafire.com/?zgxcmyi0lzz

reply to this message

#35: ..

by ezombie on 03/20/2008 03:50

Likely Ruby - it is very 'hot' right now. But I do see more Python development going on in games right now, so YMMV...

reply to this message

#36: Re: ..

by SheeEttin on 03/20/2008 03:53, refers to #33

Perl bindings for Sauerbraten?!
Kids these days. What'll they think of next...

reply to this message

#37: ..

by HashBox3 on 03/20/2008 20:57

ezombie, you do have a very good point ;)

reply to this message

#38: Re: ..

by yoopers on 03/21/2008 00:55, refers to #34

@MovingTarget: you are a scholar and gentleman. :]

@SheeEttin: I have to caveat the following by saying I was bored at work today. With that in mind:

perl "I am not a kid ;]" 2>&1| \
perl -pe's/^.*?\"(.*?)not a kid.*?\".*?$/\
$1\x74\x68\x65\x20\x77\x61\x6c\x72\x75\x73\x2c\x20\x63\x6f\x6f\x20\x63\
\x6f\x6f\x20\x6b\x61\x20\x63\x68\x6f\x6f/' 2>&1|\
perl -pe's/\n//g';perl -e'print "\n"'

reply to this message

#39: Re: ..

by yoopers on 03/21/2008 01:04, refers to #38

(btw, that was was a Perl quintet for those who aren't familiar ;)

reply to this message

#40: Re: the undead (aka perl)

by ezombie on 03/21/2008 02:56

Ah crud, now where did I put my holy water?

reply to this message

#41: Re: ..

by SheeEttin on 03/21/2008 04:37, refers to #39

Functional, but not especially obfuscated.

I once saw a program/script/thing (pretty sure it was Perl) that'd create a bitmap image based on how the source looked. Character-filled parts would be black, while whitespace would be, well, white.
Tried Google, but I don't see it...

reply to this message

#42: Re: ..

by yoopers on 03/21/2008 05:16, refers to #41

What, the ultra-obscure hex didn't keep you guessing? ;] Man, this damn head cold is killing my Perl buzz. I promise I'll start posting haikus when I feel better.

And for all the Perl advocacy, I'm working on Python bindings for Sauer, although the nested classes in some places means it'll take me a bit longer than I anticipated to create the SWIG interface.

**This message has been ROT13-encoded twice for extra security and for great justice.**

reply to this message

#43: Re: ..

by MovingTarget on 03/21/2008 14:35, refers to #42

Uuuugh... I tried SWIG once, and I failed miserably. It kept complaining about supposed syntax errors in the C++ code, when it compiled fine. My experiences have not exactly been fun.

reply to this message

#44: ..

by scasd on 03/22/2008 18:22

So what about obscurant code - as far as I think OO should be possible with cube script. Look at the following example. It would still need member function call routines plus member value lookup - but this should be possible too. You have to create a stack like the member value stack done below which will be some effort... one or two days I think :o]

Cube script isnt sandboxed - the biggest problem but maybe it will be in the future - I still got some Segmentation Faults while hacking that stuff.



// create a fake class type or inherit a fake class
// usage: class [name] [parent] [parent]
// where one or two partens are optional
"class" = [
alias classtype $arg1;

// create the member-apply function for our new class
alias $classtype (
concatword "alias " $classtype .members " (concat $" $classtype .members " $arg1); alias (concatword " $classtype ". $arg1) $arg2" // set value "class.member"
);

// empty memberlist
alias (concatword $classtype .members) [];

// get stuff from our parental class
loop i 2 [
alias parentgetter (concatword "alias parent $arg" (+ (i) 2));
parentgetter;

if (> (listlen $parent) 0) [

alias membergetter (concatword "alias members $" $parent .members);
membergetter;
alias membercount (listlen $members);
//echo $members - $membercount;

// get parents members
loop i $membercount [
alias membername (at $members (i));
//echo "- copy member " $membername;
alias membercopy (concatword $classtype " " $membername " $" $parent . $membername);
membercopy;
];
];
];

// delete local data
alias membercopy []; alias membername []; alias membercount []; alias membergetter []; alias parent []; alias parentgetter [];

alias current.classtype $classtype; // remember this class
alias membercount []; alias members []; alias classtype [];
]



// append a member to the last created fake class
// usage: member [name] [value]
"member" = [
if (> (listlen $current.classtype) 0) [
current.classtype $arg1 $arg2;
]
]


// delete a fake class and its members
// usage: delete [name]
"delete" = [
alias classtype $arg1;
alias membergetter (concatword "alias members $" $classtype .members);
membergetter;
alias membercount (listlen $members);
//echo $members - $membercount;

// get members
alias (concatword $classtype .members) [];
loop i $membercount [
alias membername (at $members (i));
//echo "- delete member " $membername;
alias memberdelete (concatword "alias " $classtype . $membername " []");
memberdelete;
];

if (= $current.classtype $classtype) [
alias current.classtype [];
];

alias $classtype [];

alias memberdelete []; alias membername []; alias membercount []; alias membergetter []; alias classtype [];
];



echo test...

class vec2;
vec2 x 12; // default values
vec2 y 34;
echo $vec2.members - $vec2.x - $vec2.y;

class vec3 vec2;
member z 56;
echo $vec3.members - $vec3.x - $vec3.y - $vec3.z;

vec2.x = 78; // the order is important - changes after "inheritance" doesnt affect the inherited classes !!!
echo "vec2 again:" $vec2.members - $vec2.x - $vec2.y;

class pos vec3;
echo $pos.members - $pos.x - $pos.y - $pos.z;

delete vec3; // pos is still working...
echo $vec3.members - $vec3.x - $vec3.y - $vec3.z;

class color;
member r 1;
member g 2;
member b 3;
echo $color.members - $color.r - $color.g - $color.b;

class pixel color vec2; // more than 2 base classes would need a dummy...
echo $pixel.members;

reply to this message

#45: Re: ..

by yoopers on 03/24/2008 16:27, refers to #43

SWIG doesn't like nested structs, classes, and unions, which explains many of the syntax errors. It's also quite picky about how arguments are passed.

But good news, everyone! There are ways around these issues, it just takes more time to create the interface. The downside is that the interface becomes more tightly coupled with the code, but that's been my experience with SWIG in general.

reply to this message

   Board Index