Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

273 Neutral

About Drakex

  • Rank
  1. Thanks for the answers guys. SiCrane, I suppose it does make sense to just check to see if the device is lost on the Present call - thanks for the tip.
  2. But then I'd have to test the return value of every IDirect3DDevice9 function. And as far as I know, calling those functions when the device is lost is harmless anyway. And if I lose the device in the middle of drawing a frame, there's no point in finishing the frame when it comes back, since everything that I drew will have been lost. Please let me know if I'm wrong about any of this. Just from the point of view of the way I have my code laid out, calling TestCooperativeLevel once a frame is much cleaner and simpler, and all I want to know is what performance considerations, if any, it has. If virtually every function in the interface can return D3DERR_DEVICELOST, I'm guessing it's not a terribly expensive operation.
  3. Premature optimization is the root of all evil and all that, but is calling TestCooperativeLevel once per frame OK? The MSDN docs just don't have any information as to its performance characteristics and I'm wondering if this is the typical use case or if I'm just doin it rong.
  4. Drakex

    The D language

    Quote:their advantage of no legacy support is negated by their lack of legacy support. This is where D differs from C# and Java - D can natively link to and call libraries that expose a C interface. In fact D can also create libraries with a C interface. There are no shims or complex porting issues to deal with, and now that there is a tool called htod which converts from C headers to D import files (using a C compiler frontend to do so), using C libraries in D is almost painless. Quote:I'm sorry but that is a pathetic example and poor C++ code. .. Well that says it all... Oh snk_kid, you are so cool. I don't even know how to begin to comprehend your arrogance.
  5. Drakex

    The D language

    Quote:Does anyone have some code that shows D doing something better than C++ or at least being done in a less complicated fashion? Alright then. This is a trivial example, but demonstrates a few key issues: operator overloading, templates, classes, and overall syntax: #include <iostream.h> #include <assert.h> template<typename T> class MyContainer { private: T* mData; unsigned int mLength; public: MyContainer(unsigned int length) { mLength = length; mData = new T[mLength]; } ~MyContainer() { delete[] mData; } T& operator[](unsigned int index) { assert(index >= 0 && index < mLength); return mData[index]; } unsigned int length() { return mLength; } }; int main(int argc, char** argv) { for(int i = 0; i < argc; i++) cout << "Arg " << i << " = " << argv << endl; MyContainer<int>* c = new MyContainer<int>(10u); (*c)[4] = 5; (*c)[6] = 10; cout << "Length: " << c->length() << endl; cout << (*c)[4] << ", " << (*c)[6] << endl; delete c; return 0; } The equivalent in D: import std.stdio; class MyContainer(T) { private: T[] mData; public: this(uint length) { mData = new T[length]; } ~this() { delete mData; } T opIndex(uint index) { assert(index >= 0 && index < mData.length); return mData[index]; } T opIndexAssign(T value, uint index) { assert(index >= 0 && index < mData.length); return mData[index] = value; } uint length() { return mData.length; } // Hell let's make an iterator, I don't have a clue how to do that in C++ int opApply(int delegate(inout T value) dg) { int result = 0; foreach(T val; mData) { result = dg(val); if(result != 0) break; } return result; } } void main(char[][] args) { foreach(uint i, char[] arg; args) writefln("Arg ", i, " = ", arg); MyContainer!(int) c = new MyContainer!(int)(10); c[4] = 5; c[6] = 10; writefln("Length: ", c.length); writefln(c[4], ", ", c[6]); foreach(int v; c) writefln(v); delete c; } Just........ yeah. THAT'S why I don't like C++ anymore.
  6. Drakex

    The D language

    Quote:The only way he will truely learn something new and actually broaden his view on problem solving is by learning languages based on completely different programming paradigms. The nice thing about D is that while it follows similar programming paradigms as C++, you find yourself working more on solving your own problems rather than dealing with deficiencies in the language. So rather than thinking about low-level implementation details (what containers to use, what memory management scheme to use, worrying about getting headers and cpp files synchronized, worrying about virtual methods), you just program your damn program and most of the time, it's almost trivial to implement. A prime example is the STL collection in C++. STL attempts to augment C++'s rather anemic data abstraction abilities, and does so, if perhaps in a somewhat wordy fashion. In D, there are some STL-style libraries, but I've never found myself needing one. For the most part, dynamic arrays, associative arrays (very similar to std::map), and custom class hierarchies achieve everything I need in terms of data abstraction. Associative arrays alone have taken the place of several more complex data structures that I used with C++. Quote:C++ could be a better language, if its evolution weren't that painfully slow. There are so many nice features in the pipe that I want to have now, not in 2009... C++ could also be a better language if it weren't weighed down with being natively backwards compatible with about 35 years of legacy code. Any new feature in C++ has to be painstakingly reviewed, checked, and tested to assure that it doesn't conflict with or break any existing code. D has something of an advantage because it's still being designed, but the point is that C++ is too old and too bloated to improve. This is D's entire mantra: it's not trying to be a better C++, it's just trying to make a language that has abstractions that have become common in programming today. Quote:When you look at D you see a potentially capable language that has many nice features, however does it truly have the support network there for you to work effectively? This is always the catch-22 with new languages. People don't want to use it because it isn't mainstream, but it'll never become mainstream if people don't use it. What has to happen is a critical mass of people have to take the leap of faith and try it out.
  7. Drakex

    Pause key

    I have the scan code documented as 197, and that seems to work.
  8. Drakex

    Am I really in full screen mode?

    Try SetWindowLong(yourHwnd, GWL_style, WS_POPUP);
  9. Drakex

    How different is DX10 vs DX9?

    Quote:I have some .3ds files and would like to use them in DX, but have a feeling I will need to convert them to .X to load them? Nope. The DirectX SDK provides helper functions for loading X models, but the API isn't tied to the format. You can write your own 3DS model loader (which you might have mostly done in OpenGL). Quote:Also can the .x file do animations? Yes, limbed or boned with vertex weights.
  10. Thank you, Sherriff. (of Nottingham) Just what I was looking for. :)
  11. So the entries in the bone combination table point to the old attribute table entries?
  12. Hmm.. kind of strange that that method provides remapping for faces and vertices, but not subsets! What you could do: 1) Lock the original mesh's index buffer and attribute buffer. Copy them to temp arrays. Unlock. 2) Run the ConvertToBlendedMesh method, and give it a place to put the face remap. 3) Lock the index buffer and attribute buffer of the new mesh. Using the face remap table, look up the index of the old face, i.e. oldFaceIndex = remapTable[newFaceIndex]. Then look up the attribute for the old face, oldAttributeTable[oldFaceIndex]. Then look up which material (or however you have it set up) that corresponds to that attribute. Set that as the material for the new attribute table value. 4) Get rid of the old temp index buffer and attribute table arrays. Maybe some pseudocode... short oldIndices[...] int oldAttributes[...] oldMesh->LockIndexBuffer() oldMesh->LockAttributeBuffer() copy data from locked index and attribute buffers into arrays oldMesh->UnlockIndexBuffer() oldMesh->UnlockAttributeBuffer() int faceRemapTable[...] skinInfo->ConvertToBlendedMesh(oldMesh, faceRemapTable, newMesh) newMesh->LockIndexBuffer() newMesh->LockAttributeBuffer() foreach face in newIndices { int oldFaceIndex = faceRemapTable[newFaceIndex] int oldAttribute = oldAttributes[oldFaceIndex] Material oldMaterial = oldMaterials[oldAttribute] newMaterials[newAttributes[newFaceIndex]] = oldMaterial } newMesh->UnlockIndexBuffer() newMesh->UnlockAttributeBuffer() delete[] oldIndices delete[] oldAttributes delete[] faceRemapTable Something like that!
  13. Drakex

    effect based render engine

    I've implemented method 2 in my engine, and it wasn't too terribly difficult. I have two classes: Effect, which holds the actual effect interface and a table of per-effect variables, and EffectInstance, of which each instance is a child of an Effect class, and has per-instance variables. So for example, I load one Effect. It might have a per-effect variable called LightDirection. I set that. That way, the light direction will be the same for every instance of the effect. I then create two separate instances from that Effect, and apply them to two different objects. The instances have a per-instance variable called Diffuse, which I set to different values for each instance. Then, when I render, I sort by effect and then by instance, so what happens is: Effect->Begin() Instance1->ApplyVariables() Object1->Draw() Instance2->ApplyVariables() Object2->Draw() Effect->End() The effect is only begun / ended once, and each instance just applies its per-instance variables to its parent effect. There are no limitations, since each effect and instance holds a parameter table which is taken straight from the effect file. So, if I want to set the diffuse of an instance, I do Instance1->SetFloatVector("Diffuse", 1, 0, 0, 1); If you keep a standard naming convention for parameters for all your effects, you can usually use some of the same code for all effects. Of course, if I really felt like it, I could derive a class from the EffectInstance class for a certain effect, so that I could get errors from the compiler instead of at run-time in case I mistyped a name. But that's just a personal preference.
  • 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!