Perspective tech demo

Perspective tech demo is about making level from bricks of 3dBoxes. In this example there are shown 2 ways of achieving tiles looking like 3dBoxes:

with 3dBoxes (of course)

with skewed sprites imitating faces of cube

Readme file:

"Leo, why?"
This tech demo tries to solve problem of implementing 3d-looking terrain elements in game. By default, 3dBox would be good enough to take care of this, but there's also a way in using sprite skew.

What are those "sprite skew"?
In 3dBox there are 6 surfaces: front, back and 4 sides. This tech demo shows how to make effect looking similar to 3dBox: each "box" sprite (single tile) is provided with 4 "skew" sprites (skewRight, skewTop, skewLeft, skewBottom) that are scaling and skewing to imitate the 3dBox (back surface of 3dBox isn't imitated because it would be invisible all the time).

Profits of using "skew sprites" instead of 3dBox?
-> works faster
-> more control of depth (3dBox don't accept float numbers for depth)
-> can be animated (for example destroying terrain)

Todo for skewing tech demo (3dBox won't be updated):
-> Handling multiple objects (like complete tileset)
-> Correction of skew sprites Z-order
-> Handling background that's on the 2nd plane[/code:2el5yc06]

If you tried this demo please give some feedback. Thanks .

Screenshot:
[url]http://www.tymczasownik.republika.pl/perspectiveTechDemo1.png[/url]

EDIT:
"ENTER" - creating objects

Not a bad demo, and I agree it is faster. Looks pretty slick. There seems to be some zsorting issues for some of the sides here and there (bottoms showing up above sides) but I'm sure that can be tweaked.

But this:

-> more control of depth (3dBox don't accept float numbers for depth)

Is just plain wrong. I'm able to put any decimal number I want into the depth, either in the IDE or at runtime.

That's strange. I have problems with float numbers. When writing 0.6 or 0,6 or .6 or 0,6 it changes into "0,6" but then depth visible on Layout for this object goes "0". When I leave object and click on it again, there is depth set as "0".

Well, I'll try some more, maybe DirectX issue or Windows XP .

Update:

Oh I get it. Writing float from Layout editor is impossible on my machine, but passing float numbers in Events works fine. Thanks Deadeye ^^.

Update:

Oh I get it. Writing float from Layout editor is impossible on my machine, but passing float numbers in Events works fine. Thanks Deadeye ^^.

Well I guess that's good news and bad news, you should be able to enter decimal values in the layout editor as well. I wonder what's causing that to not work on your machine At least it works in events.

I've got the same problem. Can't type floats in the layout editor.

Me too. Seems like a pretty common problem. Maybe devs should investigate this?

Broo's post suggests an explanation.

Brief experimentation shows that this problem happens when the user's Windows locale defines a decimal separator other than the point (which is either usually or always a decimal comma).

The edit boxes for depth and z "helpfully" replace any decimal points entered by the user with the separator defined in the locale (<-observed to be true up to here; hypothesis follows). It seems (and would make sense) that the function which reads the values from these boxes does not expect to have to do the reverse transformation; so instead of the intended decimal fraction, it reads the integer part and discards the rest (a comma followed by some numbers) as gobbledygook.

"," separator ruins everything. After changing into "." in settings panel it works fine. Thanks ^^.

Yeah, the layout editor doesn't seem to like commas being decimal separators, which is annoying. I'll try to fix it for the next build.

3D boxes are not yet fully hardware accelerated (they aren't nearly as fast as they could be). So for now, your tests will show up as skewed sprites being faster. This should change in a future build when 3D boxes are optimised.

Although skewing is a good alternative, you'll have some really tricky problems getting the Z ordering to work right with depth!

Yes, but at the moment main advantage of skewed sprites is that they can be animated (useful for destruction of land), and 3dBoxes have fixed images.

There used to be a bug in 0.94.2 that allowed 3D Boxes to steal the texture of a sprite and appear "animated" if it is possible to implement that again but as an action or behaviour (Eg: "Get face texture from sprite") from the old 3D Box rendering code, then the 3D Box could also achieve animation.

We plan to have a 'set texture' and 'get texture' function in many of the objects. For example, you could use an animated sprite and then have

always

----- set front texture of cube to sprite.texture

Likewise you could use this with other objects...such as setting the texture of a sprite to the texture of the canvas...allowing you to use the canvas object to allow the user to customise their own car and spray paint it etc.

As for this example, its good but has some obvious disadvantages...such as the lack of a zbuffer and vanishing point perspective.

I like how you've used only 3 faces...we will try implimenting that into 3d box so less vertex are sent to the graphics card.