Advertisement Jump to content
  • Advertisement

JoeyBlow2

Member
  • Content Count

    930
  • Joined

  • Last visited

Community Reputation

100 Neutral

About JoeyBlow2

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks! Thats what I wanted to know. I'm going to stick with unmanaged C++ and DX10 when its available. Haha, I got voted down 20 points in my forum ranking for asking this question. Good old Gamedev.net. How I've missed you.
  2. I've been out of the loop of game development for a good year or so now, so I've lost track of the developments since then. Is Unmanaged C++ still going to be a viable option for DirectX development in the future? Like when DX10 is released? Or is it going to be managed/dotnet only? Anybody know?
  3. Thanks for the help. I'll look into those suggestions and see what works out.
  4. First of all, this is my first attempt to learn C#. I'd consider myself an expert at C++, but I'm finding C# too restrictive because the lack of pointers and its starting to frustrate me. Since C# 2005 doesn't support TGA file formats natively in the picture box I'm attempting to write my own picture box control. (Just for TGA) The file format specification require you to read in the last 26 bytes of the file to determine if the format is New or Old by reading a tag in the 8-24th (16 byte string) position in those last 26 bytes. Being a C++ native, thats simple. Read the last 26 bytes directly into a struct that has int's and char[16] and do a strcmp on the char[16] to see if the tag is correct. Thats simple. Of course, in C#, they are making this much more difficult than it needs to be, and I'm about to throttle my visual studio! I can read in the 26 bytes into a byte[] array, and I see I can create a string from an sbyte[] array if I include an offset and a length. But the byte[] and sbyte[] are incompatible with each other... So how do I convert? Also, how do I pull integers (4 bytes) out of that 26 byte and convert those byte[4] into an int without using pointers? I just need an offset, but in C++ I'd just memcpy the 4 bytes into an int variable and I'd be done... Any help is appreciated.
  5. JoeyBlow2

    Permanently "Set Processor Affinity"

    I use WinLauncherXP (google it). The processor fixes on AMD website didn't do much for me.
  6. JoeyBlow2

    timeDelta causing laggy movement

    I believe that only applies if you have multiple threads. If I remember right, the DirectX 10 documentation says that each thread should calculate its delta from results of QueryPerformanceCounter on the same thread. For example, you don't want to call QueryPerformanceCounter on one thread to get the start time, then calculate the end time from another thread. As the threads could report different times because the cores have different results (and give you negatives.) If you have each thread doing its own QueryPerformanceCounter start/end calls, you are doing it as they suggest. However, I may have misunderstood that.
  7. JoeyBlow2

    timeDelta causing laggy movement

    timeGetTime is not the best method to use. I believe its based on a 5ms timer internally. So sometimes you will get the time passed as 0, othertimes 5ms. So depending on the results you get, it could leave you with a choppy scene. QueryPerformanceCounter() is the best time method to use. It goes down to the clock cycles for interval/calculation and can give you the time in nano-seconds rather than 5 milliseconds. Quote: Windows NT/2000: The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine. You can use the timeBeginPeriod and timeEndPeriod functions to increase the precision of timeGetTime. If you do so, the minimum difference between successive values returned by timeGetTime can be as large as the minimum period value set using timeBeginPeriod and timeEndPeriod. Use the QueryPerformanceCounter and QueryPerformanceFrequency functions to measure short time intervals at a high resolution,
  8. JoeyBlow2

    Index Buffer

    Vertex Buffer just store the Vertex data. The point's position, normal, etc. Index Buffers store how the Vertex Points link together. Like "connect the dots." Indexes are just numbers which represent point to the vertex in the vertex buffer in an organized way which creates strips, lists, and fans. For example VertexData vertex[10000]; vertex[0].x = whatever; vertex[0].y = whatever; vertex[0].z = whatever; vertex[0].nx = whatever; vertex[0].ny = whatever; vertex[0].nz = whatever; (and so on) IndexData index[6]; index[0] = 0; // <--- this points to the vertex 0 in the vertex array. index[1] = 1; // <--- this points to the vertex 1 in the vertex array; (and so on) Its more efficient to pass updated Index Buffer data to the graphics card because its just an array of shorts or longs, rather than arrays of vertexdata structure, which could be 50 bytes per vertex. Its much more suited to send the entire vertexdata to the card and never update it, and only update the Index buffer for LOD algoritms.
  9. 8 bytes per R,G,B,A = 32 bit DWORD. Use the D3DCOLOR_RGBA(0-255,0-255,0-255,0-255) macro which is nearly the same as the RGB() function but accepts an alpha and places the colors in the right bytes. I believe in D3D, the bytes are stored in those 32 bits as ABGR or BGRA (I cant remember), instead of RGBA. Which is why you are getting yellow instead of blue-green (its combining green and red in your case). Just make sure you use that D3DCOLOR_RGBA macro and you shouldn't have to worry about it. ;) edit -- i'm too slow. Agony beat me to it.
  10. Try looking at this thread. Another person had a similar problem and it could give you some suggestions.
  11. Use both. Use DirectInput for relative direction (and buffered keypresses, or whatever) and use the windows message to see where the cursor is relative to the window.
  12. JoeyBlow2

    "Background" Light

    Yes, ambient light renderstate. Also you need to create materials for your objects. You can specify how much the material will return. That way you can leave everything reflecting no ambient light for those you want that way, and for the background have it return the ambient light.
  13. JoeyBlow2

    My Terrain Engine [demo posted]

    The Terrain Stitching could use some work, but otherwise good job! Try using this approach. Instead of terrain mesh "square" being created like: ------- |\ | | \ | | \ | | \ | | \| ------- Try using this approach ------- |\ /| | \ / | | \ | | / \ | |/ \| ------- That way when you stitch its just a matter of adding a line to the square which changes detail (I seperated the squares in my example below to give you an idea of the neighbhoring square might look like): ------- ------- |\ /| |\/|\/| | \ / | |/\|/\| | \--| |--|--| | / \ | |\/|\/| |/ \| |/\|/\| ------- ------- And you can keep dividing in such a way from very corse to fine detail.
  14. JoeyBlow2

    z-buffering(I think)

    There could be 3 issues. I'd check for all 3 and make sure you are doing it correctly. 1) With Cullmode CCW, it means thats any indexes (or vertex) which are aligned counter clockwise will be culled. For example. Lets say you have a square (side of a cube) made up of 2 triangles. 1-----2 | /| | / | | / | | / | |/ | 3-----4 If you set up the index as 1, 3, 2 that sets up the triangle to be drawn CCW, and therefore, that triangle will be culled with a CCW Cullmode. You need to render it in the order 1,2,3, and the other triangle as 2,4,3. The starting number of the points do not matter, as long as they are clockwise, for the first triangle you could draw it 2,3,1 or even 3,1,2... Doesn't matter. As long as the points go clockwise. 2) Check the ZBuffer write renderstate. For ZBuffer, there are 2 different states which control the reading and writing of a zbuffer. Having ZBuffer on will check the zbuffer to see which objects are in front. However, if you have zbuffer write off, nothing will write to the zbuffer. So the location of the objects never get written to the zbuffer. You should set both of them on when drawing cubes. (There are instances where you want to read the zbuffer but not write to it, and vise versa) 3) The camera projection matrix needs to include zbuffer range. (or scene min/max) If you have 0,0 for those ranges, its basically saying read/write to the zbuffer with those ranges and as you can tell, everything will be 0 and it will act like there is no zbuffer. Also, you can't use a 0 for a znear, or unlimited number for the zfar or you will get problems. Try setting numbers like 1 and 1000. Which means everything between those 2 distances will read/write to the zbuffer. The 3d view is like a pyramid going into the scene with the top of the pyramid cut off (to create a square which gets mapped to the square monitor)... Look over that, one or more of those are usually the cause of the problem you are seeing.
  15. I was experimenting with DEM data to load in landscapes around the world. The issue I'm seeing is that the DEM data is 30 meters. Which means a 108 km "grid" of the world is 3600x3600 (over 13 million points). Loading this data and creating vertex data uses an extreme amount of memory. What methods are best to combat this? 1) Reparse these DEM files and make them less resolution. Maybe 100 meters 1200x1200 points (1.5 million points). But this degrades the detail. 2) Load the points into system memory, then calculate LOD on the points, and create vertex data high resolution for around the camera, and lower resolution for things farther away and dynamically create the vertex data as things come in and go out of range. But this seems to be alot of calculating. It can be done in a thread which isn't a problem, but is this worth doing? 3) Analyze the file, creating detail where it needs it, but scale down areas around locations that seem similarly flat, and leaving hilly areas higher resolution. This leaves data to be static but requires someone to go through the files and create patches based on the DEM files. Does anybody have a better idea? And if one of mine is an ideal solution, which one would it be?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!