EDIT: The following is assuming I understand your meaning correctly. Ignore otherwise .

Emulating Z height is actually pretty easy. Only thing you need to know is the Z co-ordinate of the Camera, which is 100.

CameraZ is the Camera Z Co-ordinate EmulatedZ is the Z height you wish to fake Object.Value is the value you wish to offset by the emulated Z height

The basic formula is:

Object.Value * CameraZ / (CameraZ - EmulatedZ) or

Object.Value * 100 / (100 - EmulatedZ)

For anything that does not involve the X/Y axis (Size, acceleration, speed, etc):

Object.Value * 100 / (100 - EmulatedZ)

Where Object.Value is the original value before any Z emulation.

For Object.X its:

((Object.Value('X') - DisplayWidth*0.5) * 100 / (100 - EmulatedZ)) + DisplayWidth*0.5

Where Object.Value('X') is Object.X before any Z emulation.

For Object.Y its:

((Object.Value('Y') - DisplayHeight*0.5) * 100 / (100 - EmulatedZ)) + DisplayHeight*0.5

Where Object.Value('Y') is Object.Y before any Z emulation.

The DisplayWidth and Height parts are basically telling the Z emulation where the Camera's X and Y are focusing, so it can emulate accordingly. Remove them if you want to see what I mean, the Z will be focused at 0,0 rather than the center of your screen.

Funny how looking at other people's code can confuse the hell out of you.

You've given me some ideas, and how I would go about achieving what you have, but I'll be buggered if I can understand how yours works, lol.

Cool though.

Awesome update!

Yeah, it'd be nice to import objs and textures

Just wanted to say, I'm already doing this within the cap I've been working on.

If I get time I might be able to strip out the transformation side of the code and turn it into a plugin that will allow everyone to use low-poly objects if they so desire.

Thanks for giving me the idea .

Evented, for now at least. Still has a fair way to go until I'm happy with it.

Would be nice to turn it into a plugin though.

Oh ok. Well that is good to know.

It isn't really that it is the wrong tool for the job. I'm not expecting Crysis type performance, I was just using that for hyperbolic contrast . I'm mainly trying to establish what our limit is for a 3D engine in Construct.

As it stands, based on my testing so far, you can definitely pull off ps1 or n64 graphics with decent frame rates, which is cool.

I'll keep looking into it, anyway. Thank you for your responses, made me more at ease knowing that it is more the nature of Construct and less the ineptitude in my programming that keeping the frame rates at what they are.

Thanks again.

EDIT:

Aeal

I'm doing this because I enjoy the learning experience. Reading about and then coming to understand in depth the different concepts involved in 3D programming has been well worth the effort.

Thanks Ashley.

In response to your, well, responses:

1. I see. I had assumed that the sprite distortion must be doing some indirect overhead (well, a lot of indirect overhead). In my testing I could reach about 15,000 1x1 meshes with a 1x1 texture before getting subpar framerates. This is with an 8800 GTX, a decent computer, and a cap that does nothing after generating the meshes.

Apparently Crysis uses 20,000 tris for a single vehicle, with 1024x1024 textures.

I know I cannot do direct comparisons here, but there must be something I can do to increase the framerate. Are you implying that a 1x1 sprite mesh is more than 2 tris or a single quad (would explain a lot)?

Just to clarify, the method I'm using currently is creating 1x1 meshes as faux polygons (tri or quad). You would know better than I what kind of overhead that might create.

2. True. Thanks for your honest answer.

3. So essentially I should only really be getting bottle necked by what I display at runtime (barring exceptionally sloppy programming on my part, of course)?

Thanks again.

Edit: Extra clarification in 1.

I would usually refrain from calling out a particular group, but I don't think this question can really be aimed at anyone else. Unless some of the plugin programming regulars can answer for them.

Is it possible (meaning, I would be doing the work, just need to know if it is feasible), to make a plugin using the SDK that can:

1. Display UV textured polygons (tri, quad) directly instead of via the roundabout Sprite Distortion method?

2. Thus allow for the use of vertex shaders?

3. Access Direct X's inbuilt Rotation Matrix (and other 3D functionality) instead of having to utilize an event based solution?

Thanks.

A reboot of my old 3D proof of concept with all the new features available to Sprite displacement since then (Z axis, Z buffer, etc).

I'll upload an exe once I get a bit further and make things more efficient (Backface culling, etc).

Model borrowed from http://www.3dtake.com/2009/08/girl-3d-m ... tures.html.

Absolute ace plugin man. I have a lot of potential uses for this.

I would certainly use it.

I'm still trying to learn more C++ so I can have a crack at turning RakNet into one, but it'll be a while before I can have a serious go at it.

Sounds great. Can't wait to give it a whirl.