Archived

This topic is now archived and is closed to further replies.

Goku705

Two questions: One Windows, One Scripting

Recommended Posts

First question: I''m making a game based on a mini-game from Final Fantasy 8 (Triple Triad) and I was wondering, for a simple card game interface, which is better: SDI or Dialog (obviously MDI would be stupid for this)? I don''t want to start coding until I''ve decided (because it''s being done in MFC and once you make your choice in AppWizard, it''s set in stone). Second, is there a C++ equivalent to the VB function CallByName () (either in the language itself or an external library)? It would make adding scripting support to my other game (an RPG) much easier (massive switch statements and I don''t go well together). If there isn''t, how would I code one (wow, that sounded so... newbie-ish). If it''s way too tough, I may just go with an already set up scripting engine (like SeeR or something). Thanks in advance for help on either question. -Goku

Share this post


Link to post
Share on other sites
hmm, i don''t know what CallByName() does, but if that means to call a function dynamically (without knowing it''s name) you might want to go with a function pointer.
if it''s that what you meant, i can provide you some sample code for fps, if not, well ignore this post

rid

Share this post


Link to post
Share on other sites
No, the point of CallByName () is a function that calls another function as listed in it''s string parameter(s). I don''t remeber the way it works but an equivalent C++ function would work like this:

CallByName ("sqrt", "9");

and would return 3. At least that''s how I imagine it would work. I''m only guessing as it was mentioned in the Game Scripting tutorial off the front page here. I don''t use VB if I can help it (I was never much for BASIC of any incarnation).

-Goku

Share this post


Link to post
Share on other sites
Maybe, you could do it like this:
1) have a map (STL)
2) have all the functions ''register'' themselves - add the name and function ptr to the map
3) whenever the function wants to be called, you must find the ptr associated with the name (using STL very easy)
4) BUT, there must only be one parameter (NOOOOOOOO) otherwise how to keep track of all the parameters? and how to make each the same in order to add to the map?
However, you can have it as an list/vector (STL) so that, in fact, you can have any number of parameters.

If you are using BCB you can do a CallByName(), although it''s not called that. Actually more like MethodAdressByName().

Hope that helps.


------------------------------
BCB DX Library - RAD C++ Game development for BCB

Share this post


Link to post
Share on other sites
Oy... that doesn''t sound easy at all. I understand what you mean, I think. I save the function pointer address along with the name into the map file (or some other script system file) but can I rest assured that all my functions will be stored at the same address on the heap (that''s where it goes, right?) so that every time the program is run, the functions pointers will be filled in properly?

I''m not sure what was meant by the stuff for parameters but I also know absolutely nothing about STL.

Unfortunately, I''m using MSVC++ so I guess that MethodAddressByName () function isn''t an option.

Thanks for that so far. By the way, I also asked about which app type to use (see my original post).

-Goku

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Oy... that doesn''t sound easy at all. I understand what you mean, I think. I save the function pointer address along with the name into the map file (or some other script system file) but can I rest assured that all my functions will be stored at the same address on the heap (that''s where it goes, right?) so that every time the program is run, the functions pointers will be filled in properly?

I''m not sure what was meant by the stuff for parameters but I also know absolutely nothing about STL.

Unfortunately, I''m using MSVC++ so I guess that MethodAddressByName () function isn''t an option.

Thanks for that so far. By the way, I also asked about which app type to use (see my original post).

-Goku

Share this post


Link to post
Share on other sites
he means that you create it in the engine, like that
struct FUNC
{
char* fname;
func* function;
}

FUNC thefunctions[MAX_FUNCTIONS];

then, an initialisation..

but, I think (when your using vc++, like you do with mfc, I think), you could do it in another way:
in dlls, the functions are written as text in, and that could you use for you, you could use your exe as a dll, and calling itsselfs so, something like this:

#define CALLFUNC __declspec(dllexport)

CALLFUNC void a_function()
{
MessageBox("Called a function");
}


and for calling something like this:
func* currentfunction=NULL;
currentfunction=FindInDll("a_function"); //Dont know the name, wait some minutes
currentfunction();

could work, and would be funny if so:

else, you could do a dll, that works hundred pro

we wanna play, not watch the pictures

Share this post


Link to post
Share on other sites
here:

HANDLE hLibrary =LoadLibrary("your.exe"); //you have to insert your .exe-name

typedef void(WINAPI * voidfuncvoid)(); //pointer to a void function like the a_function();

voidfuncvoid call=NULL;
call=(voidfuncvoid)GetProcAddress(hLibrary,"a_function");
call();

//and for your script something like this:
char* current_func_name=GetCurrentFunction("script.txt");
call=(voidfuncvoid)GetProcAddress(hLibrary,current_func_name);
call();

FreeLibrary (hLibrary) ;


we wanna play, not watch the pictures

Share this post


Link to post
Share on other sites
Thanks. I think I''ve got it now. Loading the EXE as a library seems kind of silly though very interesting but I think I''ll just make the scripted functions into a DLL and load from there. Essentially the GetProcAddress() function was exactly what I wanted because from there, making and using a function pointer shouldn''t be hard (I''ll have to look up exactly how to use function pointers but I''ll manage). Yeah, the more I mull that over, the easier it sounds. Good.

Now, I think I''ll agree with you. SDI seems better. The interface feels tidier to me that way anyway (status bar, menus, toolbar, etc.). The only reason I was unsure was because with a dialog-based app I can design the whole interface through the resource editor. With SDI, any controls on the main window have to be hard coded. Well, at least that would be true if I were using MSVC++ 5 or lower because I just found out that 6 lets you derive the View''s class from CFormView. This essentially means that my program is put together with controls in an SDI window. I can also design that as if this were VB (they''re trying too hard to close the gap between the C++ and VC++), in fact, it could even be a VB form.

Anyway, I''m done rambling now. Thanks again.

-Goku

Share this post


Link to post
Share on other sites