Y-Order

[Falcor]

Most of you notice that showing lots of images on screen will generate a large ammount of lag. This is in large part due to y-order... Determining which image will go over the other image. I propose another showimg command to do away with y-order. Weather effects and things that require a lot of images do not need y order. In my experience, NONE of the things I ever made required yorder to look good, infact I needed work around it with the imagevis layers @_@. It would be perfect if the showimg would determine which image drew over what other images if they were determined by their image index. The higher indecies draw over the lower ones...

[Kaimetsu]

Perhaps a special layer could be reserved, on which no y-order sorting is performed.

[Falcor]

Originally posted by Kaimetsu
Perhaps a special layer could be reserved, on which no y-order sorting is performed.

*shrugs* We would need 2 layers I guess then. one for status layer, and one for the level layer...

[Tyhm]

No, we need floating point layers.

Layer 0 - traditional background
Layer 0.1 - over Layer 0, regardless of Y, but still below players....

The trouble is that then, if you have ganis based on ganiscripted showimgs (since you can't just apply coloreffect to varying images directly, much to my chagrine - it's in the buffer or it's not, there's no sprites that aren't buffered), you still get players walking through each other, which could be irritating.

[Kaimetsu]

Originally posted by Tyhm
No, we need floating point layers.

Layer 0 - traditional background
Layer 0.1 - over Layer 0, regardless of Y, but still below players...

That'd probably be even slower. Because all images would have to be sorted first for layer and then for Y order.

[Falcor]

Originally posted by Tyhm
No, we need floating point layers.

Layer 0 - traditional background
Layer 0.1 - over Layer 0, regardless of Y, but still below players....

The trouble is that then, if you have ganis based on ganiscripted showimgs (since you can't just apply coloreffect to varying images directly, much to my chagrine - it's in the buffer or it's not, there's no sprites that aren't buffered), you still get players walking through each other, which could be irritating.

To point was to do away with y-order all together so that showing many images created very little lag.

[Tyhm]

Ah yes, but if no two images are on the same layer, there is no y-order problem. Your images are presorted.

The hazard with "Just doing away with it" is that what, then, happens when you have two images of equal layer overlapping? Do you flicker between one being on top of the other?

It's necessary, for now. In a perfect world we could do away with it and convert all existing image layers to be layer+(imagey/64) to emulate y-layering.

[Falcor]

I don't think you understand... It would be a wiser way to instead sort the images by their indicies... Thus the higher indexes would draw over the lower ones... that way if you have 2 images on the same x/y, they wont flicker between eachother because the higher index will always stay on top.

[Kaimetsu]

Originally posted by Tyhm
Ah yes, but if no two images are on the same layer, there is no y-order problem. Your images are presorted.

Not at all. If I do:

for(i=0;i!=1000;i++){
showimg i,blah,blah,blah;
changeimgvis i,random(0,100);
}

then Graal's gonna have a list of images in a huge 1000-element array, all with different layer values. Before you can draw those onto the screen, you have to sort them according to their layer. At least with the current system it can divide the images across multiple arrays - I hope we can all see that sorting two 500-element arrays is faster than one 1000-element array.

[Admins]

Normally the sorting is not a problem, only when many objects are on exactly the same position then it can lag (like when having 200 objects on the same market basket) but i could use the npc id or showimg index to prevent the flickering.
The y order is needed, most of my stuff really needs it. You only see the need for it when you don't have it

[Com013]

Originally posted by Tyhm
No, we need floating point layers.

Layer 0 - traditional background
Layer 0.1 - over Layer 0, regardless of Y, but still below players....

This would also be usefull for attachplayertoobj.
Instead of putting the player one layer above the NPC, you'd put him/her half a layer above it.
I haven't tried this, but I think when you are currently attaching a player to an NPC in the layer 1, the player is in layer 2, so the NPCs using "drawoverplayer" wouldn't be displayed correctly anymore.
I'm not sure whether this is the case or not, but I think it is.
I'll check later.

[Falcor]

Originally posted by Stefan
Normally the sorting is not a problem, only when many objects are on exactly the same position then it can lag (like when having 200 objects on the same market basket) but i could use the npc id or showimg index to prevent the flickering.
The y order is needed, most of my stuff really needs it. You only see the need for it when you don't have it

Well, a way to skip the y-order would be nice =\

[Tyhm]

...SUCH AS FLOATING POINT LAYERS!

Then you can have a floor tile, it's layer 0.
Then a mouse running across the floor tile, it's layer 0.1
Then an ant running under the mouse, that'd be layer 0.05
Then a cat chasing the mouse, he can be layer 0.2
Then a dog chasing the cat, layer 0.3...

You see where I'm going with this? The dog is always above the Drawunderplayer layer, but below the Player layer - and Y Ordering doesn't apply to ANY of these NPCs, as they all are on their own layers!!!

That would make my job soo much easier....

Yours too. You want it to go off index instead of y? Easy.
for(this.i=0;this.i<100;this.i++){
showimg this.i,frog.png,random(0,62),random(0,62);
changeimgvis this.i,this.i/100;
}
You get 100 frogs all over the place, each on layers determined by index instead of y. Frogs with lower y values but higher indices are drawn over frogs with higher y values and lower indices.
At least tell me I'm making sense here...

[Kaimetsu]

You're making sense. But, again, efficiency.

[Falcor]

No Tyhm, I wasn't asking for a work-around, I was really asking for a way to sort the order by incidies instead of sorting them by y order. Please tell me you understand that much.