Figured I''d share this with you guys, because, well, I think its nifty. Now, I had been working on a 2D isometric engine with different elevation levels, when Bracket posted his article on using D3D. I modified my code in a couple of days to take advantage of his article (Which was very helpful, btw) and recreated the engine, only now with smooth looking hills. But in my old code I had created terrain transitions similar to the article posted by Dave so & so, a while back about using overlays of tiles to create these transitions. (look in previously featured articles, its a good article I thought) The thing is he had 4 different tiles for instances where there was one side border (N, S, E, W) etc... Basically, he need a lot of art work... Well, with some nifty tricks with setting up textures, you can use just ONE texture to create all 4 Transitions. This is cool, because it means if your art group draws say, 8 different types of borders for one side, you can use those in every direction, meaning, you get the most out of the artwork, and need to load less of it, and it will look pretty good (Does some funny stuff because of sizes... but anyway) Here is how it works in psuedo code, I''d suggest getting a piece of paper to help you work through it. To rotate a texture, you just need to reassign the texture values appropriately. The texture values where the ones set like (If these are slightly incorrect I''m sorry, I''m doing this from memory here....) the tv, and tu might be off for 1 and 2. (in other words, reverse them) Vertex[0].tv = 0.0f; Vertex[0].tu = 0.0f; Vertex[1].tv = 1.0f; Vertex[1].tu = 0.0f; Vertex[2].tv = 0.0f; Vertex[2].tu = 1.0f; Vertex[3].tv = 1.0f; Vertex[3].tu = 1.0f; So that would be for a texture in the ''normal position'' I call it North Facing. I assume the default is north. But supposed that border is on the east side... Think about the vertices Bracket used, they aren''t in a perfect clockwise, fashion. So 1->3, 2->0 0->1 3->2 in other words Vertex[2].tv = 0.0f; Vertex[2].tu = 0.0f; Vertex[3].tv = 1.0f; Vertex[3].tu = 0.0f; Vertex[0].tv = 0.0f; Vertex[0].tu = 1.0f; Vertex[1].tv = 1.0f; Vertex[1].tu = 1.0f; Now your texture, is if I''ve done this right, (did it right in code, you might need to experiment) Rotated 90 degrees. You can reset these for all different directions. The only code you have to figure out, is to decide which direction to rotate it. You can check out a little demo of it at - No source code yet, I''m sorry, its just not ready for public consumption. http://www.speakeasy.org/~tredfern/ShatterRealms.zip BTW - You might notice some transparency issues. A few people have told me about this. All I can say, is if you do experience that, try replacing the transparent color in the art work, with black. If that doesn''t work, I''m sorry, its just a test build, and it works on my machine( and many others as well) ;P

I love the demo even though the transparency is screwed up. Could you pleas send me the source? I am working on my engine to incorporate the d3d thing but I have little experience with d3d so I am stuck. I connot get multiple textures to be assigned. Like I want to assign a texture to each map tile but I cannot get it to work.

If you are willing to send me the source codes send it here
natedest@hotmail.com

Well, once I fix the transparency issue for everyone''s machine, I''ll feel better about posting any source code.

I''ll have to convert the code somewhat into a simplified format, this code isn''t available at this time for the public, but I might be able to put together a smaller version (Which would be easier to understand anyway, There is a LOT of code in it....) But I have no idea when that will be possible. Later this week at the earliest.

It looks good, except for the transparency problem.
I''d like to see a finished product when your done. I was getting 60-75fps with my AMD K6-2 350 just to let you know

This transparency issue would be so much easier to deal with IF it would just happen on my machine!!! Arggghhh classic programmer bug report syndrome.

Works on my machine must be user error ;P

I''m going to rewrite it to fix the tranparency issues, I''ll post when I have the time to get it done.

Regarding the transparency issue...i had a similar problem when I was using 16bpp mode. The colour I was suppling as the colour key, while being correct for 24bpp mode, wasn''t right in 16bpp.

As it works on your machine and if you are using 16bpp, are you using the 5-5-5 pixel format? This would account for why it doesn''t work on my machine as I use the 5-6-5 pixel format.

No sense being pessimistic. It wouldn''t work anyway.

Well, I the code should be setting it appropriately based off whether it is 555 or 565. I''d already resolved that issue with a sprite engine I built a while ago, and it uses similar code. All my ''Color'' calls use a function that returns the correct (at least should be correct) value depending on the mode the monitor is in.

Now, listen to this.

When I''m writing the code and using a debug build, the transparency only works when it is black. Let me rephrase that, I set the transparency with the exact same code in release and debug builds. In the debug mode, I have to modify the artwork for black to be the transparent color, when I compile for release mode, all of the sudden, black is no longer transparent, but the fushcia color I specified is....

Weird huh?

But from what i''ve read, I don''t want to be using color keys in D3D mode anyway, and instead use alphablending, so that''s what I''m going to do.

Debug mode may be zeroing out your memory before you get to use it, so if there''s an oversight in your bitshifting operations, the colorkey may work right in 5/5/5 mode in debug, but not in release, if you see what I am getting at.

For example, if you just took an uninitialised INT, and ORed it with your Red value, then your Green, then your Blue, there may be 1 bit that you never touched and therefore could be ''wrong''.) Black is 0 no matter whether you''re in 5/5/5 or 5/6/5 mode, whereas the value for fuschia differs depending on which system you''re using. You might want to check all your color masking stuff.

I think I fixed it last night. Stupid error on my part.

I had originally created my engine as a purely 2D thing. When I started reading about 3D and integrating it, some of my code got wiped that checked the color key. So the flag that lets it know whether it was 555 or 565 wasn''t getting set.

I have a color routine to return the correct color value based on the color mode. When I called it, it couldn''t resolve to either 555 or 565 so it just returned nothing... Funny thing is, that code had worked for so long, I figured nothing could be screwed up there, but I had changed it without realizing. I ended up stepping through the function, and found the problem. No matter how many times this happens, I seem to forget.


It doesn''t make sense why it worked on my machine in release, but that''s not the point, I believe its fixed, but don''t have another machine to test it on. So if anyone is bored could they check it out for me and see if it works. The above URL is correct.

Also, I added F4 key to turn a grid overlay on/off. Its pretty inefficient but I added it so I could see how the hills looked easier.

Now, to move on to drawing an interface, which seems to be the least talked about subject on this board.

What version of dx are you using? And ARE YOU EVER GOING TO RELEASE THE SOURCE