that may be completely offtopic, but however:

what about BMFont? are you going to continue to work on it too?

not that there is something wrong, besides a small bug:
when i choose a font that has no characters on another page and then reselect a font that has characters on other pages, the list on the right does not reappear ;-)

also it would be nice if zero-amount kernings would not be exported and if the header included the number of exported characters. :-)

thanks a lot!

My 2 pennies... RE-EDITED

Quote:
- Context redesign -
The context as it is now will be removed, and replaced by a new context
interface and a thread interface.
The context holds the environment in which threads are executed. Thus it will
keep track of global variables and memory allocations, shared between threads.
A thread will only control the execution of a script, i.e. hold the call stack
while it is running. Thus it will not be necessary to keep the call stack in
memory when it is not used.
Unless, non-shared global variables are implemented, this redesign is pretty
useless as the contexts will not hold anything.

perfect, i was just trying to hack the engine to hold scripts in multiple threads,
but with shared memory and locking mechanizms... i think a script could be
spanned over a new thread when executed, while the main program is receiveing callbacks
of the execution status. obviously the engine could allow to execute co-scripts instead
of threads, depending on the needs. the context will manage locking and memory
accesses of shared/non-shared globals.

Quote:
- Namespaces -
With the addition of namespaces the scripts that previously had to be compiled
in separate modules, can now be compiled in one module and still use the same
names. The benefit for this is the better reutilization of common functions.
Modules will still exist, of course.

the namespace addition is something very useful for not dirtying the global
namespace with lots of similar names, especially when dealing with global objects and configuration variables.

Quote:
- Shared/non-shared global variables -
A global variable can be marked as shared between contexts, i.e. all contexts
referencing the same module will access the same memory for that variable.
A non-shared global variable is local to the context, i.e. each context has
it's own instance of the variable.
By default the global variables are shared.

this is good, even if i don't use it too much, but some other people could...

Quote:
- Registerable context properties -
A context property is a non-shared global variable registered from the
application. After creating the context, the context property must also be
set, otherwise a null pointer exception will occur.

this is a bit obscure, could you explain it a bit more ?

Quote:
- Remove the bits types -
I'll remove the bits type. The bitwise operators will instead work on the
integer types.
The advantage is the better compatibility with C++'s types. Easier automatic
mapping of integer types to angelscript types and vice versa.
The drawback is the lack of direct manipulation of bits in double or float
types. But if this is wanted the application can easily write functions to
allow the bitwise conversion for these types.

ok 100% with you ! i've never used the bits type since i've registered a BitArray class that manages and check individual bits internally.

Quote:
- Add the int64 and uint64 types -
Although not used a lot I want to add these types as built-in types, also
for better compatibility with C++'s types.

perfect! i was lacking these types when i've encountered some functions to publish in scripts that was playing with overall frames of a a played video streams...

Quote:
- Improved any type -
I'll possibly rename the any type to 'var', which I feel is a better name.
I want this type work more like the variants of &#106avascript or VBScript, i.e.
you should be able to assign any type to it, and then perform operations on it.
All the operators should work, and the meaning will depend on the contents of
the any type.
It may not work for method calls, as that requires compile time knowledge of
the type. So for objects, the type will only work as a container, but for
primitives the type should work just fine. It will also work for string
concatenations etc.

yes, even this could throw in a lot of strange behaviours when dealing with multiple operations based on the "internal type" of the any: i think a massive use of the "var" will lead to a general confusion. one of the things that impressed my attention in AS is the strong typing: when u write script you are sure that what u write is what u intend to do. if i want to use dynamic objects that will hold everything i'll choose something like &#106avascript, with function objects and all threated in the same way: but this can make you loose the control over the script and make you write something that can compile but produces incorrect unpredictable results (i've experienced this in a lot of web applications over there)...<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Unified way to access script arguments -<br>The SetArgDWord, SetArgObject, etc, functions will be replaced with<br>GetArgPointer and GetArgTypeId(), likewise for return value. This will<br>simplify the library implementation, and also make it easier to implement<br>automatic argument assignments from outside the library, e.g. through<br>templates.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>you mean SetArgPointer and SetVarTypeId or i'm wrong here ?<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Static arrays -<br>Allow use of static arrays in the scripts, e.g. int ar[3]. These will be<br>directly compatible with C++ arrays. They will not be objects, so it will<br>not be possible to store a handle for a static array, but they can be passed<br>by reference to functions.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>whau this is weird ! it opens up a lot of interesting use cases<br>and saves a lot of typing too !<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Variable argument type -<br>I'm thinking about allowing the application to register functions that take<br>variable types as argument. It would look something like this: void func(?&).<br>The function would then receive a reference to the value, as well as the type<br>id.<br>This can be useful for implementing generic container classes.<br>When overloading a function with this type, the variable type has the least<br>priority.<br><br>- Variable argument count -<br>I want to be able to support the ... parameter declaration. I will not<br>implement it as loosely as C does it. Instead the function will receive the<br>argument count, and be able to access both the value and the type of the<br>value. This will make the use of the ... in scripts just as safe as any other<br>function.<br>The script will have to add an extra keyword for parameters if the argument<br>is support to be a return value, something like: func( (out)arg );<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>splendid! &#111;ne of the thing i lack a lot is the default argument value<br>for the functions. if i have something like this in c++:<br> void x (int a = 0, int b = 1, int c = 2, int d = 3);<br>i have to register 5 different functions all with<br> "void x ();"<br> "void x (int a);"<br> "void x (int a, int b);"<br> "void x (int a, int b, int c);"<br> "void x (int a, int b, int c, int d);"<br>could be avoided with &#111;nly &#111;ne call:<br> register ("void x (int a = 0, int b = 1, int c = 2, int d = 3)",...)<br> isn't it ?<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Data structures -<br>The struct will come back to AngelScript. Now it will be used to allow the<br>scripts to declare the exact memory layout of a structure. There will be no<br>hidden members of a struct, and the packing can be controlled exactly. This<br>will make the struct compatible with C++ structs, and allow for easier data<br>manipulation in complex memory layouts, such as data files, etc.<br>It will not be possible to store a handle to a struct, nor will the struct be<br>able to inherit from another class or struct.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>nice &#111;ne. i was asking myself why the script structure desappeared<br>from time to time !<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- AngelScript Manager -<br>This is an addon for the script engine. Kind of a layer above the library.<br>* It will make the engine easier to use.<br>* It should implement the script loading with include management.<br>* It should implement script execution with timeout and garbage collection.<br>* It should implement concurrent script execution, and also co-routines.<br>* It should also implement debugging features, such as variable enumeration,<br> setting breakpoints, stepping through the code, etc.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>i agree with you, even if this could be difficult to delineate in a good<br>interface. if you look into the angeljuice trunk, under<br>AngelJuice_ScriptablEngine i've bundled all that features already. give it an<br>eye, but forget to find a clean / polished interface (not yet!)<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Engine properties -<br>It should be possible to dynamically set some engine properties, such as<br>ALLOW_UNSAFE_REFERENCES, ALLOW_POINTERS, etc. This will make the library<br>equal for all, and make it easier to test these features as I can test all<br>features without having to recompile the library.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>why not ? i think of a general engine modularity in which you can deliberately<br>make use or completely remove support for unsafe references, pointers, structs and classes, interfaces, try catch blocks, and even let the programmer change slightly the "core" syntax, letting him choose if he wants "begin" over "{", or taking case into account when dealing with the syntax (use "InT x" instead of "int x" for example), even change the name of the registered base types (i know something of this can already be done, but i'm thinking more wisely) or suppress some of them (blocking the use of the floats/double type for examples). <br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Return of pointers -<br>Implement pointer support again. Now with full support for access, type casts,<br>etc.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>THIS IS THE MOST IMPORTANT THING I'LL LIKE TO SEE IMPLEMENETED SOON !<br>(POINTERS ARE THE &#79;NLY THING THAT MAKES ME STILL STICK TOGHETER WITH C++)<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- A super class for all script classes -<br>Maybe a super class for all script classes can be implemented.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>interesting, but not so important. what kind of functions/properties it will hold ?<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Automatic translation of the string type to other C++ built-in types -<br>In C++ it is very common to use at least two different representations of<br>character strings, e.g. std::string and char*. I want to allow AngelScript<br>to automatically translate the registered string type to either of them so<br>that the application doesn't have to use wrapper functions.<br>It will probably need a new behaviour &#111;n the string type, as well as a new<br>indicator when registering the function that needs the translation.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>yeah this is a must have... but i have a really kicking ass registered String class...<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>Suggestion by Manu Evans.<br>- Getters and Setters for properties -<br>This will allow the application to register a couple of functions to<br>manipulate properties.<br>I need to investigate the complications of this. What happens for example<br>if a property is passed by reference to a function?<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>i don't see the point of being too similar with VB side of the moon...<br>i better manipulate directly the properties, and if i need to do more things<br>when getting/setting, i'll register the getters and setters manually from C++, and &#111;nly if i need to !<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Function pointers -<br>Allow use of function pointers. I think I'll require a typedef to define the<br>signature of the function, which will simplify the code.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>YEEEEEES ! this is even better than pointers to classes or variables... i think about having the possibility of passing a "void*" in the script and then explicit cast the function ...<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Registerable cast behaviours -<br>It should be possible to register cast behaviours for types, so that both<br>implicit and explicit casts between registered types can be performed.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>another important strike ! i've already talk about this &#111;n the casting thread...<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Registration of true constants and enums -<br>It should be possible to register literal constants, and also enums.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>good &#111;ne, but i also see a lot of use with the "static" word... static<br>globals, static Class members, static Class functions: it will mimics much better when mapping a C++ object to its AS couterpart (i have a lot of static Class members registered as global function... and is a dirty situtation, especially when i look at the global namespace...)<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Implement try/catch statements in the scripts -<br>The catch statement will allow the script to recover from an exception. The<br>type of exception that was thrown can be accessed from the application, if it<br>wishes to implement such a function.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>nice &#111;ne, i lack this a lot !<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Persistent script states -<br>It would be great if it was possible to save/load the script state, including<br>the context stack.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>interesting<br><br><!--QUOTE--><BLOCKQUOTE><span class="smallfont">Quote:</span><table border=0 cellpadding=4 cellspacing=0 width="95%"><tr><td class=quote><!--/QUOTE--><!--STARTQUOTE--><br>- Compile to native code JIT -<br>This would definitely speed up the execution speed. I do not want to loose<br>functionality though, such as the ability to set breakpoints, co-routines,<br>etc.<br><!--QUOTE--></td></tr></table></BLOCKQUOTE><!--/QUOTE--><!--ENDQUOTE--><br>i agree, even this could slow down implementation of new features. i think<br>this should be planned before starting to grow much implementing new features...<br>i think this should be and addon, not a complete replacement...<br><br><br>i will add:<br><br>- Give a common definition to the bytecode, that should look the same &#111;n all<br>architectures (big-little endian, mac, ppc, intel, mips) so a bytecode i have<br>here, i can run it &#111;n any other implementation without worrying about its endianness -<br>- Pragmas to configure the engine (stack sizes for example) when script will be executed -<br>- Objects class inheritance as well as interface inheritance -<br>- Possibility to decouple method declaration from implementation (ala C++) -<br>- Possibility to not use this keyword inside the methods of an object - <br>- Some sort of introspection tools to be used directly from the script side to know the type of the objects at runtime -<br>- Bytecode optimizer: while browsing some time ago i've found another scripting engine out there that have an interesting feature, a bytecode optimizer... give it an eye, overall optimization could be even ~40% gain in execution speed ! (http://www.jewe.org/jewelscript/) anyway i don't mean to copy another project... -<br><br>i think i'll sleep this night and post some more nightmares tomorrow ;)<br>i'll keep this updated...<br><br><!--EDIT--><span class=editedby><!--/EDIT-->[Edited by - kunitoki on November 6, 2006 4:16:20 PM]<!--EDIT--></span><!--/EDIT-->

This is slightly off topic (as per feedback), but you have done an amazing job so far and I wanted to congratulate you on that. We have used AngelScript in the past for a school project and it turned out to be quite an adventure. Although today I tend to stick with a CLR profile (as a scripting language), AngelScript will always be one of the things I keep close at hand :-).

NOTE: for function pointers in general, my advise would be to check out the latest C++ standard draft. They have a recently adopted a proposal for a neat fresh syntax for both static and member function pointers.

see previous post... edited ;)