in GDScript there is static and dynamic variables, we need more static ones for better performance while keeping the language easy!
static variables:
Data Type Size Stores
byte 8-bit Whole numbers from -128 to 127
short 16-bit Whole numbers from -32,768 to 32,767
int 32-bit Whole numbers from -2.1B to 2.1B
long 64-bit Whole numbers from -9 quintillion to 9 quintillion
float 32-bit Decimal numbers (about 7 decimal places)
double 64-bit Decimal numbers (about 15-16 decimal places)
char 16-bit A single character (e.g., 'A', '9', '#')
string 8-â bit An ifinite amount of letters(e.g., "Hello World!")
boolean 1-bit Only true or false
and also booleans should work like this:
var collected: bool = true
or like this:
var collected: bool = 1
if we use 1 for true and 0 for false, extra performance will arrive!
functions can be typed like:
func optimizing() -> void:
pass
or
void optimizing(){
}
and now you can choose if you want semi-colons" ; " or not!
move_and_slide()
or
move_and_slide();
but if you add semicolons, you also have to add them at the whole function or you will get errors.
i hope they get added, because this is really good for both begginners and pros!
{} has its uses but I donât understand why being able to declare a function without func improves readability in the context of the rest of GDscriptâs naming conventions
but if you add semicolons, you also have to add them at the whole function or you will get errors
Why? Current setup works fine. I use semicolons for when two lines are short enough that itâs neater to merge them into one:
func update_camrot():
if camrot != toplayer.get_node("playr1").get_node("playr1_cam_hinge").rotation_degrees:
camrot=toplayer.get_node("playr1").get_node("playr1_cam_hinge").rotation_degrees
camrot_changed=true; return
camrot_changed=false
and thatâs all theyâre really good for tbh
Wanting more variable types makes sense but at this point just use C#
Booleans
1 for true means that reduced to 8 bits 0000 0001 is true. What would 2 be?
In fact wouldnât -1 be a far better representation of true (all bits 1)?
IMO the only reasonable is 0 for false and any non-zero number is true.
And that is the way it is currently (I think): printt(int(true), bool(12), bool(0), int(false)) 1 true false 0
This line: var collected: bool = 1
is valid GDScript code.
You can add semi-colons as is however there is no restriction on using them for the entire function.
The extra data types might be added, but the performance benefits would be really, really minor in vast majority of cases.
The alternative function syntax would just be an alternative syntax withou any performance difference whatsoever. I really donât see any reason for it.
GDscript doesnât complie⌠sorta. I donât know the specifics but itâs not crunched down like C# is, the editor runs it straight from the text and there are options for how itâs exported
Open up the python interpretor and type this: from __future__ import braces
Iâm on their side. GDScript chose to use syntax similar to python, with colons to denote code blocks and enforced indentation. Personally, I like C-style code with braces and semicolons better, but itâs trivial to switch between these two paradigms when using a different language.
With Godot being over 10 years old, I think itâs a very bad idea to add syntax options to GDScript. If you really want to code C-style, you can use C#/Mono instead of GDScript. Adding syntax options reduces the intelligibility and simplicity of GDScript.
In terms of the static types, I think adding these types could be useful. I would like to see GDScript add an option to enforce static typing in the linter. I often forget to use static literals like &ââ, ^ââ, ; int, etc because the program functions without them and I wasnât forced to think about the type. Is that just me?
Thereâs simply a program (in this case, the Godot engine) that interprets your source file instead of having the CPU read machine instructions that could result from that file. It reads every line, decodes the statements you have entered and executes what they are directing it to do.
In fact, the CPU itself is just a fancy interpreter, but for its own machine language (although there have been CPUs that interpret high level languages, like Lisp).
Java compiles its programs down to bytecode, so they will interpreted by its own virtual CPU (the JVM). Itâs a hybrid approach and in some cases that makes Java a compiled language, since many implementations of JVM are actual hardware (for example, in credit cards)
Not true. It should also be mentioned that having booleans be only one bit wide is a not-so-useful, at best, or a very bad idea, at worst.
CPUs fetch data from memory (and operate on it) in whole bytes, not individual bits, which means that a boolean would need, afterall, to occupy not only one bit, but 7 more bits as well, so the data can be well aligned in memory. Plus, having the false value be 0 and the true value be anything but zero (instead of using 0 and 1 only) means that a falsehood/truth test becomes simply a check of âis equal to 0?â rather than the more complex âis it 0 or 1?â.
If you check the standards of compiled languages, you will see that booleans are always defined as a byte long, for that very reason.
This applies to interpreted languages (like GDScript) as well, as the values that you declare in a script will have to be stored in actual memory. Godot going out of its way to ensure a boolean is stored as one bit and one bit only would be a very wasteful endeavour, especially when, for modern memory standards, having 7 more bits is quite negligible.
The only case âone bit booleansâ are ever really useful is when related flags are grouped together as a single integer; then, you can use bitwise operations to see whether some flags are raised or not.
If I understand this correctly, GDScript is neither compiled nor interpreted⌠The code is stored as text, and parsed at runtime when loading. Then it is compiled into an intermediary byte-code, which is the thing that is interpreted by the engine.
However this is completely besides the point.
GDScript is not meant for performance-intensive computations - and thatâs fine. All the heavy lifting is done by the Godot engine itself via its physics and graphics subsystems, as well as its vast library of functions that you can call from GDScript. But GDScript itself is for higher level stuff. For the vast majority of cases this is completely enough. If you feel like GDScript is not fast enough, then the first thing you should ask yourself is - âCan I restructure my game so that more of the heavy calculations are done by Godot itself?â
In the rare cases where itâs not possible, then yes - go for C# or even C/C++, depending on the specifics of what you need to do. GDScript isnât meant to be âperfect for every possible use caseâ - itâs meant to be âgood enough for the vast majority of use casesâ.
With this in mind then, the extra data types also become less attractive. Thereâs nothing you can do with a float that you cannot do with a double (the default GDScript floating point type). Thereâs nothing you can do with a char that you cannot do with a string. Etc.
The more specific types are useful in languages which aim to maximize performance - but GDScript isnât trying to do that. Instead it chose simplicity and fast compilation as a goal.
That said, I am a big fan of strongly typed languages and powerful type systems - it allows to catch a lot of bugs early, plus some performance optimizations. Always annotate your variables, kids!
