Z in xyzuv[]

Has anybody successfully changed the 'z' in a frame's xyzuv[] array?
The following code just makes the image disappear when I change (what I think is) the Z pos.

SuperStrict
Function tg_setz(image:TImage , z:Float,frame:Int=0)
	Local myframe:TD3D7ImageFrame=TD3D7ImageFrame(image.frame(frame) )
	myframe.xyzuv[2]=z
	myframe.xyzuv[8]=z
	myframe.xyzuv[14]=z
	myframe.xyzuv[20]=z
End Function
Graphics 800,600
Local red:TImage=LoadImage("red.png")
Local green:TImage=LoadImage("green.png")
Local z1:Float
While Not KeyHit(KEY_ESCAPE)
	If MouseHit(1)
		z1:+0.1
		tg_setz(red,z1)
	EndIf
	If MouseHit(2)
		z1:-0.1
		tg_setz(red,z1)
	EndIf
	Cls
	DrawImage RED,0,0
	DrawImage GREEN,100,100
	Flip
Wend

p.s. I realise I can use different lists for different 'z' values to achieve the same result.

You would need to have a perspective projection in the projection matrix in order for it to know how to convert your Z coordinates to screen coordinates, otherwise it will appear to be flat and who knows maybe if it's not set up you could be putting your object outside of the entire visible range.

its especially useless as the gl side does not use it at all and you surely don't want to enforce dx7 when opengl is the worlds better chance on "real computers"

@ImaginaryHuman, You could be right. I thought it might be the projection matrix as well (e.g. the depth value) but haven't got it to do anything different yet.

@Dreamora

What makes you think I have any interest in gl or "real computers" for this topic?

Well I assumed you want this for a game, not for personally anti boringness, so others are going to see the result of it as well, right? :)

For dedicated cards from ATI and NVIDIA, OpenGL is the far better choice (50-100% more performance). For crossplattform its a must choice
As OpenGL uses TGLImageFrame you would need to modify both to have a z value in Max2D (and logically add the projection to both drivers)

thats the main reason I pointed that out.
and just to mention that: without further modifications it will not work anyway. the state system and the like of BM are especially targeted its current usage.

No, wrong.

I have no interest in crossplatform in this situation which is why I am using DX.

Now that's why I posted.
a) If somebody else has done this, how did you do it?
b) If further modifications are required... what modifications?
c) How does affect the problem and what would need to be done about it.

Well how does it affect it: z is not taken into account on the state settings. projection isn't existing in it. This means that you must ensuer that resets and the like take this information into account as well and reset it to your "start" state for example.
Because otherwise the projection is gone etc.

Don't know if the clip planes from the SetViewport will need work but potentially they do.
Different things are not setup in Max2D as it is not meant to have depth so you might struggle over issues that only exist due to the projection.

And no, so far nobody has done it. Reason is simple: Max2D is now even svn updateable.
If you want to have depth, I would suggest writting an own specific driver for it so you don't mess with the base and especially have the control over future changes. i don't know how well the max2d dx implementations are because with true depth potentially would better focus on batching / "single surface" usage for the different images as true depth will remove the need of drawing orders to define "in front" and "behind"

Hmmm, just seems odd that D3D7Max2D driver actually passes a Z=0 value. I was hoping it was taken into account but never used.


I am prepared to believe that but still thought it worth checking. Where do you get your information from that nobody has done this?


Don't understand how the two are related but nevermind.

Yes, that is right.

P.S. In case others are wondering: I am trying to do this just for the fun of it. If it *can* work and is not too clunky and is much quicker than sorting/layering/whatevering then it might be useful.

Well, most likely because otherwise someone would have shown its creation or would have reacted to one of the "weekly" "why have we no real depth" threads in the past 2 years I would assume :)

How they are related: Well if you modify the regular Max2D DX driver, the next update will vanish it.


Actually I don't think that true depth will be faster. More likely to be vice versa sadly. There have been different attempts of batched drivers by BRL themself and different users here (including me) created their own ones as well. The result was always that current hardware is capable of opting the "single quad" approach to work near as performant as batching so the overhead for handling the batching in code makes them even or even slower.
the fact that the real depth and projection means automatic "real scaling" updates (not to mix with the virtual scaling value you would have in your code) which add further calculations. no problem if only done once but for particles and the like with size updates this will quite surely degrade the performance.
What I mean with that btw: you must scale it up while moving it in the background so it will remain on the same size.

Must have missed those both by visiting every day and intensive use of the search function.


True but then I don't uise svn or change base modules.

etc etc
Now that bit *is* interesting. Thanks for that.

OK, its not that often, thats why I wrote it within quotes. But any new user that has used similar technology (TGB, Flash and others) assumes that there is some kind of depth / layer systems and asks about depth.

There are 2 benefits of an own driver with true depth:
1. You can change the depth without changing the drawing order while it changes the visual order

2. You can use the batching to make static meshes for stuff that does not change -> Tilemaps for example. That should speed it up seriously depending on the way you store it and when you update it etc
But thats not that simple and doing it within a slightly modified version of the driver would be the right way to go ... at best on DX9 which is more capable on that end.