Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / 2D in a 3D world?

Author
Message
BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 10th Feb 2012 21:01
Hey guys, I've been working only in 2d for a while now, Is it possible to have 2D sprites in a 3D (with the advantage of a camera following) world and can it look exactly like it would in 2D i.e looking down at it in one axis? And if so, can someone post an example?

Best,
BeastDeath
Hodgey
15
Years of Service
User Offline
Joined: 10th Oct 2009
Location: Australia
Posted: 11th Feb 2012 02:41
You could use textured planes.

Baxslash wrote a game using a textured plane for the main character.

Millenium7
19
Years of Service
User Offline
Joined: 13th Dec 2004
Location:
Posted: 11th Feb 2012 05:02
sprite's already are textured planes if i'm not mistaken?
but to answer the question yes you can, you may use any form of 2d in a 3d world. Normal 2d commands will create sprites/text drawn to the camera

if you require 3d space you can use one of 2 techiques
You can find a 3d point which corresponds to 2d location on the screen. This is generally used to place name labels above characters for instance. It's still 2d text it just looks 3d because it repositions itself every time the camera moves

And the other is as mentioned, textured planes
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 11th Feb 2012 11:10
Sorry, this is off-topic (but not completely), but I had to... Check this out:

http://www.youtube.com/watch?v=i6KMAm_228s

Baxslash's game looks pretty cool too
I've been playing around with this concept (the textured 3D plane for a while now as I intend to use it on a project of mine in the distant future (I have no artists but that's fine, I can't start it until I'm settled in the UK - emigration still in progress, paperwork AS LONG. This is fine, I have a cousin who draws in England).

But to clarify something:

Quote: "sprite's already are textured planes if i'm not mistaken?"

Yes, but they are not handled exactly the same when it comes to filtering - at least that's what I've observed. With this:

You'll get much better filtering than using a sprite. Even if you set the texture flag when loading the image to use filtering, it'll just make the sprite look blurry. If you want really good filtering that doesn't loose sharpness, use a plain over a sprite.

Also remember that a plain requires no extra maths to interact with a 3D world, whereas a sprite does (Unless you've a fixed interaction depth).

BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 12th Feb 2012 14:35
Ok so here's my basic code so far, how can I make a transparent png sprite look the same on the texturered plane? And how would I find the exact height for the exact width/height of the image?

nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 12th Feb 2012 21:14
Quote: "Ok so here's my basic code so far, how can I make a transparent png sprite look the same on the texturered plane? And how would I find the exact height for the exact width/height of the image?"


Well, since you're working in 3D, it would be totally Z-depth dependent. So essentially it's kind of a difficult question to answer. You'll also be sizing your plain according to the ratio of your world. There's the tricky part...
...Except it's not. It doesn't matter because as long as the correct scaling is maintained, a little resizing won't affect the image much. You can no longer think in 2D terms.


Now when it comes to textured objects being used for sprites, the best you can do is decide on a ratio and go with it. There's a formula for calculating the projected size of something using trigonometry or something but it eludes me right now. As I said though, it technically doesn't matter what size you make your models so long as you stick to that ratio. You could even use the image dimensions (Returned by IMAGE HEIGHT() and IMAGE WIDTH()). It depends a lot on the image texture size. If you are using images intended as sprites then it's fair to assume you don't have massive images weighing in at over 128x128, in fact I'd bet they're around 64x64 or 32x64. Therefore it's safe to just use the exact pixel-size for the unit-size of your models without fear of using too much resources. Something like this:



Now, the only factor left becomes your camera's z-depth. You can match it up to the image size using complex formulas if you want to but it would be a waste of time. Rather just get an approximate fixed-distance between the camera and the player that keeps the player more or less the size you want and that's it.

...I hope I'm explaining this all correctly... Basically, 3D = relative to the world, 2D = relative to the screen. In 3D, you can build the player to fit the world or the world to fit the player. In 2D, you have to think of the screen. In 3D, the only thing that matters is the monitor's aspect ratio. In 2D the resolution matters. Using the same example to illustrate:


Well that's all I can offer. I'm sure someone would know of an absolute formula, if not here, at least somewhere on the web. Maybe wiki it?

BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 12th Feb 2012 21:40
I see, at the moment I will just eyeball the height of the camera to relation of the size of the image plane for now, while keeping a fixed window size. I've been able to make the imageplane look almost the same as the sprite, I noticed it has been flipped, which isn't much of a problem atm.

I now face a new problem, what would be the best way to make the collisions in my game? Its a 3d world looking straight down, x,z are my x,y - in 2D. All my planes are flipped 90 on the x axis. I'm using individual planes for the player and enemies.

I'm also using one plane for the entire map a flat image, which needs to have collisions in several places, how would I do this?
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 13th Feb 2012 06:57
first of all I'd suggest you don't flip your world down but keep xyz as xyz, ie don't flip your plains. This is for no other reason than familiarity. It can get confusing by "looking down" on the action.

About the collisions, with object to object, its easy. So long as they're on the same depth level, they should detect as the default collision bounding box exceeds their depth (plains are not absolutely 0 in depth and therefore not truly 2D). If they aren't precisely on the same depth, use SPHERICAL COLLISION or "collision spheres" as this will give you near-perfect collission. Another option is to use invisible primitives to create you own, more custom collision boxes but I think the best option would prolly be spherical collision.

So the background needs to collide in parts? Easiest would be to use invisibe primitives. Wherever collision is required.

BeastDeath
13
Years of Service
User Offline
Joined: 7th Jul 2011
Location:
Posted: 13th Feb 2012 17:06 Edited at: 13th Feb 2012 19:42
Thanks for the help

I've not used anymore than darkbasicpro object collision command for 3d collision, how would I make the invisible primitives on the map plane where needed what commands? I'm guessing I will have to custom plot the points of the invisible collision box on the plane.
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 13th Feb 2012 19:45 Edited at: 13th Feb 2012 19:47
To get the coordinates, there are two methods I've used:

Method 1: Mathematical, Complicated, Fast


Method 2: The Faaar less complex method (but takes longer)


So what about making the box invisible? Simply set its alpha to 0 with "SET ALPHA MAPPING ON invisible_block(n), 0", but I suggest that be left till last as bieng able to see these block is useful for debugging.

Login to post a reply

Server time is: 2024-11-23 22:46:05
Your offset time is: 2024-11-23 22:46:05