Y-Order
 

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...

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...

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.

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

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

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.

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.

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.

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 :D

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.

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

...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...

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

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.

Yeah, I get it, but then what happens if you want to have two images orbiting each other over a third background-image?

Say, we have a space image in the background, an earth image in the middle, and a moon image going around it. We need the moon to go around the earth, but never behind the space, and never high enough that it'd go over the player. If we have floating point layers, we can do it with earth=0.2, space=0,moon=0.1 to 0.3. If we have index layering, for one Stefan has to redo practically everything he made that depends on the Y thing, for two we have to hide the over-earth moon image, show the under-earth moon image...

I like my way better.

Perhaps both could be implemented in some way? *shrugs* And ofcourse you would like yours better, since you have a personal bias ;).

I duno... I just want something like

showimgnyo index,image,x,y;
a showimg command that isn't sorted w/ y order, but indicies instead.

Falados wants a new system that focuses on efficiency, Tyhm wants one that focuses on practicality. You'll never both agree unless a system can be found that achieves both. Personally I'd favour Fal's index-order system, as that could be used to achieve the same things as Tyhm's with a little midpoint scripting.

...um. Okay. With my way, one could do the orbiting-moon problem with one line. With your way, it requires hiding and showing two seperate images - because you can't change an image's index, but you can change an image's layer. Therefore, sorting by layer makes a LOT more sense than index - you can edit the heirarchy with changeimgvis, you can't edit the heirarchy at all if it's bound to the indexes. If you have img 0 over img 1, and you want to put img 0 just behind img 1, my way you just changeimgvis, your way you have to hide 0 and show 2...it's just way too much of a headache.

Babbling. I was up for 38 hours straight yesterday.

We have your implimentation and my implimentation. If Stefan uses your implimentation, the only way to sort by layers is to juggle indices - a REALLY ugly problem. If Stefan uses my implimentation, you can easily sort by indices - you just set the layer to be layer+(index/maxindex). Further, what if you want to reverse it, so instead of index 0 being the top, index 0 is the bottom - what if Stefan does it in a way inverse to what you were hoping? Your way, you have to change your image indices, everything gets ugly. My way, just change the formula to layer+1-(index+1/maxindex). Simple. Elegant. Doesn't even require a single command addition to the already rapidly expanding lexicon - just change changimgvis from int to float. Boom. Done.

They can both be done my way, they can't both be done your way, is my point. It's a good idea, but I stand by my implimentation on the grounds of expanded usefulness and simplicity.

Basically what sorting by indicies was for is things like weather and such, that require MANY MANY images and doesn't need y-order to be shown correctly. Thus ignoring the sorting process would make room to have a more realistic weather system with lots more droplets and causing minimal lag.

So really what you're shooting for is no-particular-order?

So why restrict it to being sorted by index? Index is even LESS mutable than Y, you can't change an index, it just looks stupid if you change the Y but you can do it.

Thus, my way is better. Either way would have each droplet on its own layer, but mine is honest about it.

If it uses layers it still has to run through and sort itself out by y-order.. I just need a way for it to skip all that so I can display a lot of images on the screen at once.. THAT is what I need. not a way to draw images differently.

...Stefan hisself said it doesn't even check y's unless there's an overlap. If they're all on their own layers, there will be no overlap to check.

Changeimgvis #,#;
that is what I've always used. What difference would it make? You mean like have:
showimg3 #,gfx/text,x,y,vis;
so to INCLUDE changeimgvis in it basically??
---Shifter

Hey, here's an idea. Try reading a thread before replying. I'm talking about changing the # from being always an integer to allowing floating point values as well.

Perhaps... you can always rotate the changeimgvis to what you want on a timeout or function if need-be.
---Shifter

Okay, so are you just totally unclear on the concept or what?

Read the post about the moon orbiting problem until it dawns on you.

You can change an image's index easily. Throw all the images into arrays containing the info about their location, image source and virtual layer, then sort them according to that layer and throw them onto the screen. It's not like it's complicated scripting. It'd be a little faster hardcoded, sure, but how often would you need to do something like this? Removing the inbuilt y-order sorting would more than make up for the speed hit in most cases.

And, as I explained above, they can both be done Falados' way. His is just a little more efficient. And heck, if somebody can't script a simple system like the one I described above then they have no business calling themselves scripters.

And how are the non-order imgs to be sorted when they are mixed in a level with normal imgs?
You'd have to create a new layer for non-order imgs, which would conflict with existing scripts since you'd have to put it somewhere between layer 0 and 4.
Maybe you could use layer 3, since it is to be used with light effects, and they don't often overlap, so they don't need to be sorted. But then you couldn't have the day/night effects work on your images.
However, the floating point layer idea is better...and don't argue about the time it takes to sort the images...insertion sort is quite fast (dunno if it is used), because you'd only have to sort one image in the (ordered) list of images, when it is changed.

Here's a different idea: Negate the layer index to remove y-order sorting. So changeimgvis i,-2; is like layer 2 but without y-order sorting.

Insertion sort is horribly slow when using any large amount of elements.

That would result into layer 2 being filled with sorted and non-sorted images...

NPC Code:

---

changeimgvis 200,2;

changeimgvis 201,-2;

---

how do you want to sort this?
If you say so...it would just take log2(numelements) compares...of course you can't use it on arrays, because then you'd have to move all the following elements...I thought of pointer lists. I don't know how images are stored in graal.

No, look, -2 would be a whole separate layer. Identical to 2 but without the y-order, y'see?

No way, dude, insertion sorts aren't anywhere near that fast, even if you're sorting a list that's already sorted. Each successive element to be added to the final list needs to be compared to more and more elements, and with a big list like >100 or so, the processing time is just not acceptable.

Ok, and is -2 above or under 2?

I suppose above would make most sense. But I don't hold any expectations for this system to be implemented, nor do I feel that it would be particularly beneficial. To me, Graal is fine as it is. I'm just suggesting possibilities for the fun of it.

Ungh.

Arrays? Yes it'll work, yes it'll be easy to script, but Oi. Arrays online are nightmarish. Until recently it was nearly impossible to tell if they'd been initialized, and I think it recently changed from filling with 0s on redefinition to preserving the old data. Very irritating.

Plus there's the problem of what if you're trying to do this in an overburdened system NPC. That makes it even uglier.

Advantages to my implimentation:
Does not require an additional command
Backwards compatible - changeimgvis 0 is going to be exactly the same
No display slowdown. It already checks layer before deciding to display above or below - what would it matter if it's a floating point or integer? The differencec in comparison time is negligible, if there's a difference at all.

Why are you talking about arrays in scripts? I just wondered how Graal is storing the showimgs..

The floating layers thing would be very usefull while the unsort thingy would be only usefull in a few special cases.

I can't make assumptions about how Stefan coded it, but my best guess is that each layer has its own array of images. And sorting lots of small arrays is faster than sorting one big array, which you'd need to do in your scenario.

*reviving the thread*
Nope. If an image would be placed in layer 3.5 you would put it in the array for layer 3. You'd just have to change the function to compare two images (to find out which has to be displayed first).

I have now found a situation where you would need to get around the y-order: if you want to use showimg for displaying something that should look like a gani. When you are placing a sprite in a gani it won't be sorted by the y-axis.
For showimg this could be done by adding a new command "attachimg img,attachtoimg;". So you could display a shadow and then you could attach other images to it, so you could make things hover (like you can do with ganis).
The images attached to the shadow would be sorted directly after the shadow (I know, not easy to do).

Worth noting -
you can argue until you're blue in the face that layers 1,2,3,and 4 are seperate arrays or one big array, but it doesn't change a thing.

When two objects on layer n overlap, the executable checks the y and the height, whoever has the greatest bottom-position is drawn over the loser.

Using floating point layers will do one of two things. It will reduce the number of times that two objects on layer n overlap, or it will add a single additional check to the system -
when two objects on layer (int n) overlap, the executable checks the (n%1), whoever has the greatest (n%1) is drawn over the loser. If they match, then do the y-check.

If a batcher was run which replaced all layers with layer+(y+(image's height/16))/100, it could replace a lossy compare "y1+height1 verses y2+height2" with the more efficient mask-and-compare operators of int and %1. One would just have to use the layer+etc... method when they want to do things in y-order.

Or, which might be tidier, Stefan could write a new command, changeimgvis float; which frees up changeimgvis int; to continue using the y-order sort - which is, to the exe, just the same thing as changeimgvis float; but with the layer+etc inserted behind the scenes.

In either case, it's more power for a piddling cost. Not that it matters to me much, I'm on my way out anyway, but I've always been altruistic regarding the future of Graal.

Hmm, you both have fair points. I guess it's just down to Stefan.