[2.xx] Expanded void Remove()

[SUCCESSOR]

simply because if a user can create a pointer, they should be able to directly remove it. It's tidier that way.

Pointers aren't ever deleted unless they go out of scope. They just stop pointing to anything, become invalid. C++ allows you to delete a pointer that is invalid or point to null but it doesn't actually do anything. It just doesn't give an error.

[ZoriaRPG]

I'm not sure what point there is arguing this topic... I never once, used the word 'delete', so now you're just meddling with semantics because you clearly oppose this, for whatever reason.

I don't care if the stack and heap are relieved of the pointer, and data, by release, by remove_pointer; or by delete + set to NULL. I'm not even sure why we're still discussing this, except that you seem to care about it for whatever reason. I'm curious what aspect of this, as a suggestion, is problematic to you, as I can live either way. As long as whatever function used, doesn't conflict with the present remove() method, it shouldn't matter to anyone if the pointer is packing a lunch for a tour of Jupiter.

[SUCCESSOR]

Whoa, can we not have a civil discussion? Maybe you should take a walk of one of those pills that makes one "chill".

I think the on going problem of this discussion is you mixing up pointers with objects. You can call it semantics but when you are taking about removing pointers you really throw me off. I am not trying to get you all wound up or anything. It truly took me until that last post to realize you meant that you wanted to remove an object and be able to check if it is valid without waiting for the next frame.

I have nothing against it being internalized or changing the way it works or isValid() works so that the results are instantaneous. Then again aren't there several things that you have to wait a frame for?

Instead of writing custom functions you could simply add another condition anytime you check isValid().

if(item->isValid() || item->X == 32768)

if(npc->isValid() || npc->HP == HP_SILENT)

if(eweapon->isValid || eweapon->DeadState == WDS_DEAD)

[ZoriaRPG]

No worries. I have no problems with debate, or discussion: It just seemed as if you were arguing against a change, that didn't seem rational, whilst simultaneously misrepresenting what I was discussing. I'm not a C++ expert, but I know three valid ways to achieve a satisfactory remove result. As I mentioned, even delete is possible--if you also remember to set the pointer to NULL, unless you want nasty memory leaks--but as you said, it doesn't achieve much, and release would be more appropriate here. I'm reasonably confident that ZC does that now, on its own; but there is no way to instruct that release directly.

I truly don't know what happens to the pointer, on the stack, when it's removed, after a frame, but I believe that the register used by it, is freed at that time, but not before. Unfortunately, unless ZConsole can tell me--pretty sure it cannot--I can't view the stack in real-time to determine what changes. There are a finite number of concurrent pointers available at all times: 256 as I understand; perhaps 255--then again, there are 4095 array pointers, so perhaps other object type pointers / vectors share the same regs as arrays. I've never seen the source, so I simply don't know how it's set up.

Conjecture follows: Until one is released, the register using it is unavailable. If you exceed the number of available regs for pointers, overflows occur. That's pretty much standard, common sense. Nothing I am doing now, could do that, but I see it as a potential event in the future, given some of what I'd like to accomplish. Then again, a far higher priority wish-list item, is declaration of complex datatypes a ta global level (that thread is also here, with explanation of my reasons), because that would make them more useful...and is far more pertinent to what I'm doing at present, than this.

Simultaneously, the data for a pointer is maintained on the heap, as long as that pointer is not directed at NULL. If for some reason, I wish to create, and destroy, 100 objects at a time, with several iterations thereof, in a frame, an internalised remove() would permit that; whereas the present remove, would not. That may sound silly, until you consider that in order to replicate some things that are unnatural to ZC, I would need to define construct objects to set up non-uniform hitboxes. Each of those may contain 20 or more objects (overlapping). if collision occurs, each of those must die at once, and be replaced with 20, smaller objects in a different formation.

Consider replicating vector-graphics objects, such as the asteroids in 'Asteroids', with draw commands. The polygons would be filled, at each line, and point, with very small (invisible) objects, that have a definable hitbox. That would permit creating precise hitboxes for irregular shapes, that can change, rotate, and otherwise be manipulated. We're talking about hitboxes between 1px and 10px in size.

I know ZC was never meant for that, but it is possible. Mass manipulation of things like this, would flow better, if it was possible to deallocate the registers in use.

As to the proposed statements, I make functions to do these things, pretty much in the form of macros. I mean that. I eve have a function NAND(boolA,boolB) , and custom NOR and XOR functions very much the same, plus NAND (int arr) . I'm missing a few complex logic operators that deal with more than two values, but I never object to more functions. It's not as if I have a finite amount of space for them.

Witht he present Remove() functions, Remove(n) already sets HP silent, and moves the enemy to a specific position. Likewise, Remove(l) or Remove(e) move the object to the same coordinates; so by packaging !isValid && coordinates, I can return if a pointer is still in use this frame. I can't deallocate it, but at least I can pass reading it. Remove(f) is one of the few that differs, as I recall, but I have isOnscreen() and isOffScreen functions that I can use as a totality, that include the isValid() function, so I need only make one call to achieve a goal.

This becomes critical, when you have for loops nested 4 to 6 levels deep, running every frame; as optimising them to ignore invalid objects becomes mandatory. Users with high-performance systems won;t notice a difference, but testing that type of compound / nested loop on older hardware truly shows how much of an impact it can have. That said, I likely do need to expand my definitions for object validity of other sorts, do that I can skip them if other conditions also apply (NAND, AND).

The only problem with using all these self-defined functions, is that sharing code becomes impossible without requiring the same resources, or heavily modifying it. I'll usually supply an external header with compatibility functions if people want only specific portions of what I'm using for something else, and let them sort it out if they want to strip it down to essentials. Otherwise, it all goes into the custom engine, and becomes invisible to a user that would want to make the system work out of the box. (I plan to package beta, and later releases, with at least two .qst templates, so that people never need to touch most of the header to make use of it.)