Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  How to have different point of views with MultiPassView ?  (Read 3103 times)
0 Members and 1 Guest are viewing this topic.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Posted 2006-06-28 14:52:17 »

I have a scene (perspective projection) and a HUD (parallel projection).
WHen the camera is at (0, 0, 5) looking at (0, 0, 0) everything's fine although I want to move and rotate my camera but when I do so the HUD also rotates !!

Oh, it's fixed now (fixed is really the word to use here) I just had to do hud.setCameraMode(View.VIEW_FIXED); ^^

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #1 - Posted 2006-06-28 14:57:23 »

Another problem for Qudus : about default images for buttons : It seems that the default texture is loaded but it isn't displayed properly : I see the dummy texture generated by the texture loader when there has been an error loading an image (2x2 checkerboard)

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #2 - Posted 2006-06-28 15:19:16 »

Another problem for Qudus : about default images for buttons : It seems that the default texture is loaded but it isn't displayed properly : I see the dummy texture generated by the texture loader when there has been an error loading an image (2x2 checkerboard)
Fixed. I added the following code to Button :
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
private static boolean hasAddedSlash = false;
   
    private static Texture loadTex(String resource, boolean useAlpha) {
       
       if(!hasAddedSlash) {
          for (File f : File.listRoots()) {
             TextureLoader.getInstance().addTextureStreamLocator(
                    new TextureStreamLocatorFile(f));
         }
          hasAddedSlash = true;
       }
       
        if (!useAlpha) {
            return TextureLoader.getInstance().getTexture(resource, TextureLoader.RGB, true);
        } else {
            return TextureLoader.getInstance().getTexture(resource, TextureLoader.RGBA, true);
        }
    }

Pretty neat, heh ^^

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #3 - Posted 2006-06-28 16:36:01 »

When the TestureLoader does have a problem when roots are not added, so why don't add these lines to the contructor of TextureLoader?

And btw: I still see the default texture on the Button in HUD3DTest.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #4 - Posted 2006-06-28 16:47:10 »

When the TestureLoader does have a problem when roots are not added, so why don't add these lines to the contructor of TextureLoader?
Hmm I'm not sure it's a good idea, but..

And btw: I still see the default texture on the Button in HUD3DTest.
Update your CVS maybe it was badly committed. I see your default_button*.png images correctly.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #5 - Posted 2006-06-28 16:50:14 »

1  
2  
3  
4  
          for (File f : File.listRoots()) {
             TextureLoader.getInstance().addTextureStreamLocator(
                    new TextureStreamLocatorFile(f));
         }


There's a problem (at least) on Windows machines. Yes, I know I shouldn't use Windows as nobody should do  Embarrassed And I will switch back to Linux during the next times. But I had problems with the ATI driver on Linux. Well, I get a little off topic.

The prpblem I'm talking about is, that the floppy is tried to be added and there's a message saying "No floppy in it" when the above lines are executed.
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #6 - Posted 2006-06-28 16:52:46 »

1  
2  
3  
4  
          for (File f : File.listRoots()) {
             TextureLoader.getInstance().addTextureStreamLocator(
                    new TextureStreamLocatorFile(f));
         }


There's a problem (at least) on Windows machines. Yes, I know I shouldn't use Windows as nobody should do  Embarrassed And I will switch back to Linux during the next times. But I had problems with the ATI driver on Linux. Well, I get a little off topic.

The prpblem I'm talking about is, that the floppy is tried to be added and there's a message saying "No floppy in it" when the above lines are executed.
Eheheh I forgive you for using Windows  Wink Wink but heh the workaround is pretty easy.
Add a System.out.println(f.getPath()); so you can identify the paths that get added. Then find out which one is the floppy disk : it should be a: then do a f.getPath.equals("a:") and if it's true then don't add a TextureStreamLocatorFile on this root.

Simple, isn't it ?

On Linux it even simpler : there is only one root, "/".

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #7 - Posted 2006-06-28 17:09:33 »

Add a System.out.println(f.getPath()); so you can identify the paths that get added. Then find out which one is the floppy disk : it should be a: then do a f.getPath.equals("a:") and if it's true then don't add a TextureStreamLocatorFile on this root.

Well, yes. I've already solved this one.

On Linux it even simpler : there is only one root, "/".

Yes, I know. And everybody should really consider using Linux. Regulary I use only Linux, but Windows for gaming.

The other problem with the default textures is still not solved for me. Maybe there really was a committing problem since the DefaultButtonTextureLoader came as an update this morning but there actually wasn't any change. Maybe I've done the same changes that you did.
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #8 - Posted 2006-06-29 00:22:42 »

I've modified TextureLoader to take absolute resource names and load them pypassing the locators. So you won't need to add root folders. So the problem with the default textures for Buttons is solved.

I further suggest to remove TextureStreamLocatorFile and -URL and make the TextureStreamLocator interface being a class with two constructors. One for File and one for URL. There two classes are that similar, we don't need two and can merge them into one like I suggested. Waht do you say?
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #9 - Posted 2006-06-29 15:53:37 »

I've modified TextureLoader to take absolute resource names and load them pypassing the locators. So you won't need to add root folders. So the problem with the default textures for Buttons is solved.
OK.
EDIT : Committed.
I further suggest to remove TextureStreamLocatorFile and -URL and make the TextureStreamLocator interface being a class with two constructors. One for File and one for URL. There two classes are that similar, we don't need two and can merge them into one like I suggested. Waht do you say?
Hmm I don't thinks it's necessary : It's more hassle for users to migrate from one version to another and it has no great benefit : and TextureStreamLocator should stay an interface : maybe there are others class that can implement it.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #10 - Posted 2006-06-29 16:21:53 »

I've modified TextureLoader to take absolute resource names and load them pypassing the locators. So you won't need to add root folders. So the problem with the default textures for Buttons is solved.
OK.
EDIT : Committed.

Thanks. But you actually didn't commit the TextureLoader class, which is most important. Can you please make up for this?
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #11 - Posted 2006-06-29 16:50:53 »

I've modified TextureLoader to take absolute resource names and load them pypassing the locators. So you won't need to add root folders. So the problem with the default textures for Buttons is solved.
OK.
EDIT : Committed.

Thanks. But you actually didn't commit the TextureLoader class, which is most important. Can you please make up for this?
I thought I did. Please check again, I re/cut/paste/committed it.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #12 - Posted 2006-06-29 16:54:22 »

Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #13 - Posted 2006-06-29 21:35:25 »

Why did you add this absolute file handling inside the getTexture() method - and not add a TextureStreamLocator that  is absolute path aware ?

That's the reason why there are so many interfaces

Ciao Matthias Mann
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #14 - Posted 2006-06-29 22:15:02 »

Why did you add this absolute file handling inside the getTexture() method - and not add a TextureStreamLocator that  is absolute path aware ?

That's the reason why there are so many interfaces

If you already have an absolute filename, you won't need a locator. We are loading some textures by <.class.getResource(".....")> which returns an absolute path. So we had to the root filesystem folder (linux: /; windows: all drives, except removables), which is not good and even not high-performance. So this should be a good solution for this case.
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #15 - Posted 2006-06-29 22:18:47 »

But this pushes me into an idea:

If we added a new getTexture method to the TextureLoader which takes a File instance, we wouldn't need a locator for this method and it would be a little faster.
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #16 - Posted 2006-06-30 03:47:49 »

I've coded my last thoughts. Can you please (again) commit it to the core?
Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #17 - Posted 2006-06-30 15:20:44 »

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:
1  
2  
3  
4  
            if (textureStreamLocators.isEmpty()) {
                // Added for noobs
               addTextureStreamLocator(new TextureStreamLocatorFile(new File(".")));
            }



also this:
1  
2  
3  
4  
        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.

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.

Ciao Matthias Mann
Offline Amos Wenger

Senior Member




Everything's possible, but not everything's fun...


« Reply #18 - Posted 2006-06-30 16:49:48 »

Qudus, would you provide me code according to Matthias advices ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #19 - Posted 2006-06-30 16:55:26 »

Qudus, would you provide me code according to Matthias advices ?

I will do it in half time break of the game.
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #20 - Posted 2006-06-30 17:47:35 »

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:
1  
2  
3  
4  
        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.
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #21 - Posted 2006-06-30 18:18:22 »

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:
1  
2  
3  
4  
        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.

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:
1  
2  
3  
4  
            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.

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
Offline Matthias

Senior Member


Medals: 3
Projects: 1


TWL - Themable Widget Library


« Reply #22 - Posted 2006-06-30 21:41:48 »

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.

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.
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #23 - Posted 2006-06-30 21:51:20 »

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?

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?
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (11 views)
2014-07-29 18:09:19

Riven (8 views)
2014-07-29 18:08:52

Dwinin (9 views)
2014-07-29 10:59:34

E.R. Fleming (25 views)
2014-07-29 03:07:13

E.R. Fleming (10 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (27 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!