Bliz23

Members
  • Content count

    112
  • Joined

  • Last visited

Community Reputation

188 Neutral

About Bliz23

  • Rank
    Member
  1. Xna, Terrain, and Models

    I'm kinda short on time, so I can't do any code. But basically this is what you need to do. +z | | | | | -O--O--1--2--O- | | |# | | -O--O--3--4--O- +x | | | | | assuming 1,2,3,4 are your surrounding vertices, x increases to right, z increases up, and # is the position of your object. also |1 - 2| is just the distance between 1 and 2 and so on... 1) Find the height of the four vertices around you. (ie the y value of 1,2,3,4) 2) (only use the x values for these except when stated at the end)Then take ratio of |# - 1| / |2 - 1| (should be less than 1, if not, you screwed up) and then multiply that by 2's y and add (1 - ratio) * 1's y lets call that y1 3) Do the same with 3 and 4 in x again, call that y2 4) (now do this in the z direction)take the ratio of |1 - #| / |1 - 3|. multiply this ratio by y2 and then add (1 - ratio) * y1 5) the resulting addition should be your y value of the object at the # position
  2. direction of velocity?

    If I'm reading it correctly, the paper is saying that ve and vk are velocities at a certain time e and k. So if you know calc, you can say its the first derivative of the positions. The angular(ve) and angular(vk) is now considered 'position' but talking about angles. Basically angular(ve) means the angle between the ve and the x-axis, counter-clockwise. So if ve lay on the y-axis it would be 90 degrees or pi/2. angular(vk) is the same concept but corresponds to the velocity vk. Where omega or the w looking thing comes in is considered to be like a rotational velocity, hence why its change in angular (ie position) over time. So eq. 5) [source:]w of k+1 = (Angular(vk) - Angular(vk-1) ) / t basically is the change in the angle of the velocity over time. So more or less how fast the object's velocity (which will correspond to the object's position) will rotate. That being said, you can calculate it by taking arctan(Vey/Vex). But you will need to add 180 deg if Vex is negative. Also cos(angular(ve)) will simplify to (Vex/|Ve|) and sin(angular(ve)) will simplify to (Vey/|Ve|) where |Ve| is just sqrt(Vex^2 + Vey^2). Hope that helps, let me know if you have other q's. -bliz
  3. Terrain engine

    Wow, this is really amazing. Like some others, I have been watching this for a long time. In fact this is what keeps me coming back on this website ;). I first started reading when you first did procedural textures and I remember thinking that you should stick with actual textures because it looked crappy. Haha, was I wrong, you sure made everything look amazing.
  4. seamless!... Maybe

    Hope I'm not too late to post this, but I used to do some research on implementing seamless terrain. Here is an article that really gave me some good ideas to do. Game Developer's Conference. Click on the "Continuous World of Dungeon Siege". Another good engine that you should look at is the World of Warcraft engine. Even though the game has been out for a couple years, it's stilll a great MMORPG partly because there are no loading times, and the environment is huge, too big to store it in RAM. It is pretty simple, like what other people have said, at least from studying it. It's not really seamless but it loads/unloads stuff in the background, making no loading screens and it seam seamless. Realistically you could make your world as big as your hard drive can handle then, or if it was procedurally created, it could go on indefinitely. Hope that helps.
  5. D3D10 and XP. Again.

    What's so bad about swimming across the atlantic ocean? I swim it everyday after my morning tea with sasquatch.
  6. Silverbow and space rain..

    Even though its only a spaceship and rain drops shown on screen, it looks very well polished. The only thing that really gets me is how do you have rain in outer space??? [edit] My bad, I was to amazed by the pictures to read that you we're gonna keep the space rain.
  7. Weird Translations

    You realize that in one second you can have over 60 frames and that would lead to moving at least 6 units per second. My advice would be to set a breaker after like 50 loops in the draw section and see what your ztrans value is. If it seems right, then its your translation, otherwise it might just be your actual ztrans, which is whats wrong most of the time with mine.
  8. Question about making a Hud

    Yeah, just use device->Clear() method, with the 3rd argument as "D3DCLEAR_STENCIL | D3DCLEAR_ZBUFFER" and the 5th = 1.0f, and 6th = 0. I think you figured it out, but incase you didn't (or messed something up ;) there it is. But like bennyW said, clearing will be almost no problem at all. I know Ysaneya's great Universe engine (ok, so its not enough for a whole universe, but at least a galaxy, unless hes been lieing to us all this time!!! lol) clears it multiple times a frame, so doing it twice should have no problem. I know I did it once, and i didn't notice any slowdown on my crappy card either. Hope that helped.
  9. Question about making a Hud

    One simple way to do this is to draw all non-hud geometry first. Then either: A) Reset the zBuffer to whatever you reset it to(1.0f or 0.0f, can't remember right now) then draw your hud geometry, and repeat infinitely as long as you need the hud and geometry to be drawn. -or- B) Disable z-writing and z-testing. then draw all hud geometry in order of apperance level (like starting with the background hud stuff, then the decals, then the numbers... drawing the farthest away first, and drawing the next closer items next) Thats my quick fix on it. They aren't the only ways, but they seem to be one of the easiest.
  10. A nice paper that describes dungeon siege's continuous world, terrain implementation and nodes and all that beautiful stuff, it helped me give ideas for my own half engine(haha, itll never get done). The Continuous World of Dungeon Siege.
  11. I don't really have much time, but floats work like this. They work well with relatively the same size numbers. So if you have really big numbers, than you will only be able to find the difference between the two in "big numbers." but since your two objects 100km from the origin are only 1km from each other, the system will round 1km to about nothing. That is true when you work with really small numbers. you can have numbers like 1.23x10^(-12), but then when it compares to others it won't be that precise. I don't think that really made sense, lol. I'll try one more way. With floats, it works with significant digits. You can only 7 digits that are significant. so if you have a number like 1234567890, it will round it to: 1234568000. Same with smaller numbers. an easy way to think about this is in scientific notation. 1.234568 x 10 ^ (10). it doesn't matter what 10 is raised to, what matters is the numbers in the decimal, only 7 digits will be there. That is why when you have large numbers, it rounds the numbers so when you compare two numbers that are 1m apart 100km from the origin, it will be like comparing the same number. Hope that helped, and how precise all the actual information is is not exact, like 7 decimal places, but it is a rough estimate to help you understand floats. Best way to deal with the problem i think is to just have multiple origins, making the units m instead of cm won't help much because of how floats operate, so just make multiple origins. Good luck.
  12. app not remaximizing the window

    Yes that is "losing a device". Two good websites on it (no need to have me explain what is already written down): lost Device descrition source of restoring the device. if you have any questions, don't fail to ask.
  13. that is because alt tabbing shows the render queue of the windows. it is saying that your program will be on top of everything else that there is. whats on the bottom will be rendered under everything before it in other words. But it doesnt take into account the minimizing, so when it is minimized, it will still try to render it on top, but since there is nothing to render, you wont see it. it makes sense when you actually think about it.
  14. Windows Programming! What A Task!

    first thing you should do to get rid of that warning and to really make your WndProc right is to change your return function to:return ::DefWindowProc( hWnd, msg, wParam, lParam ); You should then get rid of your default "case." That should get rid of your warning. [edit] wow, i feel very dumb for saying that now, just ignore it all. wow, i should really get my homework done earlier and not be up so late.[/edit] And as far as not being able to run the window, im not sure exactly what is going on. i think it might be something wrong with your hInstance you sent to it because when i put it in my app, it works fine. If you want to show your winapi winmain function with it callling this, that would be great, otherwise im not sure what is wrong.
  15. Very Basic Project

    It will work on all windows, but if you want it to work on a mac and you want it to have a gui, then you are going to need to find a library or learn some more on gui for each system. Otherwise if you don't need a nice gui and a console app will work, then just use like C++ and a cross platform compiler, good luck with that though, because cross platform can be a very tricky thing when you are first starting off with it (well not thats its straightforward after you learned it) hope that helps