Nice job!
But it's not I that I am denying you can draw an iso grid with 1 object or using tiles. My point was that if you wanted to make say a cube at the front and a cube at the back draw with a different blend mode (which interrupts draw pipeline), you would need to do it when drawing each one right? You have to turn it on and back off in each case when drawing whatever is at that coordinate. Unlike, say, a pure 2d game where the draw order is less important, you can't change your blend mode, group your 'items' or coords that need that blend mode together, and draw them together then reset your blend mode (which would mean you could draw 20 things with you rblend mode with only one switch), because then you lose the depth ordering that the isometric projection relies on. Because the one at the back needs to be drawn first (or have lowest depth), the one at the front last (or highest). If you see what I mean? I'm not sure if thats what OP was asking exactly though.
Oh I see what you mean now.
You mean that each "batch" must be drawn in seperate "batch" when you change blend mode, and because we need the previous ( bigger depth ) items to be drawn first in order for
blend to work correctly, we can't "batch" all items with same blend mode together. I think I understood what you meant now.
Well there is something I don't understand right now... how in the hell would sending a couple of 2d blendng stuff to the video card lag your game then?
I don't think the problem comes from the actual blending problem. In such case I would think it actually comes from the way you draw stuff or the number of
objects ( this is my current prefered hypothesis ) running in the room at the same time.
If you run this: draw_text( 16, 16, string( instance_count( all ) ) )
how many instances are in the room?
If the number is higher than 60, you're game is not optimal.
If the number is higher than 100, you're game is currently running slower than it should
if the number is even higher, than something's wrong lol.
Maybe you could draw static stuff on surfaces? This could potentially remove a lot of drawing/blending from each render loop?
For instance, a shadow from a wall doesn't need to be rerendered all the time, try rendering it on a surface and wait until "something" makes
the shadow change. this is the only alternative I can suggest :/
Regards,
CedSharp