How to have different point of views with MultiPassView ?

[Qudus]

@Matthias

You should remove the folloowing from getTexture() as it is already in the constructor. If someone removed all TextureStreamLocators then it’s his own fault:

        if ((tex == null) && ((name.charAt(0) == '/') || (name.charAt(1) == ':'))) {
            // locate the texture directly through its filename
            tex = getTexture(new File(name), format, mipmap);
        }

is bad, because getTexture(File …) addes the texture to the cache.

This behaviour is wanted. EDIT: Read the below post.

[Qudus]

@Matthias

You should remove the folloowing from getTexture() as it is already in the constructor. If someone removed all TextureStreamLocators then it’s his own fault:

        if ((tex == null) && ((name.charAt(0) == '/') || (name.charAt(1) == ':'))) {
            // locate the texture directly through its filename
            tex = getTexture(new File(name), format, mipmap);
        }

is bad, because getTexture(File …) addes the texture to the cache.

I have added a return line so that the getTexture(String…) method returns the tex object if the getTexture(File…) call return a Texture.

@Matthias

You should remove the folloowing from getTexture() as it is already in the constructor. If someone removed all TextureStreamLocators then it’s his own fault:

            if (textureStreamLocators.isEmpty()) {
                // Added for noobs
                addTextureStreamLocator(new TextureStreamLocatorFile(new File(".")));
            }

I have added a better solution. Decided by a boolean flag the “dot” stream locator is added only once. This will result in a bit faster code when the user does add a “good” locator.

@Matthias

The cleanest solution would be to just create a TextureStreamLocatorAbsolute() which contains the above code and add this first (in the constructor) - this will result in much cleaner code without code duplication.

I case of a File as a texture identifyer no locator is needed and would only be time consuming. There is only minimal code duplication. Watch the code there are only about five lines of simple code duplicated.

Well, I’ve changed the noob thing, and I think this version can be committed now.

Qudus

[matthiasmann]

@Qudus

I have added a better solution. Decided by a boolean flag the “dot” stream locator is added only once. This will result in a bit faster code when the user does add a “good” locator.

This results in unpredictable behavior: User has a working program which uses the current directory. Now he adds an additional TSL to read from another source - now the current directly doesn’t work anymore.

Either add it always as the default locator in the constructor - or provide a method to add the current directory - but nothing like a “I have no TSL - I’ll create one” logic. A getXXX should never change the way how getXXX works.

@Qudus

I case of a File as a texture identifyer no locator is needed and would only be time consuming. There is only minimal code duplication. Watch the code there are only about five lines of simple code duplicated.

That’s not where I meaned the TSL. This is ok. But I’m not sure if this function should add to the cache.

[Qudus]

@Matthias

@Qudus

I have added a better solution. Decided by a boolean flag the “dot” stream locator is added only once. This will result in a bit faster code when the user does add a “good” locator.

This results in unpredictable behavior: User has a working program which uses the current directory. Now he adds an additional TSL to read from another source - now the current directly doesn’t work anymore.

Either add it always as the default locator in the constructor - or provide a method to add the current directory - but nothing like a “I have no TSL - I’ll create one” logic. A getXXX should never change the way how getXXX works.

Well, the dot locator is only added for noobs. You shouldn’t use it in general (as I understand this comment [added for noobs]). So we should perhaps delete this dot TSL at all, because if it is always present it will always decrease the performace a little bit. And this just for the noobs out there?

@Matthias

@Qudus

In case of a File as a texture identifyer no locator is needed and would only be time consuming. There is only minimal code duplication. Watch the code there are only about five lines of simple code duplicated.

That’s not where I meaned the TSL. This is ok. But I’m not sure if this function should add to the cache.

Of course it should add to the cache. You can decide to load a texture by File twice as well. So why don’t add it to the cache?