Solved Avoid these 2 mistakes: Out of Z boundary and Entity layering tips.

[oldyz]

Sadly, yes. I've been through a lot of stuff on my real-life including health issues, so I had to make choices about what I focused on.

---

I was having a lot of issues with controls, specially on Android but also in windows too, and I am testing a custom version @Kratus had sent to me (6392) and it works perfectly

https://twitter.com/x/status/1657538717790216193

(Btw I am testing it on an Anbernic RG 505, a powerful android device)

So even this build isn't being official, it's the build i will use when I update this game because 9 of 10 complains I received from the users are related to controls in windows.

just a heads up, kratus's engine has a couple of issues i have encountered,
one is some weird glitch when trying to stack more than 3 entities in a same place via spawnbind or just regular spawning of decoration objects.
about 1 out of 7 level loads one of those layers/entities will not show.

solution:
the entity stack/layering issue was due to using floating point (decimal) values on the entities, they work, but have issues from time to time.
for more information, see this post:

Solved - Avoid these 2 mistakes: Out of Z boundary and Entity layering tips.

Sadly, yes. I've been through a lot of stuff on my real-life including health issues, so I had to make choices about what I focused on. --- I was having a lot of issues with controls, specially on Android but also in windows too, and I am testing a custom version @Kratus had sent to me (6392)...

www.chronocrash.com

a second one is some characters that spawned off screen (widescreen) beyond a certain number of pixels would never appear (see firebrand in NS 21C plane level vs firebrand in 2019 version), i had to fix the issue with delay frames in the spawn animation, i don't remeber if i reported this to him ....

solution:
the problem is that for some reason, the older Openbor engine allowed the Aramer entity to spawn outside of the level's "Z" boundary (136pixels from top to bottom).
the Aramer was originally programmed to spawn Z position 100, and the new engine spawns the entity, but it gets stuck.
Kratus solved it by changing the Aramers Z spawn position to 110 and the Aramer functioned again

it is best practice to spawn entities within the Z boundaries of a level, and if there is a need to spawn something beyond those boundaries, you better use an override script:

As an example, in SORX I have many enemy spawns beyond Z limit like the ones in SOR3 stage 1a. I first deactivate the minZ during the spawn animation and then reactivate before the animation ends (and before the first bbox too, otherwise the entity will skip the correct frame necessary to activate the minZ again if take any hit).

C:

void minz(int flag)
{//Turns subject's to minZ status
void self = getlocalvar("self");

changeentityproperty(self, "subject_to_minz", flag);
}

Attachments​

• 
  
  1684533579132.png
  28.2 KB · Views: 0
  
  
  

 

[O Ilusionista]

one is some weird glitch when trying to stack more than 3 entities in a same place via spawnbind or just regular spawning of decoration objects.
about 1 out of 7 level loads one of those layers/entities will not show.

My game uses a lot of spawnbind objects and, so far, I had zero issues. But I will take a closer look on this.

a second one is some characters that spawned off screen (widescreen) beyond a certain number of pixels would never appear

Are you sure offscreenkill isn't killing them?

 

[oldyz]

Are you sure offscreenkill isn't killing them?

pretty sure, the entity is supposed to be well within the boundaries and i even tried to implement an offscreenkill override.
the only factor that may be at play is the fact the level scrolls from left to right.

i avoided making a fuzz about it and pretty much just fixed the issue using the layer delay tirck instead.
originally the intention of spawning the gargoyle so high up and to the right was for it to appear from the top right corner in a delayed descent fashion.

but if need be, i can provide the files if there needs to be closer look just in case

 

[Kratus]

@oldyz
Man, the "6392" is just a test build for the controller fixes using the 6391 as base. This is NOT a new engine version made by me, the code is entirely from the official 6391 with a few lines for the controller code (and some for the multihit fix) that has no connection with spawns or any other feature.

In case you find real bugs, they are all the same as the 6391 or previous builds like 6330 or 6315.

I already posted some explanations about it in the past. The entire discussion can be found in this post. I called it "6392" because it's based on the 6391, but doesn't follow the official commit number and is not considered an official stable build.

offficial

 

[oldyz]

@Kratus

the only thing i can say is that when it comes to the sprite layering issue, i noticed that it happens more often using all the versions that have the better controller mapping.

dont know the reason, dont make sense at all...

i dont have the version numbers at the moment , i am pretty sure that "6392" was one of them, plus at the time i tested using every .exe i had. (i had the latest official build exe and about 3 of the enhaced controller ones)

even the openbor latest build official has the issue , but it happens way less often.
it is something that bugs me greatly because it ruins the effect of the enhaced decorations and the only other solution would be to use animated FGlayers instead , which i still cant really use either ,since something in the scripting on the NS module is messing up something, same with the floating platform issue, i still can't fix it.

my hyphothesis is that there are some scritping issues that need to be resolved or that interfere, Bonus JZ might have made custom scripting that creates those issues - who knows
only way to discard is to do the same tests using a basic module.

the offscreen issue, i really did not look into it much
, since it was easy to resolve trough other means,
so its just something to look out for
if i have some time today i will try to recreate the problem using all engines & share my findings on your PMs

 

[Kratus]

@oldyz

If you show me a consistent way to replicate the supposed issues plus with accurate information like videos, screenshots, codes, what engine builds you tested, etc, I can take a closer look at it. Please don't get me wrong, I'm not discarding your feedback but we can't consider a certain issue as a true engine bug just with random information or hypothesis.

Usually when I suspect that a certain issue is a bug I try to replicate it on a basic BOR mod, this way we can test an unique game with different engine builds, no other script interference and a fresh "saves" folder.

On my part, the issues you reported never happened in my SOR2X game since the 6315 to the latest. You can unpack it and see by yourself that I made a huge use of offscreen elements and some with different layers as decorations (like the SOR3 disco on stage 2). On SORX it gets even worse because the SOR1 levels have bigger sizes (like the stage 8 with 6288px), but even the elements that are loaded at the "at 0" will never disappear.

 

[oldyz]

@Kratus and @O Ilusionista

i have provided a quick package with the "no show" bug

i will work on the layered sprites bug demo in the next hours

later on i will see about a clean version- especially for the one with layer problems

 

[Kratus]

later on i will see about a clean version- especially for the one with layer problems

@oldyz

I was able to replicate the "layer" issue after a few tries. However, I discovered why it happens, you are using the setlayer with with float numbers but this function was coded to use integer numbers.

In addition, background entities as decorations are commonly put with a Z value behind the player_min_z position, but in case the entity needs to stay inside the Z boundary you can use negative layer values for this purpose
However, in your game instead of using negative values, you are using decimal positive values like 1.4, 1.07, etc.

Before

Adjusted

An important thing to remember is about the layer position of panels. In case you use a panel that covers the entire screen from top to down and not only the ground, the lowest setlayer is usually -3 because from -4 and lower it will put the entity behind the panel and they will not appear. If you need more layer options, I suggest to split it into separated pieces and put some of them using fglayers, which allows you to adjust the Z layer individually.

After readjusting all setlayer values and loading the level again, everything reappeared normally. Tested the engine builds 6330, 6391, 6392 and 7123.

 

[oldyz]

thanks @Kratus
it seems that the version of the spawnbind caged people was also malfunctioning because of the floating numbers too - i will work on a proper spawnbind version and test just in case.

now i am wondering, what it the "z" value of backgrounds and bg layers as compared to setlayer values on entities...

i say this because i have seen that some fps games can have different layers in "dimensional" pockets or compartments

for example , using re-shade and n64 goldeneye, the dimension or layer where the gun appears gets to have its z depth differently from the "world" layer or dimension

In case you use a panel that covers the entire screen from top to down and not only the ground, the lowest setlayer is usually -3 because from -4 and lower it will put the entity behind the panel and they will not appear.

if the panel has a transparent hole , would they be seen?

what im trying to find out is if an entity can share the same "z space" as a bg layer or a fg layer, for example have an entity like a laughing sun hiding behind a cloud fglayer or bg layer...
i know we could have animated fg layers, but entities have some automatic behaviors that are more suited for other stuff...

 

[DCurrent]

i say this because i have seen that some fps games can have different layers in "dimensional" pockets or compartments

for example , using re-shade and n64 goldeneye, the dimension or layer where the gun appears gets to have its z depth differently from the "world" layer or dimension

They don't work like that. Everything in a game world is calculated from one set of prime coordinates, no matter what engine you're talking about. Pure 2D engines typically have three coordinate axes (X, Y, Base). Three dimensional engines (ex. OpenBOR) have four (X, Y, Z, Base). Different engines may arrange coordinates in their own way (ex, OpenBOR world coordinates are bottom to top, while Mugen is top to bottom), but they all rely on the same basic design.

Screens are two dimensional space no matter what, they can only ever have an X and Y. Screens are always drawn left to right, top to bottom.

Where engines diverge is how they control drawing order. First person shooters typically have what's called a "Z buffer". This is used in conjunction with game world position to create a final layering. Some engines have double buffer for greater accuracy. Although it's not a first person engine, OpenBOR uses a system that conceptually resembles a double buffer at the object level. First is the layer adjustment. This modifies the effective Z position in conjunction with the game world Z position and default Z position adjustments. The second is Sort ID. This is an adjustment priority that determines which item "wins" if both are at the same effective Z layer.

What tends to trip creators up is that every single object in game has a default hard coded Z layer adjustment. This is why you don't normally need to do any sort of layering yourself - it's already taken care of. If you DO want to customize your layering, you just need to be aware of those hard coded defaults so you can adjust enough to override them.

what im trying to find out is if an entity can share the same "z space" as a bg layer or a fg layer, for example have an entity like a laughing sun hiding behind a cloud fglayer or bg layer...
i know we could have animated fg layers, but entities have some automatic behaviors that are more suited for other stuff...

It's been done a dozen times over. Again, you just need to adjust enough to overcome the default positioning. Notice the construction crew walking between the equipment, specifically between the body and arm of the bucket loader at 00:30.

I wrote a little object placing script for myself to make it easier, but it's nothing you can't do by hand.




HTH,
DC

 

[oldyz]

@DCurrent​

i would like to have a separate discussion about the Z equivalencies on another topic.
i would like to make an excel tool where you can convert an entity to BG layer z values, or Fglayer Z values or viceversa.

in the case of the FPS gun thing, the gun exist on screen type thing or a separate buffer?
the only way to describe it it that the gun is in a flat layer, but it has real depth (like a mirror, it displays true 3D depth), and yet it does not effect the world.

i assumed that Openbor's HUD elements where like this, a completely separate layer buffer or "dimension" from the "panel space" but later on found out that if you set the layer of an entity at 999999-ish it actually can overcome the HUDs "space"

 

[O Ilusionista]

but later on found out that if you set the layer of an entity at 999999-ish it actually can overcome the HUDs "space"

For sure you can.
On my Avengers game, I draw lines over lifebars using a high z value.

Also, both Deadpool and Tigra has a move where they display sprites over everything on the screen, including the HUD.

Btw there is a "default" max z value for panels, but i can't remember the name now - my only contribution to the engine code was a fix on the debug text which uses it.

 

[oldyz]

oops -
here is the solution

just a heads up, kratus's engine has a couple of issues i have encountered,
one is some weird glitch when trying to stack more than 3 entities in a same place via spawnbind or just regular spawning of decoration objects.
about 1 out of 7 level loads one of those layers/entities will not show.

solution:
the entity stack/layering issue was due to using floating point (decimal) values on the entities, they work, but have issues from time to time.
for more information, see this post:

Solved - Avoid these 2 mistakes: Out of Z boundary and Entity layering tips.

Sadly, yes. I've been through a lot of stuff on my real-life including health issues, so I had to make choices about what I focused on. --- I was having a lot of issues with controls, specially on Android but also in windows too, and I am testing a custom version @Kratus had sent to me (6392)...

www.chronocrash.com

a second one is some characters that spawned off screen (widescreen) beyond a certain number of pixels would never appear (see firebrand in NS 21C plane level vs firebrand in 2019 version), i had to fix the issue with delay frames in the spawn animation, i don't remeber if i reported this to him ....

solution:
the problem is that for some reason, the older Openbor engine allowed the Aramer entity to spawn outside of the level's "Z" boundary (136pixels from top to bottom).
the Aramer was originally programmed to spawn Z position 100, and the new engine spawns the entity, but it gets stuck.
Kratus solved it by changing the Aramers Z spawn position to 110 and the Aramer functioned again

it is best practice to spawn entities within the Z boundaries of a level, and if there is a need to spawn something beyond those boundaries, you better use an override script:

As an example, in SORX I have many enemy spawns beyond Z limit like the ones in SOR3 stage 1a. I first deactivate the minZ during the spawn animation and then reactivate before the animation ends (and before the first bbox too, otherwise the entity will skip the correct frame necessary to activate the minZ again if take any hit).

C:

void minz(int flag)
{//Turns subject's to minZ status
void self = getlocalvar("self");

changeentityproperty(self, "subject_to_minz", flag);
}

Attachments​

• 
  
  1684533579132.png
  28.2 KB · Views: 0
  
  

you can see this on the first post too...

 

[magggas]

Hm.. since there are the subject_to_minz and subject_to_maxz entity commands i don't really understand what all this fuss is about. Without using this commands, no matter what engine version one will use, this is a very obvious mistake to try to spawn something beyond the allowed z bouderies set by the user itself, isn't it? So that's already a bad start or base before you even start to think about settlayer settings.
I mean, if any new user should take anything from all this as a "solution", that should rather be the "please read the manual" line. I mean that should be overall take away in my opinion since it all seems like a user error to me.
Sorry @oldyz , i'm not trying to be rude or oversmart or something, but really after reading all this i felt like your real issue here was that you werere unaware of the subject_to_minz and subject_to_maxz entity commands.
Unless i understood again something wrong, in which case i'm again sorry in advance.

 

[oldyz]

@magggas,
the reason why it did not choose to use those subject_to_minz and subject_to_maxz entity commands, was because as far as i understood the manual, it would mean that the gargoyle character would be able to move around beyond the stablished "horizon" and also move about beyond the bottom of the screen's edge.

did not test if this was the case, so back in 2019 i purposely spawned the entity that way since i saw other entities move from beyond the "horizon" into the play area and after moving in they would stay properly "corraled"
then time went on and under the new engine some stuff "broke" and so here we are...

don't worry about being rude, sincerity is good medicine.

 

[magggas]

Knowing or not knowing something it's not a crime anyway, so of course i meant all this in a good way. I also don't know everything or rather a lot i would say.

Okay i see, so if we talk just about decoration entities without ability to walk, then don't worry the entyties will not move around no matter if beyond the z boundaries spawn position. The actual purpose of the subject_to_minz and subject_to_maxz commands is to actually be able to spawn such decorative entities beyond the allowed z.

Also these commands are available with script too, so you can make an normal enemy for example use it only temporarily for it's spawn animation and then disable it again so he will not be able to move beyond allowed z afterwards. Like this for example:

@script
    void self = getlocalvar("self");

    if(frame==0){
      changeentityproperty(self, "Subject_to_MinZ", 0);
      changeentityproperty(self, "Subject_to_MaxZ", 0);
    }
    if(frame==1){
      changeentityproperty(self, "Subject_to_MinZ", 1);
      changeentityproperty(self, "Subject_to_MaxZ", 1);
    }
@end_script

 

[oldyz]

Okay i see, so if we talk just about decoration entities without ability to walk, then don't worry the entyties will not move around no matter if beyond the z boundaries spawn position. The actual purpose of the subject_to_minz and subject_to_maxz commands is to actually be able to spawn such decorative entities beyond the allowed z.

i will try this and see what happens.

unfortunately , tonight i edited the level with the decorations within the boundaries and the bugs persisted (with the floating point values)
did not try to do the proper -# solution yet since i wanted to try the spawnbind multilayering method first.
turns out that generating the multilayer decoration using "spawnbind" created more problems that may affect a future entitiy i am trying to enhance - tomorrow i will edit a level using all variables of this decoration and will try to remain as faithful to the manual as i can -

 

[magggas]

As far as i understand, i think the spawnbind is not working correctly in such case because of the way/the where you spawn your entities. So i'm suspecting that your entities are getting shifted when spawned and this is messing with the spawnbind very quickly. But no matter that, i really think you should not be using spawnbind for such purpose anyway. Just do a little more work again and do it the right way by using the subject_to_minz instead of such weird workarounds.

This worker you see in the video above, in the original game version by me, he really is spawned beyond the allowed z. He is not using any layer settings, he is just spawned there and looks in the same place as in this video.
So i strongly suggest you to first spawn everything on the z that it should, and then after that only use setlayer settings If it will be still be necessary in some cases.

Oh and one more thing. As far as being faithful to the manual, it's always good to rechecking and be aware of what's there, but keep in mind that even there not all information is correct. So just keep your faith on it within a reasonable volume

Edit: By the way after all my big talk about the subject_to_minz commands, i rechecked on my WH game the animated background entities and i'm not using these commands on them at all. It must be that entities type none already allowed to live outside the level z boundaries out of the box, which i forgot it seems. So that means my above theory about your problem could only be correct if your entities are a different type than none.
So i don't know, in order for me to give a more acurate help i would need more concrete things to look at, or know more specifics.

 

[oldyz]

@magggas
indeed, i tested the decorations with and without , no difference.

after checking my notes,
i was trying to make the elevator a "real space", but if you killed entities within the elevator, the entity or a big sprite like
Ortega would show amongst the decorations, to try and have them be a part of the wall, and thus hide stuff behind , i figured that using decimals (floating values) would allow me to give the decorations an illusion of depth, while keeping all 9 layers of sprites limited within the space of a single pixel, whie at the same time serving as a mask.

spawnbind seems to do the job - except that it does not respect the "parallax" atributes of the entities, so there is no illusion of depth...
another way of implementing this is to use a screen, i suppose, but everytime i try to do it i have failed...

the spawnbind problem, i will make another thread once i get to make some replacement content to illustrate what im trying to do