Slick Forums

Discuss the Slick 2D Library
It is currently Sat Feb 23, 2019 12:59 am

All times are UTC




Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
PostPosted: Thu Mar 29, 2012 6:13 pm 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
Yepp, as said it's quite amazing speed increase. I was jsut saying I don't care that much about it xD ( I'm too used to long loading times from all the current AAA Games x_X) Of course we want to give the user the most speed we can give them :) That's why I suggested implementing the code into the classes. Or we trim down the IOUtils class (We could start by trimming down the documentation a bit. remove redudance and removing methods which will "probably" never used and if we add them :)).

Edit:
And why is Nitram no a developer :o Nitram if it is okay, we trim the class a bit to the needs (if we can settle on the ones we need) and then add it :) I really don't want to break anythin in bitbucket xD

_________________
Current Projects:
Image Mr. Hat I
Image Vegan Vs. Zombies
Projects:
RadicalFish Engine - Build on top of Slick2D, Ideas, Bugs? Open an Issue ticket!


Top
 Profile  
 
PostPosted: Thu Mar 29, 2012 6:27 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
I don't think we need to trim down documentation... That's not what I'm referring to when I talk about "bloating" a library. ;)


Top
 Profile  
 
PostPosted: Fri Mar 30, 2012 9:16 am 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
Okay,

Please allow me to "defend" my implementations.

closeQuietly
Actually I think that is are pretty handy function. After all the proper handling of a input stream looks like this:
Code:
InputStream in = null;
try {
    in = new ...
    /* R/W operations */
} catch (...) {
    /* Error handling */
} finally {
    if (in != null) {
        try {
            in.close();
        } catch (IOException e) {
            // nothing
        }
    }
}


That is the only way to make sure that the created input stream is closed properly. And this always has to be done on the same level where the input stream is created or requested. (excluding methods that clearly create a new input stream to return it). This source code looks pretty bloated, while its correct and required. This was the reason I created this closeQuietly function.

Code:
InputStream in = null;
try {
    in = new ...
    /* R/W operations */
} catch (...) {
    /* Error handling */
} finally {
    IOUtils.closeQuietly(in);
}


Looks better, doesn't it?
This function is not really "needed" or required or anything... but it makes the code easier to read and lowers the inhibition threshold for developers to write the clean code for handling input streams I think. I don't know how it is for you but I always have to force myself to write that block of code I wrote up there. So I think this method makes it easier.

Method overloading... okay that was a little over the top maybe :wink:

But many of the methods are actually used, because they use each other and only the copyLarge functions really transfer the data between the Reader/Writer or the Streams. So most of the functions become "natural" a part of the implementation plainly by following the call structure. After all I guess the most often used "entry" call for the toString() method will the toString(CharSequence[, String]) as it uses Slick ResourceLoader to fetch the resources.

Also the optional "charsetName" parameter I consider as extremely valuable. Some application don't have to care for the charset because the data load contains only characters from the lower 128 characters that are shared between all commonly used charsets. But some (such as myself) require the ability to load data that are charset sensitive. For example the german umlaute (ä, ö, ü).

Surely the amount of implementation can be trimmed down a little. But not to like 2 methods. :wink:

For the readLine methods. Yes they are slower. But I think they have the better design. But a faster method something like a "Iterator" like implementation that scrolls over the buffered data from the file would be needed. Could be done, but I need to do more tests to get something like this working in a fast way. And this was a little too much for a first implementation.

For the StringBuilderWriter... that is a class that is only used by the IOUtils. And its in the same package. If you don't want to expose it to the user... just make it package local. :)

Nitram

Edit: Don't trim my documentation!! Its awesome!

_________________
http://illarion.org


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 63 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group