I don’t quite see the purpose either ??? How about a simple example on what you can do with it?
Hey! it’s just a code of a week…
The basic idea of this is:
FileSystem.Start ();
FileSystem.fadd (“base/valkyrie.mdl”);
FileSystem.fadd (“base/mytextfile.txt”);
FileSystem.fadd (“base/test.zip”);
FileSystem.fadd (“base/test.tga”);
Filesystem creates nodes with a byte buffer in memory with all the above files (in zip or jar files filesystem will add all the files in the zip or jar file).
As you can see… im a C programmer… xD
I really miss the functions fopen, fread and fclose.
Well… you wanna read 3 bytes of a file?
FileSystem.Start ();
FileSystem.fadd ("base/valkyrie.mdl");
file_t a = FileSystem.fopen ("base/valkyrie.mdl");
if (a == null)
{
return;
}
byte[] a = new byte[3];
byte[0] = FileSystem.fread (a, FileSystem.BYTE);
byte[1] = FileSystem.fread (a, FileSystem.BYTE);
byte[2] = FileSystem.fread (a, FileSystem.BYTE);
FileSystem.fclose (a);
I put FileSystem here to see another alternatives so, if im wrong, please, tell me… im just wanna learn.
(in fact, just point me at the right direction if this is wrong).
Generally you’d just use the classpath as your filesystem. Stick resources in your jars, or in directories in your classpath. Then to do what you’ve just done you could do:
try {
InputStream in = ThisClass.class.getClassLoader().getResourceAsStream("base/valkyrie.mdl");
byte[] data = new byte[3];
in.read(data);
in.close();
} catch (IOException e) {
e.printStackTrace();
}
where the MDL could be in any of the jars or directories in your class path. This helps later when you start using other distribution mediums - like for instance webstart. Also means you can play around with your classpath, put test resources etc in the way of the real ones to try things out.
Though I think most people here would sensibly wrap the classload bits and pieces up in an lightweight utility.
Kev
Though I think most people here would sensibly wrap the classload bits and pieces up in an lightweight utility.
Ye… for me its just InputStream=getInputStream(“foo/bar.ext”); or DataInputStream=getDataInputStream(“foo/bar.ext”);
I also dont need an extra try/catch there. If an exception occurs the module gets stopped and I get some stacktrace in the (quake alike) console. It doesnt really get any simpler than that 
Me also, I consider a runtime error if something can’t be loaded at game time. Hence thats a “stop and complain” rather than an possible exception case.
Kev
If you want to write C code thats fine, but don’t try and write C code in Java.
- Use the classpath
- Loose the statics
- Don’t bring your awkward C naming conventions (file_t, Node_Create, a, tmp) with you.
- Don’t convert exceptions into return codes.
- Your use of dummy parameters to overloaded functions is hideous
- You appear to have a whole bunch of unused variables
- Read this, this and this.
Hey come on OT, go easy, at least this wasn’t spam
Kev
Actually on re-reading that it sounds a little harsher than I intended. :-X
The first link is still very recommended though, it’s a pretty good read.
Well thanks…
Can you explain this points?
Generally it’s a bit overambitious to get into file I/O first thing. You should make some more useless programs and learn object oriented stuff before you can appreciate the design of the Java I/O classes.
About the naming conventions, in java you don’t use names like do_something, you use doSomething. I’m sure the relevant document was linked above.
Sure. For the first one see the link I posted for naming conventions. The main ones to get are that classes start with a capital, method names start with lower case and underscores aren’t used.
-
fadd() catches an exception and converts it into a bool return code. It would be better to simply throw the exception, or catch it and re-throw it as a runtime exception.
-
The syntax of FileSystem.fread(foo, BYTE) is just plain weird. You’re introducing a dummy variable that doesn’t get used just and forcing the caller to do odd things. Why not just try FileSystem.readByte(foo) / readInt(foo) / etc.
-
file_input, data_in and id_counter all seem to be unused.
Hi Kev,
I was just reading your excellent webstart tutorial http://www.cokeandcode.com/webstarthowto where you recommend resources be accessed the following way:
Thread.currentThread().getContextClassLoader().getClassLoader().getResource(“sprites/mySprite.png”);
In the above posts you prescribed this:
ThisClass.class.getClassLoader().getResource(“base/valkyrie.mdl”);
Is the latter equivalent to the first and will both work with JWS’s special class loader you mentioned in the tutorial?
Thanks
Tremendous question. I’m afraid I was being sloppy. The ThisClass.class version is the way we worked out for ourselfs when webstart first started becoming useful for games. However, there was a post that I’ve been unable to find from one of the guys at Sun that recommended the Thread.getContextClassLoader() method.
I think the correct thing to use the getContextClassLoader() version since you may find the class that use to find the ClassLoader may have been loaded in some special way - where as the getContextClassLoader() will return you the class loader that would be used to load classes at the current point in process execution.
I’ve use both ways lots and lots and never had a problem with either. However this is one of the reasons I wrap my resource access up in little static class - if someone eventually decides that one way is better than the other - or a third version comes up thats now the “right thing ™” - then its easy to change
For reference my ResourceLoader wrapper is available as part of my FECK code here:
http://www.cokeandcode.com/code/src/util/org/newdawn/util/ResourceLoader.java
This isn’t for review - just for reference I know lots of people won’t like the System.exit(0) in there - but it works beautifully for my usage
Kev
Thanks
That code’s handy.
getContextClassLoader() is annoying to use because its so verbose but also I’m having to give it absolute names for the resource since I can’t tell where its relative position is like SomeClass.class.getClassLoader().
I’m going to use it in the following way to get around this:
Thread.currentThread().getContextClassLoader().getResource(“mypackage.resources.”+resourceName);
Some people also add a file system fallback to the whole thing for testing purposes. Personally I just sort the classpath out earlier but I thought it was worth noting.
Kev
I’ve got an improved one I keep meaning to post :). So …
Code: http://javagamesfactory.org/sourceformatter/sourcecode/8/ResourceLoader.java
Instructions: http://javagamesfactory.org/views/view-sourcesnippet?id=8
Crikey, I can just about remember that
Kev
Although I won’t comment on the expressivness of OT ( ) I will second and third the recommendation for Thinking in Java. A fantastic read. i bought the physical copy and also keep an electronic ( free as in beer 8) ) copy on my computer and in my PDA.
What’s special about file I/O?
I can see telling someone not to start out with writing their own web server, but writing a program that reads some files is the sort of thing I would want people to start out doing as soon as they’d learned the syntax of the language.
And since he knows C anyways, he might as well do whatever he wants. He hasn’t figured out all the advantages of using Java yet, but that’s to be expected when he’s only been using Java for a week.
What Euroboy should do is read some stuff like the links Orangy Tang posted. I don’t think file I/O is the problem. It’s just “newness” to Java.
[quote]What’s special about file I/O?
I can see telling someone not to start out with writing their own web server, but writing a program that reads some files is the sort of thing I would want people to start out doing as soon as they’d learned the syntax of the language.
And since he knows C anyways, he might as well do whatever he wants. He hasn’t figured out all the advantages of using Java yet, but that’s to be expected when he’s only been using Java for a week.
What Euroboy should do is read some stuff like the links Orangy Tang posted. I don’t think file I/O is the problem. It’s just “newness” to Java.
[/quote]
There’s nothing special about I/O, it’s just that the program above is a non-object oriented wrapper for an object-oriented API. Its primary application is to convert object orientedness to non-object orientedness. This is a logical thing to do when you’re a C programmer, yes, but doing more tutorial-like stuff will show that it isn’t the way to go in Java.