_Silence_

Members
  • Content count

    181
  • Joined

  • Last visited

Community Reputation

986 Good

About _Silence_

  • Rank
    Member

Personal Information

  • Interests
    Programming
  1. Nested namespaces useless typing?

    I guess it depends on your architecture. You can do it without namespaces, the old-school way, with prefixing everything. But if one day you decide to move to namespaces, then whether you'll keep the names with the prefixes and thus have some kind of redundancy, plus obliging the client to type more characters for no real uses (ie like Qt), or whether you'll have to remove the prefixes but then the clients will loose their habits (where is that pref1prefix2Class ?) Or you can do it with namespaces. You can do it the C++ standard way, with only a single prefix (or another nested one for their experimental things). Or you can do it with several namespaces. But then you'll certainly want a main namespace to keep things logically ordered (otherwise the client will wonder if two classes of different namespaces belong to the same project/API or not). And then an issue for the client will be to wonder from which namespace a tool belong to...
  2. I can remember a bit having such kind of issues. Mainly when mixing C/C++ compiling and linking and different versions of compilers (this was threw using Linux and Solaris, not mingw however). Sometimes the linker uses mangling and is looking for a C symbol uses this mangling and thus cannot find it. Sometimes it can do the opposite. I guess that using some #ifdef c_plus_plus and extern C resolved much of this kind of things. You might also try to create a very little and simple test-case, even without any makefiles (just type in the g++ commands and test the various options). You might also try with the shared object instead of the archive of openssl. One last thing that comes to my mind (and I don't know if this is yet the case in mingw), is that gcc 5 changed the ABI, so files generated with gcc 5 are no more compatibles with files generated with previous versions of gcc. These are just thrown things... Hopefully one could help you :-|
  3. Not sure if this is the reason why but you look for the 64 bit versions of the libraries but it seems that you use mingw 32 bits...
  4. Reinventing the wheel

    Indeed
  5. Reinventing the wheel

    Also my two cents: Reinventing the wheel (or the steel) can be helpful to gain some experience. For example, you can use std::list to play with linked lists. You can use std::map to use hash maps. But knowing how these work can be very helpful in (game) programming. If you want to be a 3D programmer and you don't know how a tree works, this will certainly be more of a problem for you than if you did.
  6. .obj file text parsing

    I would personally read 'word' by 'word', letting spaces and newlines be the separators. For the faces, I would simply read an integer, a char, an integer, a char and an integer again, so with something like this: int vert1,vert2,vert3; // face indices char dump; // for the slash ifs >> vert1 >> dump >> vert2 >> dump >> vert3;
  7. Radiometric vs Photometric

    Well... Photometry is about what humans can see. Radiometry is about all rays, whether they are visible or not. So photometry is a subset of radiometry. Commonly, computer graphics is about what we can see, so photometry looks better. However, when moving threw mediums, rays can evolve (they can loose energy for example, but not only...), so a ray that was first not in the visible range can become visible when moving threw mediums. The same kind of logic can be applied to matter that receive energy from various sources, even if all the sources have wavelengths out from the visible range. Nevertheless, real-time CG does not generally care about this: diffraction for example will change the ray direction, polarization will tend to accept or refuse ray from some wavelengths. So this can become very complex. Also, in radiometry you express the flux in watt whereas in photometry you'll express this flux in lumen. But both deal with the same quantities. One is just focusing on human vision whereas the second one cares about everything.
  8. The usual billiard physics will hopefully help you. It can be narrow down to weighted disks easily. I haven't read that link thought. But at first glance it covers what you are looking for.
  9. Agree. A more modernish version of these classes would be just to declare the constructors deleted instead of making them private and having no definition. There, it makes also no interest to put them in a public or private section. Also, note that all inherited classes can inherit in a protected way, thus not perverting the IS-A inheritance idiom.
  10. Put the initialization in the source file, not the header file.
  11. Getter + dirty flag + "mutable"

    OK. But I could not guess that at first glance And at the light of what you revealed, for sure what I said is not a good solution at all.
  12. Getter + dirty flag + "mutable"

    And what about calling doComplexCalculation in doSomethingThatChangesResult ? Since it seems you have access and can modify the original code, it might be less dirty to do so. You will then be able to remove the dirty flag and the necessity to have the mutable qualifier. Which, IMHO, is far better than adding mutable just to add it. The cost is that the complex calculation will have to be done in doSomethingThatChangesResult .
  13. Why 4 if you only draw 2 vertices ?
  14. Something that I saw too. This kind of 'mistake' can show a coding style which does not suit best the user. Sometimes the coding style is not just an aesthetic thing. But it can also be something to help avoid writing mistakes I also put braces at the same line, but for loops and conditions, not for class or function/method definitions.
  15. 3D Mesh data (format)

    Well, according to this, no. Really, I never saw a max importer