Slick Forums

Discuss the Slick 2D Library
It is currently Sat Dec 16, 2017 4:49 pm

All times are UTC




Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun Mar 11, 2012 11:28 am 
Offline
Regular

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

before many new features are added to the core of Slick I'd like to throw in another idea for discussion.
Slick is currently a rather large collection of utilities and I really double that many use ALL the tools offered by Slick in there project.

My suggestion is to split up Slick into multiple smaller projects. So only the components required have to be included into the different games.

In addition to that I suggest still building a "slick.jar" that contains simply everything. As the target library for projects already finished and as base of development.

For the different smaller Jar files (that should be actually different java projects in the repository) I suggest splitting them into the smallest logical groups.

Such as:
  • slick.jar
    • slick-core.jar
    • slick-gui.jar
    • slick-particles.jar
    • slick-shader.jar
    • slick-tiled.jar
    • ...

The library is getting smaller if you select just the jar files that are really needed (which is perfect for applet and mobile applications). If multiple projects are used its easier to avoid conflicts if multiple developers work at Slick and its easier to create the proper build files.

Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Sun Mar 11, 2012 12:53 pm 
Offline
Game Developer

Joined: Sun Nov 12, 2006 11:18 pm
Posts: 890
Location: Germany
Hi Nitram,
that's exactly what Kevin already suggested and what we developers also talked about somewhere in the development forum IIRC.

I think this is definitely the proper way to go.

_________________
Right Angle Games | Marte Engine
Back to the past | Star Cleaner | SpiderTrap


Top
 Profile  
 
PostPosted: Sun Mar 11, 2012 1:34 pm 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
Totally in for it :A

Should not be a big problem to change the build file to make this work.

_________________
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: Mon Mar 12, 2012 1:54 am 
Just wondering, would it really make a large enough difference in terms of performance? I myself don't see any benefits of this mentioned. Just wondering.


Top
  
 
PostPosted: Mon Mar 12, 2012 3:39 am 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
A few quick benefits:
  • It's good practice
  • It modularizes Slick so that it is no longer a "try to do everything for you" library but rather a "collection of useful utilities."
  • It reduces distribution size if you don't need all aspects of the library -- this is of course important for mobile (Android) and applets
  • My game for example doesn't use tiled maps, pathfinding, Slick-GUI, or Slick particle systems (and, hell, it hardly uses Slick Graphics).
  • Things like slick-gui are mostly for convenience/prototyping as I see it; a "big game" will either have their own UI systems or use something like TWL. The UI in slick is so ugly and inflexible that I don't really think it belongs in slick (sorry kev)... but instead of removing/deprecating the package, it makes more sense to just modularize it (for backwards compatibility, or for beginners to slick, or for prototyping/small projects/etc). That way people like me don't need to include it at all and don't need to worry about yet another TextField conflict. :)
  • A lot of LWJGL developers don't want to reinvent the wheel, but don't want the bloat and complexity of a full-blown game library. That's why slick-util is a popular choice; because it's rather compact and to the point, and let's you jump right into LWJGL without first needing to write image/audio decoders, etc. The same rationale should be applied to the rest of Slick.

Just a note, though. Things like "slick-shader" would be a project of what... a single class? Seems like overkill at that point.


Top
 Profile  
 
PostPosted: Mon Mar 12, 2012 8:43 am 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
Exspecially Slick-Shader deserves a own project.

Currently its just a single class... well 2 if that inner class is moved out as it should be.
But I think later on such a project should contain a set of handy shaders that can be applied to the application without the need of studing the shader language of OpenGL.

I have no problem with very small additional packages. I rather have so then a bloated slick-core.

Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Tue Mar 13, 2012 9:52 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
Sure. As long as the source is all in the same folder, I guess it doesn't matter.

And yes I agree with a set of basic shaders and tests, so you're right about separating it.


Top
 Profile  
 
PostPosted: Wed Mar 14, 2012 8:11 am 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
davedes wrote:
Sure. As long as the source is all in the same folder, I guess it doesn't matter.


I sense conflict potential in this line. :wink:

Let me get this straight. Do you want to:
  1. Have a own project for every single atomic jar, with own, separated source and own build.xml. Along with a additional build.xml to merge the projects into the legacy slick.jar
  2. Have one large project that contains all sources of slick and a jar file that splits the sources up into all the small projects
:?:

Version one would be my method of choice for one simple reason. With this method you can easily check the dependency graph. To avoid that for example the slick-core.jar requires the slick-gui.jar... as this would render the splitting useless. With one large project you have to watch out like made that something like this does not happen.

Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Wed Mar 14, 2012 2:22 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
If we have multiple source folder's then won't we end up repeating a lot of source code?
i.e. the Color and Image class that might be utilized by "core", "gui", and "particles" Or would these projects simply point to other projects?

What you seem to be suggesting is something that looks like this to the end-user:
Code:
Slick
    Slick-core
        src
            org
                newdawn
                    slick
                        blah
    Slick-gui
        src
            org
                newdawn
                    slick
                        blah


And so forth for every project. This is not at all "pretty" and makes browsing source code a PITA (users need to open multiple Finder/Explorer windows for each project). In the long run who will this help? Developers of slick? Or users of slick? Keep in mind that the only reason Slick is still seeing traffic even though there now exists a much more powerful library (LibGDX) is because it's simple and minimal for the end-user to get up and running.

Like I said earlier, I am in favour of modularizing, but I'm hesitant to do it in a way that significantly changes the end-user experience. Though I'll still consider it.


Top
 Profile  
 
PostPosted: Wed Mar 14, 2012 3:21 pm 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
How in the world does this effect the end-user?

End-users are the persons who use Slick to create there applications. Those persons get either the merged Slick.jar that contains all classes in exactly the same way as it is currently.
Or they have many small libraries. How ever on code side there is no difference what so ever between using the full slick.jar or all of the smaller atomic jar files.

For developers I suggest creating separated projects for each of the atomic jar files. Simply because its easier to maintain the dependencies.
For the problem with the repeating of source code. This shouldn't happen. While there are different projects, they still can have dependencies with each other. There is no problem in having every atomic jar requiring the presence of the slick-core.jar. How ever not the other way around. This will be the case for the most projects anyway. Because for example the particle systems simply can't work without the slick-core.

The bad thing is the other way around. If the core of slick requires for example the particle systems for any strange reason. Then separating the particle systems is useless as they need to be present in all projects anyway to get the core running.

And to ensure this is suggest using multiple projects. You can setup Eclipse easily to ensure such a dependency graph.

Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Wed Mar 14, 2012 7:02 pm 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
One project is better. With better I mean better for us. Imho, that all :D

_________________
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: Wed Mar 14, 2012 9:37 pm 
Offline
Regular

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

I understand that the layout must not change for all those who use the compiled library. That is the case in both approaches.

I do not understand why a single project is better for developing. Could you please tell me why?

Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Wed Mar 14, 2012 10:14 pm 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
Crossdepencies will wipe all over you and you have trouble merging different projects to one. It's way easier to use one project (hell we even have already a build.xml, we just copy paste what we need xD Why make the effort to seperate the projects so I have 10 projects in my workspace... Sorry I don't see any good things coming from it). I tend to don't invent the wheel a new just because the technology for it :D

_________________
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 15, 2012 8:44 am 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
Okay I am pretty sure we are talking about entirely different things here.

Lets take as example: slick-core and slick-tiled

slick-core works in the packages org.newdawn.slick[.*]
slick-tiled works in the package org.newdawn.slick.tiled[.*]

Both different projects. slick-core does not require slick-tiled at all. How ever slick-tiled required slick-core to work and is set up to depend on slick-core so it uses the sources of slick-core as well (To avoid writing duplicated code and the requirement to merge anything). If someone ever has the smart idea to use anything from slick-tiled inside slick-core Eclipse will throw error messages as it should be. So corrupting the dependencies basically can't happen if you don't change the project settings. Real cross-dependencies like slick-core requiring slick-tiled and slick-tiled requiring slick-core must not happen anyway. At it screws the entire idea of having separated jars. Components that require each have to be merged into a single project anyway.

And merging the different projects like slick-core and slick-tiled into the slick.jar is way easier then splitting one compiled project into many separated ones as one simple ant command does the job. For splitting you need to use include and exclude filters to get this done. That works for projects that contains just a single package but once you get projects with multiple packages (slick-core) it will get ugly to maintain.

So all in all: I don't get your advantages. :wink:

Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Thu Mar 15, 2012 9:43 am 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
I don't get your advantages too. It's all too... well useless to the user. It's just mor work for us. And I don't see where you could have a problem in copying stuff from the build.xml and change it as we need for the small jars.

Don't get me wrong but you throw a lot of Software Engineering stuff at us (Maven, Mutliple Backend stuff, Splitting a working project into 10 or so, enhance the risk to miss dependencies, mess with people who just want to pull the newiest branch, etc). I can see there is some benefit but you seem to want to table flip all so it matches your style of working. I just don't get why you conentrate so much in giving us MAYBE the chance to work better with the project (I never used any of these neither does any company I worked with) but imho it's more important to make the library itself better. Not giving us more work which the end user doesn't even see... (meaning what davedes does mostly)

I can do a simple question for that: Does anyone have a problem with the project? Does anyone feel the urge to have like 10 projects and skip through them?

_________________
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  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 27 posts ]  Go to page 1, 2  Next

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