Global Typed Pointers, Two Options — ZC Software Development

ZoriaRPG 21 Jul 2016, 07:54

I had given some thought to how to permit global typed pointers, for ZScript object types, withot co flicts with rollovers, and two ideas are at the forefront.

(1) Preallocate a set of pointers for global decs,that are never used otherwise. For example, pointers 256-511, would be reserved for global declarations of lweapon, eweapon, ffc, whatever.

(2) Make internal ZScript arrays, under the Game->Pointer for them. One, for each type:

Game->npc[214747]
Game->npc[214747]
Game->item[214747]
Game->lweapon[214747]
Game->eweapon[214747]
Game->itemdata[214747]

[MENTION=42714]Gleeok[/MENTION], what do you think?

I also still want to add typecasting between the various types, for reading pointers as float.

Gleeok 21 Jul 2016, 09:09

#1 sounds weird, and I don't like #2 at all. ...not sure what you mean by rollovers though.

Global ref types can't be saved into a save file and have it mean anything though. idk.. the simplest solution is probably the best one.

Saffith 21 Jul 2016, 16:47

Why use separate registers for pointers? They're the same data type internally; they don't need any special handling.

ZoriaRPG 22 Jul 2016, 10:53

[MENTION=42714]Gleeok[/MENTION]: As I understand, the reason for blocking the declaation of zc types globally, if that if the pointers roll over--reaching 4,294,967,295, then roling over to 1--that they'd be invalid; that the global values might be using a pointer that is assigned to another object...and that pointers would lose their value on system reset.

Preallocating global pointers, similar to global array allocation, and using a range between n and n2, for dynamic allocation, would alow global declarations, at least, I believe it would.

Grayswandir, Moosh, Dimentio, probably Evan, and I all pretty much want to be able to do global declarations for npc, ffc, and *weapon, as it'd simplify a lot of things. I'm just looking for the most reliable way to do it; although the easiest path would be ideal.

I'm not sure how, or why allocating 256 to 511 of each as global pointer values would be bad.
0: NULL
1-255: Screen objects:. Used by assignment.
256-511: Global pointers.
511-4,294,967,296: Dynamic alocation on declaration at a non-global scope.

Game-> arrays, I thought would be interesting, as their data would be saved, and we wouldn't need to change compiler, or object behaviour at all. It would allow referencing a pointer declared, for example, in the active script, from anywhere, as if it were a global pointer, by storing its value in the Gamei>Object[n] array, and reading it from there, from script, at any scope.

Being able to typecast between the zc types, and float, would likewise permit that, except...I believe that the pointers are unsigned, so zc floats would only cover half of them.

Throw me a solution that seems better than any of these, if you can think of one.

Grayswandir 23 Jul 2016, 05:35

Could we maybe rewrite the ZScript compiler to perform an additional type check whenever it references a global pointer?

Similar to option #2, we could have:

int npc_id = Game->SaveNPC(enemy);
// ...
npc n = Game->LoadNPC(npc_id);

That would let you implement it however you wanted under the hood, instead of being forced to use an array. Since we're not using uuids directly, there's no danger of getting the wrong type. Whenever an object expires, you can have it check to see if it's saved globally, and delete that entry? Or you could, as above, stick the type check into the Game->Load calls.

For reference, my current "standard" workaround is to store an "id" in the misc array for each object. The NPC_ScreenIndex(id) and similar functions build an object_id -> screen_index mapping the first time they're called in a given frame.