Quote from: eri0o on Thu 13/10/2022 21:13:04I had an idea for refactor here, instead of the type being a thing, having different versions of this class from the same interface that each implemented their own behavior instead of all those IFs per type.
Are you speaking of a virtual inheritance? In such case these objects would have to be allocated dynamically too, one at a time, and accessed through a pointer to a base class.
Alternatively you could have a pointer to vtable in each object; then the object itself could be same struct, allocated regularily, but have a pointer to table of functions that may be different (this is C-style of override, seen, for example, in a Allegro4 BITMAP struct).
Quote from: eri0o on Thu 13/10/2022 21:13:04I don't know if this helps yet, but was looking at it and in theory this would reduce the branches.
In theory, majority if not all of these if branches may be removed by replacing if/else with a switch, similarily to how it was done with ReadValue:
https://github.com/adventuregamestudio/ags/blob/master/Engine/script/runtimescriptvalue.h#L316
I tried that recently, but found that it actually reduced the fps a little in a project I've been testing with, so I decided to leave for later.
Maybe I did something wrong, or the test was wrong. Or this particular branching was not the main problem for that particular project.
EDIT:
My belief is that ideally there should not be any branching or behavior switch at all, and all the memory access implemented similarly, somehow.
One major reason this was written in the first place was because AGS compiled script assumes 32-bit pointer size, so it won't work with 64-bit systems. Couple of people have suggested to implement a virtual memory instead, and use virtual 32-bit addresses instead of the real ones, which might fix this issue.
I suppose this is what Nick Sonneveld started to write in one of his experimental branches few years ago.