Jump to content
  • Advertisement

mossmoss

Member
  • Content Count

    422
  • Joined

  • Last visited

Community Reputation

326 Neutral

About mossmoss

  • Rank
    Member

Recent Profile Visitors

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

  1. mossmoss

    normal x tangent = binormal?

    Quote:Original post by cignox1 I don't know if this could be the reason, but what does 3dstudio max when you mirror the geomtry? Does it mirror the tangent as well? Because if this is the case, then the bitangent will point the wrong direction. I remember there was a discussion here on gamedev some time ago about mirrored geometry, but it could heve been about uv mapping as well, I'm not sure... EDIT: check out these two topics: http://www.gamedev.net/community/forums/topic.asp?topic_id=340745 http://www.gamedev.net/community/forums/topic.asp?topic_id=352834&forum_id=12&gforum_id=0 They may be usefull... The mirrored geometry would almost certainly be the problem. The solution I've used is to include a bias term of either +1 or -1. (Can conviently fit into the w component of the shader register containing the xyz of your normal.) So bitangent = bias * (normal x tangent).
  2. Quote:My first version was a direct port from Perlin's original C source to Python. Perlin's first version, if I recall correctly, had second-order discontinuities, which would result in what you are seeing. He later improved his noise to remove that problem. EDIT: Here it is: http://mrl.nyu.edu/~perlin/paper445.pdf
  3. mossmoss

    Fast string look up

    Try a hashtable or hashmap. It's not part of the current standard, but some STL vendors have included an implementation as an extension. I would guess boost might have something along those lines as well. EDIT: 5 milliseconds is a *long* time for a simple lookup. Have you actually tried the STL map? You are assuming it's slow, but have you timed it?
  4. Quote:Original post by Drakkcon Okay, so I won't use std::list<Whatever&> but what about a class having a private reference to the dispatcher that it uses to raise events? Sure, that sounds normal. Quote: Also: It definitely compiles and I'm using Visual C++ 8 MSVC is not a paragon of compiler technology. That it compiles doesn't make it a good idea.
  5. I'd actually be surprised if it compiled... A good STL implementation would prevent you from making such a mistake.
  6. Offhand, that sounds like a **very, very bad idea**. STL containers work via copy mechanics, which is fine for pointers and objects (with decent copy constructors). References, however, do not. When the container attempts to perform certain operations on the "values" in the container, and do a copy, you are going to get very unexpected behaviour... your will begin losing some data and duplicating other data. Go with raw pointers and assert on NULL pointers, if there should not be any.
  7. mossmoss

    [C++] Memory leakage

    Quote: Since it is supplied to the constructor, I don't need to delete anything in the destructor right? Generally, it's a good practice that the section of code that allocates memory is also the one to free that memory. Which would jive with what you said. Just make sure that whoever is allocating the SSettings object (assuming it is allocated on the heap) also frees it. Quote: But do I have to set settings to NULL? Often, yes, you want to set it to NULL so you don't accidentally attempt to use the object later. But since this is a destructor, it's not necessary since the CMainScreen object itself will no longer exist. Quote: lso, is it only when I have used the new keyword that I need to use delete? Yes... new -> delete new[] -> delete[] malloc -> free
  8. mossmoss

    Some questions on precision

    Yes, as the magnitude of your floating-point numbers increase, the precision decreases. I am not sure what engine you were looking at... It may be using only floats because it is not intended for large-scale where the precision loss would matter. Or the engine authors, if they intended for such a large-scale, didn't understand this issue. In any case, here are a couple suggestions. First, keep this document handy, something everyone coding should know: http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf Second, determine if the loss of precision is at all important. What are your numbers going to represent? What units? (Inches, meters, miles...?) What is the set of values you need to represent? (For example, you might say, "My world needs to be 100 kilometers wide and I need per-meter precision.") Third, once you break it down to what a delta of 1.0 means (and 0.1, 0.001, etc)... you should be able to determine whether you can keep your precisions at the outskirts. If you can, or can live with the error, might as well just use floats. However, if your precision requirements are such that floating-point alone is going to lose more precision than you'd like, you have a couple of options... Go all fixed-point, use 32- or 64-bits. Get a good fixed-point library or write your own (not all operations trivial, though). Do some combination of fixed-point and floating-point. Use fixed-point for the gross (ie. large), more global portion and use floating-point for the finer (ie. smaller), more localized portion.
  9. mossmoss

    "Recursive Dependencies" - How to do?

    For each file, figure out if you really need to #include another file. Let's take H1 as an example, #including H2. Why? What does it need out of H2? Here's a simple example: /* H1.h */ #include "H2.h" // declares Bar class Foo { public: void Run(Bar* bar); }; /* H2.h */ class Bar { /* whatever */ }; Since you don't actually make use of Bar objects in H1 (you only indicate that Run, defined in the .cpp file, will use Bar _in the .cpp file_), you don't need the header. So you could make H1 look like this instead: /* H1.h */ class Bar; // forward declare class Foo { public: void Run(Bar* bar); }; Because you didn't use/store Bar (you only mentioned a pointer parameter), you only need to let the compiler know the name, hence the forward declaration. The cpp file, however, will need to #include "H2.h" That is very informal... You might get some more complete descriptions from others here. Aside from circular dependencies, this can help reduce compile time, so it's a nice thing to do. Also, you might consider that such a circular dependency as you describe can often, though not always, indicate a design flaw. Consider your design and see if there are ways to simplify.
  10. mossmoss

    What the f? (C++)

    An L after a number also forces it to be a long (vs an int), and UL is an unsigned long.
  11. Sounds like you want a hash function.
  12. Learn either one... they're pretty similar, so having learned one, the other will be easy to figure out. May also depend on what API you are programming to... DirectX? I think you have to use HLSL. OpenGL, I believe, uses Cg... though I don't know offhand if that is set in stone.
  13. First, get this document, "What Every Computer Scientist Should Know About Floating-Point Arithmetic": http://www.physics.ohio-state.edu/~dws/grouplinks/floating_point_math.pdf Probably a _lot_ more than you want right now, but a good document to have on hand. Second, decent information here: http://en.wikipedia.org/wiki/IEEE_754 It's hard to summarize floating-points... I'd suggest looking at the wikipedia page for a brief overview of how values are represented. Super-briefly, you could have values up to approximately 2^127. Freaking huge. And values down to 2^-126, freakin' small. But there's a price; not every value can be exactly represented. Most values are going to get rounded to the nearest value that can be exactly represented. Additionally, the density of values that can be represented using floating-point is not constant. As an example, the number of integers between 0 and 100 (using an int) is exactly the same as the number of integers between 1,000,000 and 1,000,100. That is not true of floating-point. IIRC, as the magnitude of your f.p. exponent increases, the numbers spread out. Which means if you try to use the full range of a float for your zone, as things move further out from the center of the zone, they'd start jumping. Depending on exactly what you want to do, it may be better to represent certain values with fixed-point rather than floating-point. (In case you're not familiar, fixed-point uses integers and integer arithmetic.) You'll have a well-known range and even distribution.
  14. mossmoss

    Polymorphic sizeof() Operator?

    sizeof alone will not work polymorphically; it's not actually a function (i.e. it is determined at compile-time, not run-time). I can think of a couple ways of getting the size, but without knowing exactly how/when you need your size, I don't know which is appropriate. One way: class A { public: virtual size_t ClassSize() const { return sizeof(A); } // rest of A }; class B : public A { public: virtual size_t ClassSize() const { return sizeof(B); } // rest of B };
  15. mossmoss

    Transform matrix calculation

    Quote:Original post by tconkling So it seems like a game engine ends up having to perform model transforms twice for each object in the game -- once in hardware (inexpensive) while drawing transformed polys to the screen, and once in software (expensive) for engine operations unrelated to drawing. You'll probably stall trying to get matrices back from the GPU. And your CPU calculated matrices are probably not as expensive as you think. A profiler is your friend. If you do find your matrix/matrix or vector/matrix multiplications are costly, then use your library's functions (or write your own) to do these ops using the CPU's vector capabilities (i.e. SSE, VMX, whatever).
  • 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!