Actually, this should work better even. I am responding to myself, but someone let me know if you see a problem with this working for all cases. I need to figure out how to include jar file loading as well, without implementing too much junk.

    static public URL loadFile(String filename) {
        URL returl = null;
        try {
            if(KittIO.baseurl != null)
                returl = new URL(KittIO.baseurl + filename);
            else
                returl = new URL(filename);
        } catch(Exception e) {
            try {
                File file = new File(filename);
                if(file.isFile())
                    returl = file.toURI().toURL();
            } catch(Exception ex) {
                ex.printStackTrace();
                returl = null;
            }
        }
        return returl;
    }


But, I'm hoping someone here knows it. I completely forgot as I have not used the technique in a long time, but there's a specific trick to loading a file that could be from either an applet or application and within a jar or not, in other words, loading the file with just the base dir/url and the loader not caring which it is.

I use to have this documented but since I haven't used it in a long time I lost it.  If I remember correctly using new File(filename) doesn't work in all situations.

Looks very...tronish. I like it.

Thank you, that's what I was hoping for. Going to put up the first official version of the library soon, just need to do a tax test on it to see where I need to tweak some things. It's actually turning out better than I had expected, but the game and the library. Thanks to your input, I think I have something that other people may just find useful.

Alright, I got the Blender to Kitt jPCT engine scripts done, here's a scene exported from Blender to the engine.





The beams and the green ground have animated textures, the ground shimmers, the small beams look like blips flying through, and the big one looks freaking cool animated. lol

I know the PC jPCT has not native method, not sure about AE though.

I created a texture sequence class, which holds a list of texture names and textures as well as other information about the animation, then the animation system for the object just "flips" to the next texture after some time has passed based on the sequence settings. Sort of like a movie.

Very pretty. Nice details too.

Slight change in plans, though not massive. I developed a pretty decent 3D GUI system, but the drain on the CPU due to collision checks and such with the mouse have made me choose to change gears a bit. Getting rid of the "picking" with the mouse completely, for the 3D GUI, most games use hotkeys for such things anyway so I'm probably just going too big. I am also going to put more focus on the HUD system, making it into a full GUI which will respond to the mouse. As it is I have to do something that will wind up abusing memory and queuing all the events in order to prevent some serious glitches when working cross threads, Swing's event system demands such and that's sort of the purpose of this library, to merge Swing with the GL rendering.

So to recap:

1. More focus on 2D HUD elements and interactions.
2. Elimination of 3D GUI object "picking."
3. A more refined event queue system.
4. A HUD system that's comprehensive and useful, as well as more GUI capable, that means event bindings and animations for the HUD elements themselves.

For those interested, I managed to iron out the texture system in a way that will actually benefit even small projects. Added a new object, the Scene object, which only tracks things that are unique to that scene allowing you to remove them easier and faster when changing scenes. Considering being rid of the 3D GUI completely, as cool as it looks, I want my library to be capable of operating on lower level machines than modern top of the line, the 2D HUD system can look not only as smooth, but also more like what people are used to for widgets anyway.

If there are any suggestions of ideas, please let me know, also any specific requests. I will hold onto the 3D GUI and maybe develop it further later on, but for now I prefer the 2D one.

Okay, I figured out that either jPCT or OpenGL doesn't like transparent objects. Tons of sorting errors and it eats CPU cycles, on the GL render. Since I'm too lazy to write my own graphics library for OpenGL I'm just going to work with it somehow. Which leads to two things I would like some recommendations on from the dev(s) of jPCT:

1. For texture animations, frame by frame update of the texture, would reassigning the texture each frame be more costly, or would using a TextureEffect and updating the texture's array each frame be more costly, when using jPCT?

2. Would using two worlds cost a lot? I notice that using two worlds versus one then switching visibility on the objects, has almost no difference in CPU cycles eaten, and the two different methods don't seem to have much of a difference in resource consumption from what I can see.

When I say cost I mean memory and CPU consumption. I don't know exactly how you coded the World class, so I'm not sure what it does exactly. Currently with the simple world, and almost no transparent objects, I can pump out 33 FPS with or without the GUI layer on top of it, using either technique. So unless there is a nuance that could kill an app I am considering going with the multiple world "layers."