Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

Posts posted by mohij

  1. For a game manager that makes sense (since there can only be one), but with a texture manipulator that is a class of which logically any number could exist (with threads even at the same time), that seems strange. To me it sounds quite strange to make classes singletons which logically aren't, just as a speed hack. Or did I misunderstand that?


    Following that thought it means that there is no actual data saved in this class (since the same class can be used in different cases), so the class actually just wraps up functions.

    Wouldn't it then be better to just provide the functions directly? (this doesn't sound object oriented, but why make a class out of something which is really just functions?)


    Please don't feel offended, it just doesn't seem right to me.

  2. But it would be good to know anyways.


    What I know for sure now is that in map expressions the second image is scaled to the size of the first.


    That different dimensions are possible is obvious too, but what I'd find interesting to know is what sets the final size of the texture in game. (whether a texture is "two feet" or "20 feet" high.)


    It seems the resolution has no influence on that. Could it be that by default all textures are the same size?

  3. I did a small test, and it seems to scale the second parameter to the resolution of the first one.


    I also noticed that the resolutions of the images are not responsible for the size of the final result. I guess the diffuse map resolution does set the size finaly. I will test and report results. (so in the end all images in a material file will have the same resolution, I'll just have to find out which one sets this final resolution).

  4. The scale problem could be solved in two ways. Either scale one image to the size of the other (probably the higher resolution image to the lower) or don't scale the images and use the getPixel function, that won't scale the images, but repeat the small image. Both seem logical, so no idea which one is correct.


    Scaling the image would require a scale function (perhaps there already is one in there I don't know of?), writing my own would be quite some work, an alternative would be a hack to divide the different widths and heights and step through the bigger image with a different offset, but that's no nice solution.

  5. My first try would have been to write a normalize function, as I will probably need that one more often. And then simply iterate through the image (I wouldn't even need to differentiate between RGB) add the values together and divide by 2. After that a call to the normalize function would do the trick.

    That is much simpler and the result would be the same, right?


    I'm not 100% sure, normalize means trimming a vertor to a length of 1, right?

    Edit: Wikipedia helped.

  6. I noticed a bug: in GLTextureManager.h line 85

    virtual TexturePtr GLTextureManager::getBinding(const std::string& fullPath, const std::string& moduleNames) = 0;

    the GLTextureManager:: shouldn't be there.


    Small question, is it intended, that you use two different descriptors for the second argument? In ishaders.h and GLTextureManager.h you use "moduleNames" and in GLTextureManager.cpp "fileExt".


    What are you working on next?

    I will continue with the AddNormalsExpression. Some information on what this function (and later on the others too) should actually do would be helpful. The alternative would be trying some implementations and see which one mimics Doom3s implementation best, but that doesn't sound fun...


    Edit: and about the critics, I am very grateful for them, since they really help learning, and that's what I want to do ;-)

  7. The problem is that I changed getBinding to take MapExpressions, so I'm forced to use MapExpressions all the time, even if I just need to realize a path which has nothing to do with a MapExpression.


    I think even better would be to change the GLTextureManager to take such a "bool useFileLoader" instead of a MapExpression. Logicaly that makes more sense too.


    Edit: or even better change the

    GLTextureManager::getBinding(const std::string& filename

    to default to using the FileLoader and just let the caller create the MapExpression.

  8. Yeah, this is the second time MapExpressions fail because they use the DefaultConstructor and not the FileLoader.


    First thing that comes to my mind is overloading the createForToken/createForString functions to take a pseudo argument: "bool useFileLoader=0", but it could be that there is a more elegant way of solving this. But on the other side the question arises if it makes sense to interpret paths as MapExpressions, because in the end a MapExpression was not meant to be a path (that's just a hack to make life easier).

  9. I'm not sure how that could happen. Since we fixed the bug with returning white images instead of ShaderNotFound, it is more logical that a ShaderNotFound is returned, when a call is faulty.

    The relevant line:

    mapExp = IMapExpression::createForString(GlobalRegistry().get("user/paths/bitmapsPath") + IMAGE_BLACK);

  • Create New...