Quote:
Originally Posted by Y_Leѕѕ
Quote:
Originally Posted by SMX
Quote:
Originally Posted by MaVe;
Quote:
Originally Posted by SMX
To those people talking about the wrappers being fine; have you ever looked at their source? They do a lot of stuff behind your back that wouldn't be necesary if my suggestion gets realised.
|
What's that stuff exactly?
|
For example when you call SendClientMessage from your plugin:
First you need to locate it's address which only has to be done once so thats not much of a problem.
Next is allocating an array of cells in the AMX for the text string you want to send.
Then you need to convert and copy your string from a char array to that array of cells.
All that before you can call it.
Now if we would separate the AMX the prototype for SendClientMessage would probably look like this:
Код:
int SendClientMessage(int playerid, int colour, char* text);
int SendClientMessage(int playerid, int colour, wchar_t* text); //Support non latin languages?
With that you could just pass a pointer to your string, no copying or whatever required.
Calling functions that pass arguments by reference also require you to allocate space in the AMX.
Think of GetPlayerPos used for a speedometer, how many times does that get called for each player per second? See how it's adding up now?
|
Have you ever looked at my wrappers? You're generalising!
|
No I have not, will do that as soon as I have time for it though.
Edit:
I've done some research on how you do it and you seem to be able to bypass the AMX when calling native functions.
I have a few questions about it though:
* How did you get the addresses of those functions?
* How do you know what types and in what order you need to send the arguments to them other than just guessing?
* As far as I know those addresses can change when a new version of the SA-MP server binary is released so isn't that causing a lot of trouble (yeah I know we don't get a new binary often but still)?
Even so if the suggestion I made gets realised we wouldn't have to go through all this trouble.