SA-MP Forums Archive
Separate the AMX - Printable Version

+- SA-MP Forums Archive (https://sampforum.blast.hk)
+-- Forum: SA-MP Scripting and Plugins (https://sampforum.blast.hk/forumdisplay.php?fid=8)
+--- Forum: Plugin Development (https://sampforum.blast.hk/forumdisplay.php?fid=18)
+--- Thread: Separate the AMX (/showthread.php?tid=116453)

Pages: 1 2

Separate the AMX - SMX - 28.12.2009

I have a major question/suggestion, I'm not sure if this is the right place to post it but I'll try.

Would it not be better to separate the AMX from the SA-MP server so it only requires a .dll or .so as a gamemode?
Now you might think: "What about all those gamemodes programmed in PAWN?", well supply the AMX as a .dll or .so to use that if you have a gamemode programmed in PAWN.

This would have several advantages:

* People who want to code their gamemodes in C or C++ dont have to use those wrappers anymore so that should be faster and easier.
* It should make it easier to make SA-MP use other virtual machines/embedded languages like LUA for example.

I cannot think of any disadvantages of using this approach apart from a bit of work for Kye to move stuff around.

The reason I came up with this is because I was thinking about how the current implementation works if you want to make a gamemode with a plugin.
Say if the server wants to call a function, it calls it in the AMX, you make a little script that makes it forward that call to your plugin, your plugin then does it's stuff and returns to the AMX, the AMX then returns to the server.
That is a lot of extra stuff that needs to be done and then I'm not even talking about what if your plugin wants to execute a native function from the server, that also goes through the AMX.

Do you think I'm completely wrong here or that its a bad suggestion or perhaps you agree with me?
Well what are you waiting for? Post it, I'm looking forward to hearing your opinion!

Re: Separate the AMX - cmg4life - 28.12.2009

Well, in my opinion, it should be made either both, either AMX only. Why? Because of all the other scripters and starters, mainly. Also some don't know C or C++ .

EDIT: Also you would just throw away a lot of time/knowledge. I for one spent 3 years scripting this way. I learnt and i'm still learning, it's like you would throw all my knowledge away.

If it would be possible, maybe a better wrapper to be made by the SA-MP Dev Team itself for those who use this way.

Re: Separate the AMX - pliva_sb - 28.12.2009

For me is ok but perhaps the most problem is that some do not know the work of C, CPP. Also I'm not anything special but I know the basics, very easy to adjust it. I'm not saying that the other would quickly adjust, but I say my opinion. For now, I have no idea whether it would be a problem but because is SA:MP made in cpp (I think) that it actually would not be a problem. Maybe I'm wrong.

Edit: I have a similar opinion as cmg4life.

Re: Separate the AMX - Zeex - 28.12.2009

If you mean something like offical SA-MP library with API for C/C++ (and perhaps other langauges?) then it would be extremely good I think

Re: Separate the AMX - Google63 - 28.12.2009

The only really good advantage PAWN has is - you don't need to do version for LiNUX and WiNDOWS.

Re: Separate the AMX - SMX - 28.12.2009

Quote:
Originally Posted by cmg4life
Well, in my opinion, it should be made either both, either AMX only. Why? Because of all the other scripters and starters, mainly. Also some don't know C or C++ .

EDIT: Also you would just throw away a lot of time/knowledge. I for one spent 3 years scripting this way. I learnt and i'm still learning, it's like you would throw all my knowledge away.

If it would be possible, maybe a better wrapper to be made by the SA-MP Dev Team itself for those who use this way.
You missed one bit of my post:
Quote:
Originally Posted by Myself
Now you might think: "What about all those gamemodes programmed in PAWN?", well supply the AMX as a .dll or .so to use that if you have a gamemode programmed in PAWN.
So it is still possible to use any script programmed in PAWN, no loss.

Edit:
To clarify, with separate I do NOT mean get rid of the AMX, I mean make it optional.

Re: Separate the AMX - Striker_Moe - 31.12.2009

PAWN is the only scripting language I can and its easy for me Q_Q I wouldnt mind everything coded in PAWN, lol..

Re: Separate the AMX - Calon - 04.01.2010

The current wrappers are fairly sufficient and do the job; I think it could also cause a few complications for newbies.

Re: Separate the AMX - BP13 - 04.01.2010

If that happens I might as well quit San Andreas Multiplayer forever.

Re: Separate the AMX - MPKaboose - 04.01.2010

Pawn could still be used for novice/new scripters and C++ and/or lua for more advanced scripters

Re: Separate the AMX - SMX - 04.01.2010

Quote:
Originally Posted by [SU
BP13 ]
If that happens I might as well quit San Andreas Multiplayer forever.
You make it sound like we are losing something with this approach making me think you didn't read everything.
Please make sure you read and understand where I'm going with this before you post stuff like that.

So for the third time: We do not lose anything with this, it only makes using PAWN to create your gamemode optional.

I'll think of modifying the first post later to make it a bit more clear as I didn't have a lot of time when I posted it.

Re: Separate the AMX - JernejL - 04.01.2010

Quote:
Originally Posted by Seif_
We should rather switch to Lua instead.
Your suggestion is not helpful and off topic.

cmg4life: you don't throw anything away, pawn is very similar to plain C and you should be able to use all pawn knowledge to migrate to c++, but that would not be the only language that a native dll could support.. think delphi, php, python..


Re: Separate the AMX - Burridge - 04.01.2010

Quote:
Originally Posted by Calon
The current wrappers are fairly sufficient and do the job; I think it could also cause a few complications for newbies.
Exactly, the ways for coding SA-MP right now, are fine, I don't see a reason for there to be a change. Sure, by all means make it so people can code in LUA or whatever too, but leave the PAWN there for the majority. But to be fair, as you rightly said Calon, the wrappers are doing the job just fine.

Re: Separate the AMX - SMX - 04.01.2010

Quote:
Originally Posted by RedShirt (JernejL)
Quote:
Originally Posted by Seif_
We should rather switch to Lua instead.
Your suggestion is not helpful and off topic.

cmg4life: you don't throw anything away, pawn is very similar to plain C and you should be able to use all pawn knowledge to migrate to c++, but that would not be the only language that a native dll could support.. think delphi, php, python..
That's exactly what I'm talking about! It gives us full control about what language/virtual machine/whatever we want to use to create a gamemode.

Since everything goes through the AMX, SA-MP is limited to a just a few data types that all fit within the 32bit cells it uses (32bit signed integers and 32bit floats) and then it also uses those unpacked strings which take 4 bytes per character.
I know you can make it use packed strings so it uses 1 byte per character but SA-MP doesn't do that at the moment.
This might not be much of an issue but it adds up.

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.

Re: Separate the AMX - Streetplaya - 05.01.2010

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?

Re: Separate the AMX - SMX - 06.01.2010

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?

Re: Separate the AMX - Streetplaya - 06.01.2010

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?
Well yeah, that's completly true. I might have to think of a new method again. And I need to get better at IDA.

Re: Separate the AMX - Streetplaya - 06.01.2010

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!
I'm waiting for you to release a big better SDK with a perfect wrapper for natives and callbacks. That would help at least me a lot.

Re: Separate the AMX - Streetplaya - 06.01.2010

Quote:
Originally Posted by Y_Leѕѕ
That's a LOT of work and unlikely to happen - every PAWN native would basically need to have custom code written for it, you can't just hook the native itself, you need to get into the underlying code.
If you worked in a team, it would be faster and more likely to happen.

Re: Separate the AMX - SMX - 06.01.2010

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.