Page 1 of 2 12 LastLast
Results 1 to 25 of 35

Thread: Why pascal?

  1. #1
    Join Date
    Mar 2013
    Posts
    49
    Mentioned
    0 Post(s)
    Quoted
    17 Post(s)

    Default Why pascal?

    Just wondering why SRL/Simba chose free pascal as its language.

    What are its strengths compared to something like Java or C++?

  2. #2
    Join Date
    Mar 2013
    Posts
    1,010
    Mentioned
    35 Post(s)
    Quoted
    620 Post(s)

    Default

    So it was compatible with scar (I think)
    #slack4admin2016
    <slacky> I will build a wall
    <slacky> I will ban reflection and OGL hooking until we know what the hell is going on

  3. #3
    Join Date
    Dec 2011
    Location
    East Coast, USA
    Posts
    4,231
    Mentioned
    112 Post(s)
    Quoted
    1869 Post(s)

    Default

    Quote Originally Posted by Hawker View Post
    So it was compatible with scar (I think)
    One could then ask the question: why did SCAR use pascal? I don't know, maybe someone else does
    GitLab projects | Simba 1.4 | Find me on IRC or Discord | ScapeRune scripts | Come play bot ScapeRune!

    <BenLand100> we're just in the transitional phase where society reclassifies guns as Bad™ before everyone gets laser pistols

  4. #4
    Join Date
    Mar 2013
    Posts
    1,010
    Mentioned
    35 Post(s)
    Quoted
    620 Post(s)

    Default

    Quote Originally Posted by KeepBotting View Post
    One could then ask the question: why did SCAR use pascal? I don't know, maybe someone else does
    Guess we'd need to ask kaitnieks or someone around when scar was first made
    #slack4admin2016
    <slacky> I will build a wall
    <slacky> I will ban reflection and OGL hooking until we know what the hell is going on

  5. #5
    Join Date
    Feb 2006
    Location
    Amsterdam
    Posts
    13,691
    Mentioned
    146 Post(s)
    Quoted
    130 Post(s)

    Default

    Simple language, Kaitnieks himself was probably used to Delphi, so Pascal was a logical step since there was an interpreter for it (PascalScript). Benefits? Well, it's not as bad as C++ and Java, and it's nice as a scripting language here. These days I would probably prefer Python, but hey.



    The best way to contact me is by email, which you can find on my website: http://wizzup.org
    I also get email notifications of private messages, though.

    Simba (on Twitter | Group on Villavu | Website | Stable/Unstable releases
    Documentation | Source | Simba Bug Tracker on Github and Villavu )


    My (Blog | Website)

  6. #6
    Join Date
    Feb 2007
    Location
    Colorado, USA
    Posts
    3,716
    Mentioned
    51 Post(s)
    Quoted
    624 Post(s)

    Default

    Quote Originally Posted by Wizzup? View Post
    Simple language, Kaitnieks himself was probably used to Delphi, so Pascal was a logical step since there was an interpreter for it (PascalScript). Benefits? Well, it's not as bad as C++ and Java, and it's nice as a scripting language here. These days I would probably prefer Python, but hey.
    How hard would it be to put a python interpreter inside of simba

    that's the "easy part" or am I wrong?
    The only true authority stems from knowledge, not from position.

    You can contact me via matrix protocol: @grats:grats.win or you can email me at the same domain, any user/email address.

  7. #7
    Join Date
    Dec 2010
    Posts
    483
    Mentioned
    30 Post(s)
    Quoted
    328 Post(s)

    Default

    SCAR was never meant to be anything serious, it was originally just a temporary replacement/side project of AutoRune.

    Fact is, I don't care what anyone says, Java, C++, .NET languages...just about anything is considerably faster, more powerful, and prettier on the eyes than pascal/delphi.

  8. #8
    Join Date
    Oct 2006
    Posts
    6,752
    Mentioned
    95 Post(s)
    Quoted
    532 Post(s)

    Default

    Quote Originally Posted by the bank View Post
    SCAR was never meant to be anything serious, it was originally just a temporary replacement/side project of AutoRune.

    Fact is, I don't care what anyone says, Java, C++, .NET languages...just about anything is considerably faster, more powerful, and prettier on the eyes than pascal/delphi.
    Yup ^ There's a reason why pascal is no longer used for much of anything nowadays..
    “The long-lived and those who will die soonest lose the same thing. The present is all that they can give up, since that is all you have, and what you do not have, you cannot lose.” - Marcus Aurelius

  9. #9
    Join Date
    Mar 2013
    Posts
    49
    Mentioned
    0 Post(s)
    Quoted
    17 Post(s)

    Default

    Thanks for all of the responses. Really interesting!
    Definitely agree with the bank, is a very ugly language.
    Last edited by JJordan; 02-22-2015 at 05:03 PM.

  10. #10
    Join Date
    Feb 2012
    Location
    Norway
    Posts
    995
    Mentioned
    145 Post(s)
    Quoted
    596 Post(s)

    Default

    Quote Originally Posted by the bank View Post
    Fact is, I don't care what anyone says, Java, C++, .NET languages...just about anything is considerably faster, more powerful, and prettier on the eyes than pascal/delphi.
    I find object pascal very nice looking.

    Also, considerably faster than Delphi? You clearly don't know much about Delphi then. Delphi is fast (it compiles to quite optimized native machine code), none of the mentioned languages are notably faster. They might in some cases be a few times faster than FPC (but that's usually not noted), but FPC is not Delphi.

    I can assume you mean to say those languages (errm compilers) are much faster then Lape (not Delphi), then you wouldn't be wrong. But for what we do speed isn't really that much of a concern, when a speedup is needed you simply extend it with a "plugin" (dll), this plugin can be written in any language capable of compiling a lib.
    Last edited by slacky; 02-22-2015 at 07:47 PM. Reason: somehow manged to not type "considerably"
    !No priv. messages please

  11. #11
    Join Date
    Dec 2010
    Posts
    483
    Mentioned
    30 Post(s)
    Quoted
    328 Post(s)

    Default

    Quote Originally Posted by slacky View Post
    I find object pascal very nice looking.

    Also, faster than Delphi? You clearly don't know much about Delphi then. Delphi is fast (it compiles to quite optimized native machine code), none of the mentioned languages are notably faster. They might in some cases be a few times faster than FPC, but FPC is not Delphi (and that's usually not noted).

    I can assume you mean to say those languages (errm compilers) are much faster then Lape (not Delphi), then you wouldn't be wrong. But for what we do speed isn't really that much of a concern, when a speedup is needed you simply extend it with a "plugin" (dll), this plugin can be written in any language capable of compiling a lib.
    I mean no disrespect, however Pascal/Delphi are ridiculously wordy languages. Not only does this, ironically, decrease readability due to the clusterfuck that is an application, but also limits efficiency of the developer by making code longer and take more time to write.

    As far as Delphi compiling into machine code that is optimized anywhere near the degree of say C or C++ is ridiculous fallacy. Take these benchmarks for example. Of course these sorts of things are specific to compilers themselves, but I would put VisualStudio 2014 or even GCC faster than any Delphi compiler I've ever used.

    I've used Delphi extensively, including creating the OpenSCAR project a year or so before Simba was even released. And yes, I'm well aware of Simba's plugin capability.

    Delphi is fairly quick, you're correct, but it is not the fastest, and leaves a lot to be desired in terms of efficiency, specifically for the developer. Its just so damn "wordy".

  12. #12
    Join Date
    Nov 2011
    Location
    England
    Posts
    3,072
    Mentioned
    296 Post(s)
    Quoted
    1094 Post(s)

    Default

    I also think Pascal is the most easiest language to understand with no prior coding knowledge.

    Obviously most languages out class it, but pascal does a decent job for RS scripts.

    Also don't forget we're using a interpreter (Lape) which is far from FPC.

  13. #13
    Join Date
    Dec 2010
    Posts
    483
    Mentioned
    30 Post(s)
    Quoted
    328 Post(s)

    Default

    Quote Originally Posted by Olly View Post
    I also think Pascal is the most easiest language to understand with no prior coding knowledge.

    Obviously most languages out class it, but pascal does a decent job for RS scripts.

    Also don't forget we're using a interpreter (Lape) which is far from FPC.
    I 100% agree with you but for all the wrong reasons. I feel that yes, for the simple things, pascal is a very simple language to learn. However, the more advance features of it I find are harder to use and learn than the higher level features of more popular languages. This is due to objects being more stuffed into it rather than the language being built around them.

    I also believe pascal can teach some very poor practices, such as lack of care to case-sensitivity.

    Ultimately, I agree, it works fine for our goal.

  14. #14
    Join Date
    Dec 2011
    Location
    Toronto, Ontario
    Posts
    6,424
    Mentioned
    84 Post(s)
    Quoted
    863 Post(s)

    Default

    Quote Originally Posted by Olly View Post
    I also think Pascal is the most easiest language to understand with no prior coding knowledge.

    Obviously most languages out class it, but pascal does a decent job for RS scripts.

    Also don't forget we're using a interpreter (Lape) which is far from FPC.
    Dunno about this, i'd say that Python is easier to read/write.

  15. #15
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by slacky View Post
    I find object pascal very nice looking.

    Also, faster than Delphi? You clearly don't know much about Delphi then.
    I can assume you mean to say those languages (errm compilers) are much faster then Lape (not Delphi), then you wouldn't be wrong.

    Lol..

    The ONLY time Delphi is "faster" than C, C++, C#, and Java, is in code-writing speed. You can write code faster in Delphi than the mentioned languages because you have less to worry about (memory management, "gotcha's"), etc..


    Even then, I would bet you can write code faster in C# and Java than Delphi by a long shot. Delphi's optimiser will NEVER be as aggressive as Clang's LLVM or the JIT compiler used by .Net 4.5+. Not sure about the JVM.


    The reason we use Pascal and Delphi for Simba and Scar is simply ease of use. With these languages, we can write scripts and code within a day of learning it. The tutorials are easy to follow. There's no "gotcha's" or stupid stuff to worry about (well there is, but not too many [other than the bugs in Lape]). It's straight forward.

    I like the other languages but I can never see them being used for scripts. Those are for full fledge programs.


    @OP; The only legit reasons I can think of is:

    extremely easy to learn
    easily used as a scripting language (although, this is arguable since we can use LUA or Python or w/e)

    That's it. If we could do it all over, I would vote PYTHON as the main language for Simba. Not Lape or Pascal script or Delphi (although Scar Titan is using Delphi and looks fairly nice).
    Last edited by Brandon; 02-22-2015 at 07:05 PM.
    I am Ggzz..
    Hackintosher

  16. #16
    Join Date
    Feb 2012
    Location
    Norway
    Posts
    995
    Mentioned
    145 Post(s)
    Quoted
    596 Post(s)

    Default

    Quote Originally Posted by the bank View Post
    I mean no disrespect, however Pascal/Delphi are ridiculously wordy languages. Not only does this, ironically, decrease readability due to the clusterfuck that is an application, but also limits efficiency of the developer by making code longer and take more time to write.

    As far as Delphi compiling into machine code that is optimized anywhere near the degree of say C or C++ is ridiculous fallacy. Take these benchmarks for example. Of course these sorts of things are specific to compilers themselves, but I would put VisualStudio 2014 or even GCC faster than any Delphi compiler I've ever used.

    I've used Delphi extensively, including creating the OpenSCAR project a year or so before Simba was even released. And yes, I'm well aware of Simba's plugin capability.

    Delphi is fairly quick, you're correct, but it is not the fastest, and leaves a lot to be desired in terms of efficiency, specifically for the developer. Its just so damn "wordy".
    This goes to you as well @Brandon:
    I never claimed delphi was the fastest or faster then the mentioned languages (compilers). I only saeid that the other languages (bank mentioned) aren't notably faster. Also that test you show there seems to be around 14 years old or so.. And it only tests 1 single thing.. Computing PI, where I don't see Delphi being any notably slower then any of the C compilers (at least not the the degree where it's worth mentioning).

    I didn't claim Delphi to spit out machine code optimized to the same level as GCC. I only said "quite optimized".

    Pascal languages are indeed very wordy, and for some this is an issue. I however haven't noted my self being very limited by it's wordy syntax. It does force you to type a lot more compared to the more compact languages out there, but on the other hand I find it extremely clear, so I can often take a quick look at some random piece of code and understand it/what it does quite quickly, and this on the other hand saves me a lot of time, this is not the case for me in most C-based languages, any language filled with all sorts of punctuation-marks isn't nearly as clear.


    And all in all.. Who really needs the fastest of the fastest compiler?
    Any compiler that spits out machine-code is usually good enough. There are very very few cases where one actually would need to care about the microscopic speed difference between GCC and Delphi. Can you mention any? And if speed is that important in what ever you do can't you just have the most critical parts written in assembly?
    Assembly in FPC and Delphi is extremely simple to use.
    Last edited by slacky; 02-22-2015 at 07:34 PM.
    !No priv. messages please

  17. #17
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by slacky View Post
    And all in all.. Who really needs the fastest of the fasts languages?
    Any compiler that spits out machine-code is usually good enough. There are very very few cases where one actually would need to care about the microscopic speed difference between GCC and Delphi. Can you mention any? And if speed is that important in what ever you do can't you just have the most critical parts written in assembly?
    Assembly in FPC and Delphi is extremely simple to use.

    Yes you are right. The mentioned languages are not "much" faster naturally but the optimisation of the other languages are done a ton better.

    And yes we DO need the fastest at times. We use image processing in our scripts (OpenCV doesn't use Pascal or Delphi for a reason). We read directly from the GPU in OpenGL and Direct-X. Doing this more than 30,000 per second in Pascal & Delphi is a LOT slower.

    In high performance critical code, it matters. It's not just a few nano-seconds or micro-optimisation. It's seconds that are passing as the time piles up.


    But we are arguing about scripting languages so yes, I would say you are 100% right and that it doesn't matter.. but we could have been using Python or Lua instead of Lape or PascalScript.

    So there's no "particular" reason why we use Pascal or Lape over Python or other scripting languages. I can count many reason why we use it over C, C++, C# or Java but definitely not Python or Lua.

    It all just comes down to one choice which Wizzup made and that was to use Pascal. But I highly doubt there was any specific reason behind it other than ease of use and easy transition from Scar to Simba without having to learn new languages.
    Last edited by Brandon; 02-22-2015 at 07:27 PM.
    I am Ggzz..
    Hackintosher

  18. #18
    Join Date
    Feb 2012
    Location
    Norway
    Posts
    995
    Mentioned
    145 Post(s)
    Quoted
    596 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    Yes you are right. The mentioned languages are not "much" faster naturally but the optimisation of the other languages are done a ton better.

    And yes we DO need the fastest at times. We use image processing in our scripts (OpenCV doesn't use Pascal or Delphi for a reason). We read directly from the GPU in OpenGL and Direct-X. Doing this more than 30,000 per second in Pascal & Delphi is a LOT slower.

    In high performance critical code, it matters. It's not just a few nano-seconds or micro-optimisation. It's seconds that are passing.


    But we are arguing about scripting languages so yes, I would say you are 100% right and that it doesn't matter.. but we could have been using Python or LUA instead of Lape or PascalScript.
    Regarding OpenCV, have look at it's code. The most critical parts are usually written as SSE2 instructions.. And, alternatively can be compiled to use your GPU (Using OpenGL).
    You also mention OpenGL, I am not sure why. OpenGL can be used from any language that can do external function calls (and AFAIK they all do it pretty much the the same way) so there is no slowdown there, if you where to use OpenGL from delphi.
    !No priv. messages please

  19. #19
    Join Date
    Feb 2007
    Location
    Colorado, USA
    Posts
    3,716
    Mentioned
    51 Post(s)
    Quoted
    624 Post(s)

    Default

    Quote Originally Posted by the bank View Post
    SCAR was never meant to be anything serious, it was originally just a temporary replacement/side project of AutoRune.

    Fact is, I don't care what anyone says, Java, C++, .NET languages...just about anything is considerably faster, more powerful, and prettier on the eyes than pascal/delphi.
    Agreed
    It'd be nice to have like maybe the client itself in C++ or .net since they're speedy and reliably cross platform "today" (.net is now open source so we'll see it in mono with better compatibility soon)
    and with many interpreters so people can code in what they like imo
    The only true authority stems from knowledge, not from position.

    You can contact me via matrix protocol: @grats:grats.win or you can email me at the same domain, any user/email address.

  20. #20
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by slacky View Post
    Regarding OpenCV, have look at it's code. The most critical parts are usually written as SSE2 instructions.. And, alternatively can be compiled to use your GPU (Using OpenGL).
    You also mention OpenGL, I am not sure why. OpenGL can be used from any language that can do external function calls (and AFAIK they all do it pretty much the the same way) so there is no slowdown there, if you where to use OpenGL from delphi.

    Ahh you're being stubborn. Now the thread is derailed completely.. ={

    OpenGL can be used in any language such as Pascal, Delphi, and Java yes.. But what language is it written in? It's definitely NOT Pascal or Delphi. It isn't Java. It's C.

    There's ONE reason for that: SPEED. There IS a slowdown in other languages (even Delphi and Pascal) which is what you're not understanding.

    The simple indirect access to a C API isn't optimised out. When you load these API's in other languages, a whole new layer is added on top of it. JNI is the perfect example and there's NO WAY to get rid of it. Delphi is managed.

    I'd like to start with the very basic core of Delphi: http://stackoverflow.com/a/180449/1462718 HEAP ALLOCATIONS.

    The cost of a heap allocation vs. stack allocation. Everyone knows allocating on the stack is WAY faster than heap allocations. It's as simple as pushing the stack down and popping it. There's no memory book-keeping or tracking going on. There's no need to "free" allocations (which also costs).

    This alone already puts Delphi behind. If you wanted to allocate on the stack in Delphi, you're forced to use Assembly. Not all allocations in OpenGL require a heap allocation (which is usually done for LARGE objects). See "Small String Optimisation" vs. Heap allocated strings.

    Next is the usage of the "try-finally" idiom for freeing memory allocations. There's no such thing as "Free Exceptions" in Windows. Windows has three kinds of exception handling.. VEH (Vectored Exception Handling) and is used in Windows XP, SJLJ (SetJump LongJump) and SEH (Structured Exception Handling) and Linux has Dwarf, Dwarf2 and Dwarf3.

    In Windows, SJLJ will COST you 15% speed NO MATTER WHAT. You will never be able to optimise it out. You automatically incur this cost by just using a 32-bit version of GCC alone (even if you don't use ANY exceptions at all!).

    Next is SEH (http://www.microsoft.com/msj/0197/Ex...Exception.aspx and http://www.codeproject.com/Articles/...-Point-of-View). This is the one Delphi and all languages that use Windows MUST use (SJLJ is optional and only used as a hack in GCC). The cost of a SINGLE exception is to push the stack down and allocate a structure such as the below, run your code, unwind the stack when the exception occurs (pop the below structure off the stack and cleanup all stack allocated variables, then run the exception handler):

    C Code:
    typedef struct _EXCEPTION_RECORD
    {
      DWORD     ExceptionCode;    // which exception occurred
      DWORD     ExceptionFlags;   // additional exception info
      struct _EXCEPTION_RECORD *ExceptionRecord;
      PVOID     ExceptionAddress; // where the exception occurred
      DWORD     NumberParameters;
      ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS];
    } EXCEPTION_RECORD;


    This is done in ALL LANGUAGES that works on Windows. This cost alone is why C programmers stay away from raising exceptions in WinAPI and instead use "goto" and "return codes".

    So just using an idiom such as the one in the above Delphi sample, you incur the cost of an exception without even realising it. And this is required because an allocation may fail and throw an exception and if you don't catch it, you will incur the cost of a memory leak.

    This cost is not paid in C++ because you don't have to use exceptions due to RAII and automatic destruction of objects. The only way to avoid this cost in Delphi is to use records/structures (POD) and completely avoid creating classes/objects.


    Anyway, unless you plan on allocating and handling all the memory yourself and writing a lot of assembly, you're out of luck. Every time you use SetLength on an array, it has the overhead of reference counting, copying on write, etc.. Are you saying you're going to get rid of the core features of the language for speed?

    There's a whole layer of memory difference. In Pascal & Delphi, allocations are done completely different. The same memory you allocate in Pascal and Delphi cannot just be passed to C and expect it to be used the same way.

    For example, in Tesseract, I have to COPY the string to a Pascal allocated buffer.


    For example in @the bank;'s random-int plugin, he does (the difference between malloc and AllocMem):

    Simba Code:
    Function PSAlloc(size: Integer): Pointer;
    begin
      Result := AllocMem(size);
    end;

    var
      TIA: TIntegerArray;
    begin
      SetAllocator(@PSAlloc);

      TIA := randomIntArray(0, 500, 1000); //generate 1000 random ints
    end.

    then in C he does:

    C Code:
    void (*allocator)(int) = NULL;

    void SetAllocator(void (*alloc)(int))
    {
        allocator = alloc;
    }

    void* randomInt(int min, int max, int count)
    {
        int* TIA = (int*)allocate(count, allocator); //allocate memory using Pascal instead of C.
        generate_random(TIA, min, max, count);
        return TIA;
    }


    He had to use an allocator because malloc & new aren't compatible with AllocMem. AllocMem has a lot more book-keeping than a simple malloc. AllocMem is equivalent to: book-keeping + malloc combined. However, malloc already does its own book-keeping so now you have the overhead of double keeping and an extra layer of incompatibility.

    The TIntegerArray will simply crash right there and then. Allocating the TIA in Simba and then COPYING the data to it can be done but again, you incur the cost of a COPY.


    If I allocated pointers to some structures in C, I have to COPY it to the Pascal/Delphi side. You can't just pass the memory and expect it to work (unless you guarantee the exact same memory alignment and layout). Then you have to worry about alignment as well.

    JNI is even worse, Jagex had to write a custom OpenGL wrapper (jaggl.dll) in C just to interface with their application. They copy every single texture and model into a java.nio.ByteBuffer. This buffer is then passed to OpenGL which makes its own copy to the GPU (allowing the user to delete their own copy). So now you have a Java copy, you have a Java ByteBuffer copy and you have an OpenGL copy. That's 3 copies for each texture and 3 copies for each model. To narrow it down to TWO copies, Jagex decided to "Map" the buffer directly to their ByteBuffer. But now you have the overhead of just TWO copies.. but that's NOT all! You have the overhead of forcing the GPU to "sync" with the CPU (to access the mapped buffer) all to avoid a single copy (which is a fairly good trade off).

    So all in all, Jagex had to write a custom plugin, create a duplicate of every model and texture and map the buffer (sync GPU with CPU). Without this, they'd have 3 duplicates. This right here is UN-AVOIDABLE, which is why they do what they do. Simply because they use Java. They can also use the "Unsafe" class to access buffer pointers directly, but it's another JNI overhead.

    Next, the OpenGL plugins have to COPY the buffer to SMART to use (and then SMART copies to Simba which is irrelevant but adds up).


    The same goes for OpenGL in Pascal and Delphi. It's not a native Delphi or Pascal API. Not only do you have to use indirect function pointer access, but you have to worry about memory alignment, packing, etc.. There's no static linking in Delphi to OpenGL or Direct-X. You have to use LoadLibrary and create a function pointer for all THREE HUNDRED AND SEVENTY-THREE functions and then call GetProcAddress to get the address of each OpenGL function to assign to your function pointers (which you have to write the signatures for). All of this, Delphi does under the hood for you. We can consider this overhead "NEGLIGIBLE".

    Although Delphi can use pointers directly, you have to guarantee layout (contiguous memory) and alignment (dword, byte boundaries) for ALL structures and allocations and mapped buffers.

    You're going to have to start using raw memory in Delphi just to get comparable speed. Things like "string", "arrays", et al will have to be dumbed down completely to raw dirty memory allocations with manual freeing.

    Things like bit-fields cannot be used in Delphi or Pascal so you're out of luck. So all this incompatibility + overheads is just absolutely ridiculous. So just by using Delphi, you've already given yourself a huge disadvantage (although not even close to being as bad as Jagex using Java for OpenGL).

    So it's not so much the "overhead" of loading the functions or calling them (which does add up eventually not is negligible).. It's the overhead of using the language itself. The core functions and classes of the language (which has to now be avoided to pass to C.. PChar for String, Raw memory allocations for everything, alignment/layout/packing, et al).

    In that case, you might as well use C. But again, Python should be Simba's scripting language. Not Delphi or C.
    Last edited by Brandon; 02-22-2015 at 10:16 PM.
    I am Ggzz..
    Hackintosher

  21. #21
    Join Date
    Feb 2012
    Location
    Norway
    Posts
    995
    Mentioned
    145 Post(s)
    Quoted
    596 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    Ahh you're being stubborn. OpenGL can be used in any language such as Pascal, Delphi, and Java yes.. But what language is it written in? It's definitely NOT Pascal or Delphi. It isn't Java. It's C.

    There's ONE reason for that: SPEED. There IS a slowdown in other languages (even Delphi and Pascal) which is what you're not understanding.

    The simple indirect access to a C API isn't optimised out. When you load these API's in other languages, a whole new layer is added on top of it. JNI is the perfect example and there's NO WAY to get rid of it. Delphi is managed.
    Didn't mean to come of as stubborn. I pointed out 1 thing, and asked a question (badly formulated), where I asked why OpenGL would be better from C ("You also mention OpenGL, I am not sure why") which you answered (in a somewhat spiteful manner I must add).

    And yes, I do know why he passed an allocator to the plugin... Meh. So harsh for just because I asked a small simple question.

    - I think i'm done here.
    Last edited by slacky; 02-22-2015 at 08:20 PM.
    !No priv. messages please

  22. #22
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by slacky View Post
    Didn't mean to come of as stubborn. I pointed out 1 thing, and asked a question (badly formulated), where I asked why OpenGL would be better from C ("You also mention OpenGL, I am not sure why") which you answered (in a somewhat spiteful manner I must add).

    And yes, I do know why he passed an allocator to the plugin... Meh. So harsh for just because I asked a small simple question.

    - I think i'm done here.

    I'm not being spiteful. It's just the way I write. I write how I think (as if I'm explaining to myself, but in a more natural way [unprofessional because who speaks to themselves professionally].. My capitalisations are for emphasis, not shouting. I rather that, than painting it in red to make it clearer). I was just explaining, not for just you (even though I figuratively ask questions like "do you know why".. but "you" doesn't refer to just YOU but to the other readers as well), but for others who are reading as well. They might not know why the allocator was passed or what a memory layout is. Relax a bit. It's just a discussion. Not an argument or a put down. I don't put down capable programmers (which you obviously are [SimbaEXT, Memory Reading, etc). I don't put down incapable programmers either because they can learn.

    My post is simply an explanation to the question and a discussion of WHY it is slower by a lot more than just a few nano-seconds which was implied previously.

    As I have already mentioned, I would use Delphi, but definitely not as Simba's scripting language and it isn't a plausible language for GPU programming (as I described). Python would be my vote for scripting. I'd use Delphi over C if it really came to that. If you don't know, I love Scar Titan (Delphi) more than I do Simba (Pascal) and I love auto-it more than I do both of the aforementioned. Simply because of the "power" of it and it's a ton "faster" than Lape.. So again, this is where the "need for speed" comes in I guess. Although Lape may not hamper our abilities to code or to get things done fast, it's just not my cup of tea for a scripting language. Neither is Delphi. Neither is C (absolutely horrible choice). However, there's a reason we're here and not over at Scar or Autoit. Personal choice & Open Source (ability to contribute to make Simba better.. which is hard to do at Scar). The same personal choice that made Pascal our scripting language and not Python or Lua.

    To answer OP's question of what are it's strengths compared to others: "NONE". It doesn't compare to others. It's just easier to learn. That's it. I personally hate comparing languages. Just choose what's best for the Job and Delphi, C, Java, C++, certainly isn't that IMO.

    My choice is PYTHON or .NET if I even had a choice.
    Last edited by Brandon; 02-22-2015 at 08:45 PM.
    I am Ggzz..
    Hackintosher

  23. #23
    Join Date
    Dec 2010
    Posts
    483
    Mentioned
    30 Post(s)
    Quoted
    328 Post(s)

    Default

    Quote Originally Posted by slacky View Post
    Didn't mean to come of as stubborn. I pointed out 1 thing, and asked a question (badly formulated), where I asked why OpenGL would be better from C ("You also mention OpenGL, I am not sure why") which you answered (in a somewhat spiteful manner I must add).

    And yes, I do know why he passed an allocator to the plugin... Meh. So harsh for just because I asked a small simple question.

    - I think i'm done here.
    Don't be so easily offended, he didn't say anything to attack you just laid out some facts.

    No one is denying you clearly have knowledge about the matter, but certain things you claimed from the beginning are simply false. That's all Brandon or I were trying to say.

    Don't let an intellectual conversation bring you down, no body meant anything bad, and discussions like this is what help us both individually and as a community grow and become stronger and more informed developers.

  24. #24
    Join Date
    Dec 2010
    Posts
    483
    Mentioned
    30 Post(s)
    Quoted
    328 Post(s)

    Default

    Bringing back reference to the OP, I actually personally feel Java is the best approach to runescape macros. Tried and true.

    The game is written in Java, to think that Java doesn't have a bit of a dominance in that regard is silly. Reflection API alone is clearly incredible.

  25. #25
    Join Date
    Jun 2013
    Posts
    33
    Mentioned
    0 Post(s)
    Quoted
    14 Post(s)

    Default

    I have been just looking around and reading your posts @Brandon trying to learn something although a lot of it is a bit over my head You seem like you reeeeally know the technical side of just about everything.

Page 1 of 2 12 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •