It’s in no way pointless if you consider I have only one year of experience in object oriented programming and that something like “null pointer exception” could pretty much mean any pointer.
I should get used to placing stuff in my code to help me debug but I never take the time. I shall.
Also, don’t consider me moved by your stupid words; every programmer runs what they program while they program it, unless he’s a proficient guru or is fond of searching hours for a bug that could be a typo.
EDIT:
Awww, screw it I’ll write it with libgdx instead and use graal assets, you win, spooon. Project is too big for graal anyway.
Jatz
April 19, 2014, 4:27am
43
AngelScript Features
Script language
Familiar syntax - The script syntax is similar to that of C or C++, with only a few differences.
Statically typed - Unlike most scripting languages that are dynamically typed this one uses the same static types as C++, and applications can register additional types.
Object oriented - The script language allows for declaration of classes, with support for single inheritance and polymorphism through interfaces.
Object handles - Pointers are not safe in a scripted environment, so AngelScript uses object handles instead. Object handles are almost like smart pointers, that control the life time of the object they hold.
Sandboxing - The library provides a secure environment for the scripts, i.e. the scripts can only access what the application explicitly exposes, and any built-in script objects are completely secure.
International support - The script files can be encoded in ASCII or UTF-8. String constants can include UTF-8 encoded characters directly or can use escape sequences to add specific unicode code points. UTF-16 encoded string literals is also supported.
Engine
Run-time compiled - The library compiles the scripts into byte code and executes the byte code through a virtual machine.
Step by step execution - The scripts may be executed line by line, for controlled execution and debugging.
Detailed exceptions - When an exception occurs information about why and where can easily be obtained.
Line interpretation - The engine can interpret separate script lines using the currently compiled script. Useful for in-game consoles.
Saving/loading byte code - The compiled bytecode can be saved and reloaded at a later time. The bytecode is platform independent.
Modular - Scripts can be compiled into modules that can be dynamically linked with each other.
Concurrent scripts - Several scripts can be executed in parallel, by suspending and resuming them one by one. This allows for easy implementation of multi-tasking schemes, or even co-routines.
Debugging support - The application can examine the call stack and the value of local variables while running the scripts. The line callback feature allows the application to use breakpoints, do profiling, etc.
Real-time capable - The execution time is deterministic and doesn’t vary.
Integration
Direct access - The script engine can directly access and use registered functions, objects, and object members without the need to write proxy functions (where native calling conventions are supported).
C++ interface - The standard application interface is C++, but a C interface can easily be written that can be used by languages that don’t interact well with C++ interfaces. It has for example successfully been used in Delphi projects.
Multithreading - The library can be used in a multithreaded environment.
Memory management - Objects are reference counted for easy management of objects that pass between script and application. An iterative garbage collector is used where circular references can occur. The application can also completely control the library’s memory usage.
(http://angelcode.com/angelscript/features.html )
Lol, Graal script.