# Unity 2d images given precise 3d behavior?

This topic is 4120 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

##### Share on other sites
sounds like too much trouble than its worth...

##### Share on other sites
sounds like you're trying for "Voxels"(look that up)

but if the camera is limited to fixed ortho positions... you can probably save a lot of work
maybe have a separate Voxel representation for collision detection from the actual sprite graphics?

Also, Voxel (or as you call it pixel-prices collisions in 3d) is kinda... overkill
you sure you can't just get away with having bounding box collisions, just make the boxes smaller than the tiles for added detail?

##### Share on other sites
Hi guys!

Ultimape--

Does that mean you think the method will can work, only that it would take a lot of work to complete? And do you mean it would take the programmers a lot of work, or the artists, or both? Because if it's just the artist, I'm more than willing to do all that work LOL!

Anon--

Yes the camera in my game would be in a fixed ortho position and I was considering making a voxel mask to represent the collisions of each 2d image but someone told me, like you, that they're "overkill," anyway. So do you think this RGB method is "just as overkill" as using voxels anyway? Because if I could use voxels to make the masks I would be happier!

I read somewhere that voxels are better than polygons for a few reasons, but that polygons are majorly supported by 3d graphics cards and whatnot, while voxels aren't, which is why voxels tax the computers.

Anon, I was also thinking of using bounding box collisions, smaller than tiles, and cylindrical/spherical bounding "boxes" (though I heard they are harder to code), but then this would mean to toss out any irregular shapes...If it's a last resort I could consider it--but I want to learn my options.

My goal here is to figure out primarily, if my theory is valid. 1. Can a game be made like this? And if so, 2. Would it require too much computer power? And 3. Would the programmers have to do too much extra work? Or just the artist?

Also, I've thought about using voxel models themselves as the artwork, and I think that idea is also out (it would be too complicated to explain why unless someone wanted to know, but it has to do with aesthetics).

[Edited by - Sylon on November 6, 2006 7:06:31 PM]

##### Share on other sites
I think you need to ask yourself if its really necessary to have these features, because in the way you want them, it's near impossible to build.

A: pixel perfect collision detection.
In itself this is possible.
However, as soon as you add an isometric world, especially with the impression of height, pixel perfect collision detection becomes very, very difficult.

Example: Imagine two characters, one on top of a hill, the other at the bottom. For the moment I'm going to dismiss the problem how you would translate these characters as that is a whole problem itself, but they each start walking to each other. At one point there is a collision as they meet (head collides with feet). Obviously there is no collision, but in a 2d game you can't calculate that, unless you change the pixelperfect collision to only one or two points of collision (In this example they both would be at their feet), its never going to work.

Example two A: Imagine a tree. Character A is standing a bit above it, and is going to walk towards it. At some point the top of the tree is colliding with the character. In reality there actually is no collision. Again collision should only be detected at the base of the tree and at the characters feet.

Example two B: Imagine that same tree now with a branch hanging over a road. Character A is small enough to walk under the branch, but Character B isn't. Again at some point both characters collide with the branch. Your point of collision now has to be based near the head area. (Explaining that you can't rely on one point either.)

Shadows in 2d games works fairly well up to a point. There are several ways, but I found that adding the shadows to the images themselves gives you the best result.
Here's an example image I used in a different question earlier on another forum (best seen in FF as IE kills the transparency effect)

If other characters walk over the shadow or if this character walks near other objects, they'll automatically receive that shadow too.
Of course this methode doesn't mimic real shadows as they don't really react to the environment, but in most cases it probably comes as close to it as you want it to be.
Mind you that its a very time consuming process. Creating an entire animation for this character (not talking about actually creating the animation in Lightwave, but rendering it and processing the renders in PhotoShop, took about an hour per animation cycle)

Anyway, I hope this helps a bit.

##### Share on other sites
Hi Traveler! Thanks for joining in.

About the pixel-precise collisions. Yes, I've thought about this through and through for an isometric 2d game. Once again I don't know code or coding languages but I have a vague idea of game mechanics. I assumed the kind of trouble you're pointing out here was already tackled but I'm just a little too hasty. I realized how tough it must be to code.

There is a game called "Head over Heels", a remake of a classic, made by a team called retrospec http://retrospec.sgn.net and if you download that game you'll see that the single programmer was able to calculate 2d isometric collisions in 3d space. The characters can jump all around each other and objects. If there was a tree (there isn't though), the character would collide with the trunk of the tree, not as his sprite touched the tree sprite (leaves or branches or whatever). The thing with HOH is that the objects all have cubic bounding boxes--the boxes were pixel-precise but...how I'd say, I guess...the boxes weren't true to the form of the 2d image. So yes as you've said, it's possible, and you're right I bet it's difficult but I've seen pixel-precise collisions work with cubic bounding boxes so I'm spoiled. I'm wondering if there's a way to take it to the next level--pixel-precise bounding "boxes" that conform to the 2d image how we'd like it to, instead of just cubic or simple cylindrical bounding boxes.

About the translations of the sprite, wouldn't it just be a sprite offset function? I know in HOH height was apparent. The problem was that nothing was sloped, just all cubic blocks the characters would stand on/jump on. I'm gunning for slopes in my objects.

About the shadows. In HOH as well, there were precise shadows coded. The problem was that they bent only around the cubic collision boxes of objects, but they fell and rose in height accordingly in 3d space. The shadows were transparent images that followed the character and were offset in position when they hovered over an object with a different height.

So I was thinking that say, if a single pixel of a shadow image collides with a pixel with RGB values assigned to it, that pixel of the shadow would be offset, just like in HOH. So blue values signify height. If a shade pixel was on a pixel with a blue value of 15, then the object moved over a pixel with a blue value of 120, the shade pixel under that object would be "told" to offset by however many pixels upwards. This way it would "jump" from a low height to a higher height instantly.

Besides the fact that this all is difficult to code, is any of it impossible to code (because I don't know)?

##### Share on other sites
Let's look further about collisions in the RGB model.

Remember I arbitrarily chose increments of 15 for the RGB value differences between each pixel.

In the bottom left, there is an arrow symbolizing a sprite moving towards the cube. As soon as the sprite's own bounding box collides with the pixels that have a blue value of 30, it should stop moving. In other words he is traveling on pixels with blue value=15. So anytime he comes into contact with a pixel of a greater blue value than the one he is currently on, he *should* stop.

Another example. On the top of the cube the blue values are 120. Let's say the sprite follows the arrow direction towards the cliff edge (along the x [red] dimension). All of its green values will be the same as it follows the arrow, but as it moves, its red values will change. At the cliff edge, the red value is 180. As the sprite continues moving past that, the NEXT red value in sequence is 195, which is down below. Those pixels with red values of 195 have a blue value of 15. The sprite moving along that x dimension would collide with pixels that have a change in their blue value (from 120 to 105), and since the next pixel in red's sequence (195) is down below with a blue value of 15, that is where the sprite should fall. Calculating gravity would be another issue I suppose.

Seriously to me this sounds like it means much less work for coders and more for artists, as long as it works. I hope.

I've been looking for someone to verify to me that this is a valid theory but, I guess, maybe I should look for someone who'd like to test it? Maybe all it needs is some testing?

[Edited by - Sylon on November 7, 2006 11:53:54 AM]

##### Share on other sites
To be honest I dont think computations on such a scale are really feasible. Usually a (multi)dimentional array is used to calculate where your character may or may not go. This array represents the playarea.

In the picture I've an array where some parts (tiles) are filled already. Each position can hold a number of values. In this case, I have an ID to a texture as well as collision information. (The red area marks collision information.)
I've used rather large tiles here, but it is possible to decrease the size of course, to match smaller objects better.

The cool thing about this is that you can very easily change this information. You can build an editor around it and have a leveldesigner do his thing. I'm not really sure how you would edit maps using your method.

##### Share on other sites
Honestly it doesn't look impossible, just fairly difficult (especially for someone who doesn't know any programming languages).

The colored blocks you're posting images of are voxels. If you want to do slopes (not just different heights) then it's either voxels or 3D texture mapping. If you're ruling out voxels, then you'll probably just do linear texture mapping. At that point, it'd probably be easier to just switch to 3D and maybe constrain the camera angle.

Collisions will be a programmatic pain in the ass. First of all, I'd be very careful in your map design. The example given about the tree can be avoided if you make sure there are no hills as tall as trees directly beside trees. Your example about the crevice is very difficult. 3D programmers have long sought after an easy way to do overhangs with collision detection, and you're wanting to do it isometrically. I would personally make the crevice tile a special case tile that actually has three tiles: one for the top of the tile, one for the roof of the crevice, and one for the floor of the crevice.

This post has gotten me thinking about a very special (and very computationally expensive) kind of isometric engine; a voxel isometric engine. Basically it would be layer upon layer of tile. You could effectively dig down through the ground that way, unearthing new tile layers. Might be sweet!

Anyway, what I'd like to know is: is someone going to code this for you? Because that person should be intricately involved in the design of the game. Artists sometimes don't realize the complexities of programming things like this

##### Share on other sites
Traveler--

Yeah I've played iso games with that kind of design. Well, I guess, if I was to edit maps with "my method", it would simply be that there would be a bottom layer in each room, of just flat tiles. Above them would be cubic dirt or rock objects which you stack on top of each other to make hills and mountains, and at the top of those stacks are objects shaped like lumps (for hills), or stones, grassy tiles, etc.. And within each stackable object will be these invisible RGB masks that tell the computer what their xyz dimensions are.

The computer will draw the objects from back to front, and apply the offsets.

That's my idea anyway, I guess!

Funky--

You mean the individual pixels in the multicolored dioramas are exactly how voxels are made? Voxels use RGB representations for space?

I guess the bottom line would be that, with the crevice example and all, it would be as if every single pixel in the game was its own "tile", that gets drawn from back to front within the larger tile that it's in (say a 32x32 tile). The 32x32 tile would be the one that the level designers place in the game. I can't seem to get around thinking the RGB values should be enough to tell the sprites what is happening and where they should jump to (offset in height) or stop. Maybe I just need to learn to code.

What would be the most efficient way of learning what I need to for me to study this theory? Should I learn an ENTIRE programming language or just parts of it?

Funky I was planning on doing all the art first for a few decades and then finding some programmers to help me.

##### Share on other sites
Quote:
 Original post by SylonYou mean the individual pixels in the multicolored dioramas are exactly how voxels are made? Voxels use RGB representations for space?

No.
Voxels are a Concept, there are as many different ways of Implementing them as there are different programmers.

##### Share on other sites
Quote:
 Original post by Anonymous PosterNo.Voxels are a Concept, there are as many different ways of Implementing them as there are different programmers.

Oh okay cool!

##### Share on other sites
Sylon,

I responded to your PM. These are my thoughts (assuming I have your goal correct):

First, and foremost, any solution we can come up with will most likely be too slow to be of any good. While 3D pixel-perfect collision is very nice to have, it's just that... a nice-to-have.

However, for the sake of learning and problem-solving, let's assume that processor speed and memory is not an issue.

What you want is for every object you have, associate a 3-dimensional array of bits which will represent what the object looks like in a 3D world. A 3D mask if you will. Every frame the object can be in that changes the space it occupies means also that you will need to have a new array for that. Some will have more than others. A rock will most likely have 1 while a living will have many arrays.

Now since all you are concerned with is collision of 2 objects that are within the same space, checking for collision is very easy. You take the 3D array of the one object and then overlap the other object, of course offsetting it correctly. If any 3D points (also known as voxels) intersect, then you have collision. It's very simple to theorize since this is how the real world works.

Implementing such a scheme efficiently is a different story. A simple 32 x 32 x 32 object will require a total of 32 thousand bits (or 4k of memory) to have it truly represented as a 3D mask. That is not realistic.

So let's try an cut that number down to something more manageable. The most efficient we could get is if we decided to only map the outer surface of our object which would (in the 32x32x32 object) still take up 512 bytes (1024 bits per side, 4 sides, 8 bits per byte). This is a simple cube. A more complex object would require more data to map the surface.

This is why people have opted to use boundary cubes for collision detection or going true 3D because given our current level of technology, having hundreds of objects using that much memory (for a single frame mind you) is just not realistic. Let say your standard character is 64 pixels tall, 24 pixels wide, and 24 pixels deep. A 3D mask of a single frame of this character would require 65,536bits (or 8k bytes). If that character has 15 frames for 1 single position or motion, then that would require 120k bytes. If that character has 20 different positions and then that 1 character would require 2.4M bytes to represent it fully in 3D space. That is actually not that much memory, but that is for 1 semi-complex character.

Now, you can do some things to take advantage of the defined 3D mask. All instances of that character can (and should) use the same 3D masks so it's only 2.4M for an infinite number of character instances. Also, while some monsters may look different, they could all share a common 3D mask.

However, even if you optimize is as much as you think is possible, you will still end up using a lot more memory than you would hope for. While PCs are coming with 1GB and 2GB of memory today, most people playing your game will have around 512kB of memory (+/- 215kB). Also, I only pointed out the memory limitations of trying to do pixel perfect 3D collision. There is then the actual collision algorithm that must be written. It could be written in such a way that it only does collision checks on the voxels that could possibly have intersected, but is still a whole lot of looping, ANDing, and memory jumping. Of the two limiting factors, though, this would be the lesser of the two evils.

I would look into have a close representation 3D model of your 2D object that you can use to do all of your collision detections on. This close representation model can be rendered on a hidden surface with 0 frills and used for collision detection only. You can use the detailed 2D sprite for display, but use the 3D model for most of the grunt work.

##### Share on other sites
What a thoroughly awesome reply by Dino! I've NEVER.

For me it was like, more educational than that stuff I read from my Commodore 64 manual, and my DarkBasic manual(s). LOL! Pssh DarkBasic...

Quote:
 Original post by DinoI would look into have a close representation 3D model of your 2D object that you can use to do all of your collision detections on. This close representation model can be rendered on a hidden surface with 0 frills and used for collision detection only. You can use the detailed 2D sprite for display, but use the 3D model for most of the grunt work.

So this can be for any object, a tree, a rock, a monster, whatever? Because actually for the characters and monsters I was thinking that 3d rectangular bounding boxes would be fine in my game--but it will be a hack'n'slash, another nightmare to code I suppose, with all the weapon swinging/shooting. Would having polygonal collision boundaries save a mass more CPU power than voxel collisions, or just a small amount more?

The other thing is, the reason I really wanted pixel-perfect collisions is because I want objects to "roll" over rounded surfaces, instead of just cubic blocky heights or triangular ramp heights...I want organic hills. If there is a non-voxel collision method to get that, then awesome. Polygonal collision boundaries look like a good way to go. Someone at GarageGames told me that he's making an Isometric engine which will allow some kind of sub-cell collision checking within tiles I think...and they might be given height values too! I COULD probably ask him more about that.

Okay, now back to shadows baby!

So I was talking to guys at devmaster. One of them told me this:

-----"i think its possible, if you have absolute world coordinates for each pixel, which you could get from the base position of the sprite, then using the heightmap/coordinate map to create the exact world position of the pixel, you could use it to detect if its in shadow or not.

you could use geometry shadow volumes to do it.

you make the volume out of the outlines of the sprites (as long as you find its supposed exact 3d position) and extrude away from the light and then its
just a containment test per pixel to find out if its in shadow or not. (including ground tiles)"-----

I don't get the extrude part. BUT! I illustrated what I understand he meant by the world coordinates. So basically (correct me if I'm wrong) the world has absolute x and y values for each pixel right? Then, for objects' base pixels, x and y values are coded (absolute within the object, but relative to the world pixels?) and for any pixels in an object that supposedly have height, instead of coding their x and y values normally, we'd code say all pixels "above" x1y1, to be x1y1 as well! Then when a transparent shadow sprite crosses a world pixel, and an object's x1y1 pixel is sitting on that world pixel, THOSE pixels in the object which were coded as x1y1 will become shaded! Because the shadow will offset to those pixels! If that's confusing I drew my understanding here:

The first pink arrow shows an object pixel offsetting the cast shadow pixel.

The pink bracket in the 3rd diagram shows a row of pixels on that cubic object, which are all coded with the same x/y coordinates as the pixel at th base of the object, so they all get shaded by the cast shadow because it's as if it "moved" to all of them.

The last diagram has an unrealistic effect but for code purposes it has to be that way (if my understanding is right).

What we can get is that ramp-shading effect, where rounded and ramp objects can BEND cast shadows, as long as someone codes the heightmaps right?

So, how does this look for making pixel-precise cast shadows? I don't want a lighting system, just shadow sprites that follow objects and get cast over other objects, that's what I want. Does this take the same processing power as voxel collisions??

And, if I choose the polygonal collision checking method, would this kind of thing still be available?

Dino you rule!

##### Share on other sites
The method you describe isn't the one suggested to you, but the suggested one was far more complex then you need. If all you need are simple vertically projected shadows your method would work well and feasibly fast. In response to your collisions, if you used a simple heightmap for the terrain and then only used polygonal collision meshes for special objects like characters and trees it might be feasible in terms of memory and performance. I definitely recommend a hybrid approach, with simple collisions/shadows for places where the complex systems aren't needed such as terrain and then a more complex system for 'special' situations. Hope this helps.

##### Share on other sites
I LOVE THE UNIVERSE! Holy excellence!

Twincam--

Hi! Perth huh? S'where the coder that suggested the world coordinate thing was from! Are you HIM? LOL.

So "simple heightmaps for terrain" would mean I could make rounded, near-domelike hill tiles? And further can I make them any shape I want or by "simple" do I have to make them inorganic (not lumpy)? Like, if I made a tile with 80% flat heightmap and in one corner of it I made a rock with a small raised height, would the mobile objects collide with it, using their simple polygon mesh? This and the rounded hills terrain is the whole reason I thought voxels were necessary. Would the SAME heightmap that offsets the shadow pixels be the one that dictates collisions (would make it easier)?

And as long as my character sprites "roll" organically over the hills as they run, or bump into these random small objects within tiles, I wouldn't mind if their bounding box was a blocky rectangle or a cylinder.

-------------------------------------------

I think...I'm running out of questions. Somebody slap me. Miracle!

My fantasy is unfolding before my eyes! I don't believe it. Finally! After asking 23,000 questions I'm finally here!

But I apologize to all the programmers who I confused with my uneducated theoretical questions.

SO! My shadows will work, and fast too. What a relief. I will go NUTS defining heightmaps for my artwork! Sweet.

You guys rock, all of you. If I had some, I would give you money just for telling me this.

[Edited by - Sylon on November 10, 2006 8:52:04 AM]

##### Share on other sites
Quote:
 Original post by SylonYou guys rock, all of you. If I had some, I would give you money just for telling me this.

That's way GD.Net has implemented the rating system :)

##### Share on other sites
Yes! I award all of you exactly 1,233 rating points!

##### Share on other sites
Quote:

The reason several coders would recommend going all 3D is because they don't deem the added 2D sprite detail worth the extra work it would entail to do a 2D/3D hybrid. However, you think it is worth it and that is all that matters.

Quote:
 Original post by SylonSo this can be for any object, a tree, a rock, a monster, whatever? Because actually for the characters and monsters I was thinking that 3d rectangular bounding boxes would be fine in my game--but it will be a hack'n'slash, another nightmare to code I suppose, with all the weapon swinging/shooting. Would having polygonal collision boundaries save a mass more CPU power than voxel collisions, or just a small amount more?

I think that most 3D collision boundary implementation will do this kind of work much more efficiently than any voxel implementation. Just look at the simple numbers:
A single 3D boundary cube will require eight 3D points to represent it. Lets say one 3D point consists of 3 single-precision floats for a total of 12 bytes (32bits * 3). That means for any cube of any size, you will need 96 bytes to properly do collision checking on a cube. To determine if 1 cube is colliding with another cube (assuming you just don't use the optimized 3D libraries) would a simple check. I forget the actual formula, but it's not very CPU intensive.

Now a voxel based implementation of a small object (let's say 8 x 8 x 8) would require you to have a minimum of 64 bytes (8bits cubed). At first that doesn't sound bad at all, but this is for a small object. Increase that to 32 x 32 x 32 and now we are looking at kilobytes of memory needed to do the collision checking. Then add on algorithm needed to actually do a bit by bit check and you are talking alot of work.

So, right now, boundary collision is your best and fastest choice and is much more efficent.

Quote:
 Original post by SylonThe other thing is, the reason I really wanted pixel-perfect collisions is because I want objects to "roll" over rounded surfaces, instead of just cubic blocky heights or triangular ramp heights...I want organic hills. If there is a non-voxel collision method to get that, then awesome. Polygonal collision boundaries look like a good way to go. Someone at GarageGames told me that he's making an Isometric engine which will allow some kind of sub-cell collision checking within tiles I think...and they might be given height values too! I COULD probably ask him more about that.

As long as you don't want object to be able to go under a tile, then height maps are the way to go here. It's fast and efficient and gives you pixel-perfect heights at any 1 point. By storing the information in a simple 2d array with a char offset, you can have very large rolling hills. A 3D terrain engine could also give you the same effect, but I'm not completely sure on the pixel perfect height evaluation.

The purpose of the char offset allows you to break the 256 pixel maximum height that a single 2D char array (which is what you want to use to minimize memory use) and also allow you to reuse the same tile at different heights. For every unit the offset is increase, the tile is raised 256 pixels. This allows you a maximum of 64k pixels high, but only use 1 extra byte more than the 2D char array.

Quote:

If you use a simple 2D height map, then it should work ok. There are quirks you will need to keep an eye out for, though. It's hard to explain, but oddly shaped objects will cause you the most problem and I would, in your implementation, test with objects that are concave and have the left-most points in the back (furthest from the viewer).

##### Share on other sites
Hey!

Quote:
 Original post by DinoHowever, you think it is worth it and that is all that matters.

That's what I was thinking too! Hehehe.

Quote:
 Original posy by DinoSo, right now, boundary collision is your best and fastest choice and is much more efficent.

Nice.

Quote:
 Original post by DinoAs long as you don't want object to be able to go under a tile, then height maps are the way to go here.

DANG!

Maybe I'm confusing tiles with objects? I was thinking of making stackable objects, with different floor levels and stuff.

SW of the dog character you see some blocks, with one shaded by the one above it. I was think I could make a game with elevated levels like this, and yes characters going under objects. In this case are objects different from tiles? I want my world to be basically BUILT by stacking cubic objects, and then any organic objects with rolling or lumps, would be stacked on top of the cubic objects to basically give form to hills and stuff. The "tiles" would be such as the metal floor you see in the screenshot of HOH--just at the bottom of the stacked objects. Really the objects would be what gets walked on 99% of the time.

Can I give the organic heightmaps to the objects and stack them, and make it so some of them can be traveled under?

I figured the whole 3d polygon collision mesh would allow for jumping in 3d space, such as for jumping into elevated cave hole in mountainsides, or into windows, under/between multi-level bridges, etc.

LARGE hills I was thinking could be sacrificed--to build large hills I would instead just stack cubic objects in a large 3d formation and at their tops, place an object with a ramped or lumped heightmap (there would be enough of these "top" objects that you could make it look seamless when you set them near each other). Doable?

Here is a pic to explain, don't mind the mismeasurements of tiles or the bad art!:

I would like 90 degree rotations of maps (I will make 4 sides to everything) and jumping around elevations.

Quote:
 Original post by DinoIf you use a simple 2D height map, then it should work ok. There are quirks you will need to keep an eye out for, though. It's hard to explain, but oddly shaped objects will cause you the most problem and I would, in your implementation, test with objects that are concave and have the left-most points in the back (furthest from the viewer).

As long as they're just quirks I'm sure I can find a way around them, or be able to sacrifice them. Thanks!

##### Share on other sites
I always considered tiles a 2d image used solely for terrain rendering. However, give what you want to accomplish, I would be more inclined to say that your terrain is built using a voxel-like system. In your picture there, every cubic area can be represented as 1 type of terrain building block, kind of like a voxel. But where a voxel is a cube, your building blocks are cubic in containment only, but have an organic surface inside your cube.

Given this, I would revisit the whole voxel approach for your terrain. Try going at it like this:

struct BLOCK{	unsigned int offset;	//Height offset from ground 0	char *topography;	//The height map of this block	void *data;		//Any block specific data};struct BLOCKLIST{	unsigned int count;	BLOCK *blocks;}struct TERRAIN{	unsigned int width;		//Number of tiles in the X direction	unsigned int height;		//Number of tiles in the y direction	BLOCKLIST *tiles;		//The actual layout of your terrain}

You would then initialize the TERRAIN like this:
TERRAIN t;unsigned int mem_size;t.width = 32;t.height = 32;//Allocate the minimum memory needed for this terrain and initialize//all the values to 0mem_size = t.width * t.height * sizeof(BLOCKLIST);t.tiles = (BLOCKLIST *)malloc(mem_size);memset(t.tiles, 0, mem_size);

You would then build each individual BLOCKLIST entry with your terrain building blocks. Given this structure, I don't think you need to get 3D libraries involved because collision detection is built in due to the terrain being made up of those building blocks. You will need to implement a simply gravity system to pull the objects down so that they do follow the terrain, but that's easy.

##### Share on other sites
The exact pixel perfect collision system kind of eludes me at the moment, but as for creating a map such as the one you have drawn there (really not bad at all btw), I believe it should be possible to realize that with a simple isometric engine.

Are the characters in there fair representations in regards to their size? Because if so, I really wonder if a pixelperfect collision detection system will have any benefit over any other system.

##### Share on other sites
Interesting approach to getting organic 2d worlds. Personally I'd go with a world like Dino described, made up of fixed-size cubes with 'fuzzy' tops represented with a heightmap. Then you could hold your world as a big 2d array, where each slot represents a vertical slice of cubes. Each slice would then be a linked list of cubes within it. That takes advantage of the mostly sparse nature vertically while still giving you nice fast array lookups for any given area.

For rendering, if you had a second sprite with the depth information (like in your first post), then shadows could be done quite easily in a pixel shader. You'd only get top-down drop shadows, but it'd look like the animations you've created.

##### Share on other sites
Gamedev is full of geniuses!

Dino, that's awesome. What happens if I use that actual code in my game and decide to make the game commercial? Would I have to contact you? Chances are I will make my game free (I will work on it as a hobby for years, so I'll probably have a job for myself and I HOPE be able to pay a team to help me, but as far as making the game commercial, not sure). I don't think anyone has ever went through the effort to make that much code for me. LOL. Thanks man!

I think I see what you mean by the concave shading quirk now:

I have theories but I'll spill it elsewhere. I will test those leftmost pixel and concave cases when I work on implementation though, thanks for pointing it out!

Traveler--

Yeah, that's about their *relative* sizes to the tiles and blocks...for real I'd like them to be maybe 24x48 or, with blocks being like 32x32. Yeah as long as they roll over hills as they run, and can jump between stuff and possible over and around a mass of lumpy tree roots, I guess I don't mind the non-pixelperfect collisions. Polygons for tree roots might do it and stuff. But I'd think if the hills could be rolling, that I could do the same kind of heightmap stuff for the hills, with trees and branches and rocks and stuff too, right?

Orangytang--

Awesome! You get some rating points too! I'm keeping notes on all this stuff. I will save this topic discussion in like My Documents, it was the best I've ever had.

[Edited by - Sylon on November 10, 2006 5:19:41 PM]

##### Share on other sites
Quote:
 Original post by SylonI think I see what you mean by the concave shading quirk now:

Ah, the age-old 'double shadow' problem that crops up in every shadowing method. [grin] You'll get variations on this with self shadowing of cubes too.

So far I can think of two possible solutions: 1. store another mask layer indicating which bits contain baked-in shadows, and so don't need to be further darkened. Or 2. tinker with the depth sprite so those pixels are at maximum height - that way they'll always be fully lit, and you won't get the shadow applied a second time over the hand-painted version.

• 27
• 11
• 17
• 11
• 13
• ### Similar Content

• Hello fellow devs!
Once again I started working on an 2D adventure game and right now I'm doing the character-movement/animation. I'm not a big math guy and I was happy about my solution, but soon I realized that it's flawed.
My player has 5 walking-animations, mirrored for the left side: up, upright, right, downright, down. With the atan2 function I get the angle between player and destination. To get an index from 0 to 4, I divide PI by 5 and see how many times it goes into the player-destination angle.

In Pseudo-Code:
angle = atan2(destination.x - player.x, destination.y - player.y) //swapped y and x to get mirrored angle around the y axis
index = (int) (angle / (PI / 5));
PlayAnimation(index); //0 = up, 1 = up_right, 2 = right, 3 = down_right, 4 = down

Besides the fact that when angle is equal to PI it produces an index of 5, this works like a charm. Or at least I thought so at first. When I tested it, I realized that the up and down animation is playing more often than the others, which is pretty logical, since they have double the angle.

What I'm trying to achieve is something like this, but with equal angles, so that up and down has the same range as all other directions.

I can't get my head around it. Any suggestions? Is the whole approach doomed?

Thank you in advance for any input!

• By devbyskc
Hi Everyone,
Like most here, I'm a newbie but have been dabbling with game development for a few years. I am currently working full-time overseas and learning the craft in my spare time. It's been a long but highly rewarding adventure. Much of my time has been spent working through tutorials. In all of them, as well as my own attempts at development, I used the audio files supplied by the tutorial author, or obtained from one of the numerous sites online. I am working solo, and will be for a while, so I don't want to get too wrapped up with any one skill set. Regarding audio, the files I've found and used are good for what I was doing at the time. However I would now like to try my hand at customizing the audio more. My game engine of choice is Unity and it has an audio mixer built in that I have experimented with following their tutorials. I have obtained a great book called Game Audio Development with Unity 5.x that I am working through. Half way through the book it introduces using FMOD to supplement the Unity Audio Mixer. Later in the book, the author introduces Reaper (a very popular DAW) as an external program to compose and mix music to be integrated with Unity. I did some research on DAWs and quickly became overwhelmed. Much of what I found was geared toward professional sound engineers and sound designers. I am in no way trying or even thinking about getting to that level. All I want to be able to do is take a music file, and tweak it some to get the sound I want for my game. I've played with Audacity as well, but it didn't seem to fit the bill. So that is why I am looking at a better quality DAW. Since being solo, I am also under a budget contraint. So of all the DAW software out there, I am considering Reaper or Presonus Studio One due to their pricing. My question is, is investing the time to learn about using a DAW to tweak a sound file worth it? Are there any solo developers currently using a DAW as part of their overall workflow? If so, which one? I've also come across Fabric which is a Unity plug-in that enhances the built-in audio mixer. Would that be a better alternative?
I know this is long, and maybe I haven't communicated well in trying to be brief. But any advice from the gurus/vets would be greatly appreciated. I've leaned so much and had a lot of fun in the process. BTW, I am also a senior citizen (I cut my programming teeth back using punch cards and Structured Basic when it first came out). If anyone needs more clarification of what I am trying to accomplish please let me know.  Thanks in advance for any assistance/advice.

• Hi , I was considering this start up http://adshir.com/, for investment and i would like a little bit of feedback on what the developers community think about the technology.
So far what they have is a demo that runs in real time on a Tablet at over 60FPS, it runs locally on the  integrated GPU of the i7 . They have a 20 000 triangles  dinosaur that looks impressive,  better than anything i saw on a mobile device, with reflections and shadows looking very close to what they would look in the real world. They achieved this thanks to a  new algorithm of a rendering technique called Path tracing/Ray tracing, that  is very demanding and so far it is done mostly for static images.
From what i checked around there is no real option for real time ray tracing (60 FPS on consumer devices). There was imagination technologies that were supposed to release a chip that supports real time ray tracing, but i did not found they had a product in the market or even if the technology is finished as their last demo  i found was with a PC.  The other one is OTOY with their brigade engine that is still not released and if i understand well is more a cloud solution than in hardware solution .
Would there  be a sizable  interest in the developers community in having such a product as a plug-in for existing game engines?  How important  is Ray tracing to the  future of high end real time graphics?

• Good day,

I just wanted to share our casual game that is available for android.

Description: Fight your way from the ravenous plant monster for survival through flips. The rules are simple, drag and release your phone screen. Improve your skills and show it to your friends with the games quirky ranks. Select an array of characters using the orb you acquire throughout the game.