Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

217 Neutral

About CraZeE

  • Rank
  1. CraZeE

    A program of particle fire

    i'm running on a Radeon Mobility X300 - 72fps Just curious, how ARE you doing your rendering for the particles? I'm asking because I've worked on a particle engine a few years back and it gives a decent 100+ fps on my old geforce4 running on a pentium 2 :O Unless you're doing something unique, i believe you shud be getting much better framerates for what (seems) like a simple implementation. Enlighten us :)
  2. by large worlds, i'm assuming you're worried bout particles in the distance OR huge number of systems across different locations in the world. they are somewhat 2 separate problems that I would treat differently. 1. as distance increases, the detail level will not be perceptible. i would recommend performing some form of LOD to minimize processing. This applie to both the aforementioned scenarios. 2. precision may not be an issue unless you're performing per-particle transformation at world coordinates. Excluding live systems in immediate vicinity of visible area, systems located far away could be rendered to texture. That way, precision is not an issue, and u just need to render the texture ala imposters on the world.
  3. just came off the top of my head... IF you're having a problem of accessing functions in a namespace due to declaration oerder, then it is NOT a namespace issue. Functions, in general, are required to be at least 'declared' before using. If your code calls a function (in a namespace) and the function prototype hasnt been declared at the point of using it, then its gonna be a standard link error. Either way, its not the namespace thats the problem, its the order you declare the function in the namespace with respect to the function caller. Hope that made sense.
  4. namespace forward declaration? honestly havent heard of this, nor the need for it. Namespaces are special compared to classes. Class/type declarations must me complete with respect to file. As in: // In A.h class A { // class contents... void firstFunction(void); }; You can't have this after you do the above: // In A-2.h class A { // class content 'extention' void secondFunction(void); }; The above just wont work and compiler will kick ur a** about type redefinition, etc. Namespaces dont have this limitation actually. You can open and close a namespace (almost) anytime and anywhere, each content being universally appended into ONE in the background. So why do you have this namespace issue again?
  5. CraZeE

    Confusion: Libraries, .lib and .DLL

    whoa~ reading up on multithreading is useful but it is overkill for your situation. Here's the breakdown as best as i can explain. Most programs are linked to a C Runtime Library (CRT). The runtime library itself exists in a few forms: 1. Single Threaded 2. Single Threaded Debug 3. Multi Threaded 4. Multi Threaded Debug 5. Multi Threaded DLL 6. Multi Threaded DLL debug Now, without getting to much into detail yet of each variant, here's the important news: You *must* ensure that all components in a project are all compiled using the same runtime library. So if you make an EXE project that links to a LIB file and a DLL (jsut for example), you must make sure that they're all configured to link to the same type of runtime library. In the case of bundled or 3rd party LIB/DLLs, they usually provide different variants of their libraries OR they should tell you explicitly which type their library is linked to. To change this setting, check the project properties. Select C/CC, Code Generation -> Runtime Library dropdown. As to what each variant does, that's a bit more complicated. The easiest to understand is the Debug/Non-debug runtimes. When you're compiling into a debug configuration, you should use the Debug runtime. Easy! Why? Coz the debug runtimes will have debug symbols and information that permit you to do your code debugging properly. As for multi/single threaded, that I cant really explain easily. However, I can help on the Multithreaded vs Multithreaded DLL. The DLL version will generate smaller output files, but the target system must have the runtime libraries installed. Which means, if you create an installer for your app, you wanna make sure that: 1. You check that the user has the runtimes installed 2. If not, you bundle the runtime DLL with your app Point 2 makes its a moot point to use DLLs, especially when developing on .NET 2003 and above coz their runtime files may not be the same as the defaults bundled in the OS. If you wanna avoid all this 'DLL not found' errors, then link to the standard multithreaded runtime. You get a larger file output, but chances are it'll be smaller than bundling the runtimes with your installer :)
  6. how do you handle motion/path updates for particles? is it hardcoded? if it is, i would recommend implementing some way to provide the particle system with a 'behavior' function. that way, particle behavior is not linked to the system in general although such a behavior can also be replicated if done this way. This would be handy coz you can just swap the 'behavior' and the particle/system will adapt to it. Imagine a fire system in a windless environment, then when you introduce wind, the behavior is updated by just providing a new function. the same can be applied to any modifieable element of the system. I created a system once that had pluggable motion and emission area. It promotes extensibility to the system, though it seriously depends on how much extensibility you'd like to have.
  7. generally speaking, casting to a base class is always possible... but you're trying to cast a base class to a derived class. Haven't actually done that myself, but it seems logically valid that it would fail. casting to base class is valid, however, because the base class in its entirety is a part of the derived class. casting to a derived class however is not recommended (if not illegal in the first place ). Imagine: class A { // Simplified for brevity public: virtual int DoSomething(); }; class B: public A { public: virtual int DoSomething(); virtual int DoSomethingElse(); }; // USAGE possiblities? A* toBase = dynamic_cast<A*>( new B() ); toBase->DoSomething(); //toBase->DoSomethingElse(); <-- This will give compile time error B* toDerived = dynamic_cast<B*>( new A() ); // Don't think this will work // Why? Because the following would cause a runtime error if the above // succeeded. A pointer to B will allow access to a defined 'DoSomethingElse' // which is non-existent in the original class-A toDerived->DoSomethingElse(); not sure if my explanation helps, but thats my 2cents.
  8. yes, as Muncher puts it, most system APi callbacks have at least one void* parameter that can be used for arbitrary data. In most cases, especially in an object-based application, you can (and should) piggyback the 'this' into the parameter. just keep note of this limitation and/or solution whem making your own callback mechanisms in the future. You can apply this same logic into designing your callbacks ;)
  9. Quote:I do feel that the VS2005 compiler is extremely picky. On VC6 and any other compiler and IDE combo, I could have: MessageBox(NULL,"Hello","Hello",MB_OK); On VC2005, MessageBox(NULL,L"Hello",L"Hello",MB_OK); That L parameter came out of nowhere. It's annoying, especially if you've never used the compiler and don't know it's even supposed to be there. erm.. i think you need to know your IDE more before comparing it with others. The 'L' parameter has been around for a LONG time and not just in VS2005. I've seen it in .Net and .Net2k3 (cant confirm for vc6). What it stands for has already been explained by JohnB. Quote:Is it just me or was that a blank message...? The first parameter is a handle to the owner window. So the Messagebox command specified in the example has a title of 'Hello' and content of 'Hello' with an OK button, and it is linked to the desktop (i think).
  10. u didnt mention the OS you're running on so its a gamble. If u're using windows (highly likely), then there's a collection of functions on console formatting. However, these use the Win32 API and might be a bit complicated at first. For exact details, check out MSDN.
  11. CraZeE

    Operator overloading class members

    out of curiosity, wats the reason for the operators to be private? If you're gonna use them from outside of the class, then chances are you won't have permission to access private methods.
  12. CraZeE

    creating a DLL

    i'm not very used to anything besides a standard DLL (so COM is not my expertise). So here are wat i (hopefully) know on DLLs: Pros ==== 1. Dynamic loading (duh!) - Since the client app and the DLL are not linked (though possible) at compile-time, you can update the DLL and/or client application without recompiling the other. 2. Reuse - You can more easily integrate a DLL into another project, avoiding linkage issues and compile settings to support the DLL. 3. Can share a library between incompatible languages (bridge Delphi<->C++<->VB etc) Cons ==== 1. VERY tricky to handle passing of class objects between DLL and client app 2. Requires a well defined interface to ensure client code does not get affected by DLL updates 3. Calling convention issues must be handled wisely 4. Harder to debug from the client-app's point of view Erm.. feel free to add as you find more.
  13. yes, include guards should be in the header. assuming that's what you wanna achieve. but on a second note, no you CANT define a preprocessor within another preprocessor. meaning you cant: #define #ifndef WHATEVER\ #define WHATEVER\ #endif It just wont work.. or at least I neva got it to work :P
  14. CraZeE

    Sprite without glOrtho

    er.. u mentioned 'having them face the camera' but that would require rotation. So how did that work if this other rotation doesn't? anyway, it looks like either a transformation order or transform state problem. Some existing code snippet would be handy to debug though, coz right now its just a random guess.
  15. CraZeE

    Silly visual C++ 2003 problem

    unfortunately, errors are reported by the compiler with a line reference. Since the compiler does not run at realtime, the line info doesnt get updated at realtime. Its a minor annoyance, but you'll get used to it. I don't think it can be fixed (easily) because that would require constant validation of code at runtime, and VS.NEt2003 can be quite slow as it is.
  • 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!