I have found something quite interesting about gE
Posted: Thu Aug 06, 2015 2:11 amNearly accidental I've discovered that the engine held variable names somewhere in the Game Mode runtime contiguous memory.
This can be the master odd for debugging, since you can get variable names directly from the memory, as a string.
Moreover, it now allows me to think even wider and perhaps I will be truly succeeding to create a better debugging system for the custom
cross-game scripting I am working on (Since it obviously cannot send the front end cross-game error/warning message).
One of the benefits of using interpreter over compiler, as Game-Editor does is that the interpreter parses each statement, while the compiler
converts the entire code into a byte code. Which means it scans for errors almost immediately, one statement after another.
This is why Game-Editor is able to find errors in our code, so fast, almost in the same time we press to Add the script.
However, I am fearing that this might be very dangerous for it confronts a variety of different constraints.
Game-Editor stores runtime allocations in arbitrary memory areas (which offset is mostly determined by the processor/heap allocator)
While we cannot even think of writing, locating the appropriate memory offset cannot be simply pre-calculated.
And yet there is still a chance. If user specifies the name of the first variable ever declared (global code is with priority),
then I can create a memory searcher that finds the appropriate offset, keeps the byte pointer iterator read-only, non-optimized (volatile),
and it must systematically check if the seed-variable is in the same memory offset as the first discovery, because Game-Editor
is unpredictable and may decide to reallocate information about variables in another instance.
This can be the master odd for debugging, since you can get variable names directly from the memory, as a string.
Moreover, it now allows me to think even wider and perhaps I will be truly succeeding to create a better debugging system for the custom
cross-game scripting I am working on (Since it obviously cannot send the front end cross-game error/warning message).
One of the benefits of using interpreter over compiler, as Game-Editor does is that the interpreter parses each statement, while the compiler
converts the entire code into a byte code. Which means it scans for errors almost immediately, one statement after another.
This is why Game-Editor is able to find errors in our code, so fast, almost in the same time we press to Add the script.
However, I am fearing that this might be very dangerous for it confronts a variety of different constraints.
Game-Editor stores runtime allocations in arbitrary memory areas (which offset is mostly determined by the processor/heap allocator)
While we cannot even think of writing, locating the appropriate memory offset cannot be simply pre-calculated.
And yet there is still a chance. If user specifies the name of the first variable ever declared (global code is with priority),
then I can create a memory searcher that finds the appropriate offset, keeps the byte pointer iterator read-only, non-optimized (volatile),
and it must systematically check if the seed-variable is in the same memory offset as the first discovery, because Game-Editor
is unpredictable and may decide to reallocate information about variables in another instance.