• Content count

  • Joined

  • Last visited

Community Reputation

128 Neutral

About nerdboy80

  • Rank
  1. You might also want to try SharpDevelop it includes Subversion, NUnit, and NCover integration (in editor source code highlights of code coverage of units tests == awesomeness). Debugger is a bit flaky/slow, and you can't easily change editor fonts for some reason, but otherwise its a cool little IDE. I really do not understand why Microsoft decided that giving away an IDE for learning purposes without source control or unit testing built in was a good idea in this day and age.
  2. I wholeheartedly agree with all the posters above. I just recently switched over to what I would call Test Driven Development in my project, and find not only do I feel more productive, I have more confidence in what I write as well. And about writing tests for all code. Yes, yes, yes! There have been a few times when I said "Oh, this is so simple, I don't need a unit test for this.... but I guess I will do it". Finding when I did write the test I found problems when I actually wrote my implementation. Problems I wouldn't have found until much later. Personally, I've found my "TDD" gives me: - Smaller, tighter, more functional APIs (once you realize you have to write one or more tests for every extra public function, you re-think some of your API decisions) - Loosely coupled components (since components need to be testable in isolation) - Less bugs overall (and things that do come back from QA as defects tend to be "small" things, not major problems) I've been using the CppUnit framework, which I've found pretty easy to work with. I feels a little cleaner that Boost::Test, but to each his own. Also, I think there is very little benefit in going back and writing tests for "old" code, UNLESS you plan on refactoring or re-implementing it, in which case they are absolutely necessary.
  3. I was doing some research on caching systems for vertex data on the graphics card, and came across several posts by YannL talking about his sliding slot allocation system. It seemed that he was using one massive VBO on the graphics card, and then *somehow* updating only parts of it at a time. Now I see there is a way to update parts of a VBO using glBufferSubData() in OpenGL, is there an equivalent way of doing this in DirectX? If you follow the DirectX best practices, then you should lock a dynamic buffer with D3DLOCK_DISCARD or D3DLOCK_NOOVERWRITE. Now, using D3DLOCK_DISCARD won't work because it blows away everything in the buffer, and we only want to update part of the buffer. D3DLOCK_NOOVERWRITE doesn't work either because (as I understand it) you should treat it as a write-once type of flag. Once a section of the vertex buffer is written to, then you can't write over it again (until the next D3DLOCK_DISCARD call). Now, maybe glBufferSubData() isn't as performant as I think it is. Maybe it takes the same hit as locking a directx vertex buffer with no flags, and stalling the GPU (which I believe keeps the data in the buffer, and then would do what you want). I just don't know. Any help/guidance is appreciated. Thanks.
  4. Buffer problem

    When filling the VB you need the offset anyway (to tell DX where to lock), so just use that and keep a variable for each object which is that object's offset into the VB, The go ahead a re-fill the IB.
  5. cannot convert from 'LPSTR' to 'LPCWSTR'

    You probably want to be using the UNICODE version of the string functions, so instead of lstrcpyn use lstrcpynW, ect... Oh, and I just noticed that when you're compiling you're linking against the UNICODE versions of the functions, if you don't care if you're UNICODE or not, then see if you have "_UNICODE" defined and turn it off.
  6. Um... AFAIK the D3DX guys are to be used as a GENERIC 3d library, and as such need to do certain things to keep their generality (like make a lot of state changes to make sure they are in some certain state), at the price of performance. If your app is still slowing down in release mode, then I would check your D3DX calls as well.
  7. What is XNA?

    As I understand it XNA is simply a standardization of DirectX and other microsoft gaming API's across platforms (PC/XBOX/Pocket?) which will allow games to run anywhere with simply flicking a switch a re-compiling. I believe it will allow things like PC games getting onto XBox Live and such.
  8. Is managed DirectX smooth?

    Exactly. Saying that something doesn't have a Release() method and therefore uses COM Interop is like saying that if I use the following class I'm not using COM: class Foobar { Foobar() { m_object = CoCreateInstance(...); } ~Foobar() { m_object->Release(); m_object = NULL; } IUnknown* m_object; } Just because a Foobar object doesn't have a Release() method doesn't mean it can't use COM, at some point it does need to finalize (by Dispose in .NET land, or by the dtor in C++ land), and there it can properly call release. Keep in mind the application doesn't have to call Dispose() on an IDisposable object. It's one of those "special" interfaces, which the CLR treats differently. When IDisposable objects are marked for GC they are swept off the heap, but then put in a finalization queue. Each of their Dispose() methods are then called before they are finally destroyed. Anyone with more knowledge on this subject feel free to correct me. Anyway, this non-deterministic finalization is how you would release COM interfaces, or shut down database connections, or anything else outside the realm of standard program flow. A user can of course always just call Dispose if they want the resources freed right away. In which case if you tried to use the object again (after a call to Dispose()) you would probably get an error, depending on the object's implementation.
  9. translating quad...

    If you're using vertices that are marked as "Transformed", then that is telling DirectX, "Hey, these vertices don't need to go through the world transform stage, so just ignore the world transform matrix all together when rendering them." You either need to make your vertices not of a "Transformed" type, or modify the vertex data directly, but multiplying each vertex of your model by the transform matrix.
  10. Doesn't the .X file format support hierarchical frames? If so, then just make the wheels children of the car, and everything will work swimmingly.
  11. Performance of DrawPrimitive*

    I'm still a little bit hazy on the whole expense of copying into dynamic buffers every frame vs. making multiple DIP calls, but if you're scenery was static then you could keep your gigantic VB and IB and just store the begin/end indices into your IB for each leaf. Then you just need to make a DrawIndexedPrimitive call for each leaf that is visible using the begin/end IB indices stored in it. That's more DIP calls, but you won't have to refill a dynamic IB every frame. I just love double indirection! I myself was considering re-implementing my octree to simply be a kind of axis aligned bsp tree (though it would not be a "real" bsp tree in any sense of the word). Instead of storing eight children per node, I would just store 2. The upside is that at some time I could re-arrange the indices in the IB to take advantage of this. All indices of some node's children would fall inside the indices for that node. Just like a heap-sort array if you are at all familiar. That way a could make a single DIP call on a fully visible node instead of having to traverse to it's leaves and making multiple DIP calls there.