I want to make a kind of 2D puzzle side-scroller which will use tiles for the map. Do you have any idea on how I could load multiple files like Frame1.txt and Frame2.txt and translate numbers into tiles? Also, how could I make it so when the character wants to go to the next frame, it transitions smoothly?
Reading a file is dead easy:
BufferedReader reader = null;
try {
reader = new BufferedReader(new InputStreamReader(new FileInputStream(new File("Frame1.txt")),"UTF-8"));
int i;
while((i = reader.read()) != -1) {
int num = Integer.parseInt(String.valueOf((char)i));
//now you can play with the number
}
}
catch(Exception exc) {
exc.printStackTrace();
//cleanup appropriately
}
finally {
if(reader != null) {
try {
reader.close();
}
catch(Exception exc) {
//error with flushing/closing the stream
}
}
}
I love to read any thread I can! ra4king, you just answered a weird question I had not so related to OP.
Thank you both 
Fine idiom, but for the love of Bob, please stop catching and ignoring exceptions. I swear checked exceptions cause more damage than they ever prevented.
It’s the freaking close() method! There are only 2 possible exceptions at that point: NullPointerException, caused if an exception was thrown inside the outer try-catch; and IOException, which almost never happens and if it does, it means something happened when flushing the buffer
It’s in the block above the close too. Printing the exception then going on like nothing happened is still ignoring the exception. I know, example code, but I’m seeing everyone do this everywhere because they don’t like being bitched at by the compiler. If you want to defeat checked exceptions, the boilerplate to use instead is this:
except (Exception e) {
throw new RuntimeException(e);
}
FWIW, and I’m sure you already knew this, but you can avoid the possible NPE quite easily by checking the reader for null in your finally block.
} finally {
if (reader!=null) {
try {
reader.close();
} catch (IOException ioe) {
// Logging and error handling of your choice
}
}
}
Don’t you just love how verbose Java can be.
I agree with this for large-scale applications, but for smaller scale games like most folks here are writing, I think a simple printStackTrace() is sufficient in cases like this. A game loading a level data file or whatever is exceedingly unlikely to fail since you package it with your game, meaning you know its exact location and it’s guaranteed to exist. And if somehow the file reading does fail at runtime, you’re going to stare at a stack trace to figure out why, no matter what. Whether that was printed in some deeply nested try/catch block or stopped your main thread via a wrapper runtime exception, your course of action will be the same.
Though if someone’s paying you for your application, and/or it accepts arbitrary input, or has some other reason to be more robust, then you’ll need to be writing some error handling boilerplate.
You could at least print a stack trace, just so we know if this becomes a problem in the future, for whatever reason.
No, it isn’t, not even slightly. What do you think the proper behavior is when the program fails to load a level? Yes, you’re going to get a stack trace sometime, later, but it’ll probably be a NPE, and you’ll have to re-run the program under a debugger to find out why. Printing the exception to stderr is not very useful if the program was launched from a GUI. Your top-level can take care of capturing, logging, and displaying uncaught exceptions and do it in one place.
The language provides structured exceptions for a reason, so we don’t have to write code like C and check for null returns from everything. And you get this feature by writing less boilerplate, not more. So I really don’t see the need to cripple a program’s robustness just because it’s small.
If you did an “e.printStackTrace()”, then the level-loading stack trace would also be printed, before the cascading NPE. The original error is not lost. No need for a debugger. My point was that folks writing small-scale games, the I/O involved in level loading is very unlikely to fail once you get it working the first time. If the data is static, Class.getResource() loads it from a relative location and it “just works.”
Of course, you can log the exception however is appropriate for your deployment scenario.
I’m not arguing to do this all the time, and I’m not arguing to “write code like C” either. I’m just trying to follow the KISS principle. Decide how robust your error handling should be in your game and implement it appropriately.
Alright, well I updated my post
Hmm, a mention of Java 7’s automatic resource cleanup seems appropriate seeing the thread content
http://www.oracle.com/technetwork/articles/java/trywithresources-401775.html
Yup, using Java 7, that huge try-catch block would shrink down to:
try(BufferedReader reader = new BufferedReader(new InputStreamReader(getClass().getClassLoader().getResourceAsStream("Frame1.txt"),"UTF-8"))) {
int i;
while((i = reader.read()) != -1) {
int num = Integer.parseInt(String.valueOf((char)i));
//now you can play with the number
}
}
That looks like what I was going to make a post about!.
I wanted to be able to read a file and say: Ok, if a number is 1 than that means draw a tile.
But… I wanted to know how to detect spaces in the file, also collumn rows, possibly say if there’s a space, that means draw the image at the current x but + the image width, vice versa for a images y for a new line.
For transfering into a new frame/map, try adding a way to pause the game/slow it down and render a nice black fading transparent screen.
switch((char)i) {
case ' ':
//space;
break;
case '1':
//1
break;
//etc....
}
Saves in notepad
Should keep me busy for tonight.
0 0000000000 0
0 1111111111 0
0 2232323220 0
0 2232323220 0
0 1111111111 0
0 0000000000 0
Thank you.