Slick Forums

Discuss the Slick 2D Library
It is currently Fri Nov 17, 2017 7:03 pm

All times are UTC




Post new topic Reply to topic  [ 27 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Thu Mar 15, 2012 10:00 am 
I agree with @R.D. The only advantage I see here is allowing other devs to use just specific parts of the library. However this isn't really a necessity either. The size of Slick is incredibly minimal compared to other libraries. Organisation of components is not a priority on my list


Top
  
 
PostPosted: Thu Mar 15, 2012 11:29 am 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
Hey, no offence. I am just proposing things I had to learn the hard way.

My project was originally one large project as well. Containing multiple applications as well as shared code that were at the end split into multiple jar filed for the different applications. The problem that happened very often was that parts of the game client used parts of the map editor (all thanks to the dependency resolution of Eclipse -.-). Within the development environment everything worked just fine as all the sources were available. Also the ANT buildscript did not took notice of this problem as the entire project was compiled and after this the compiled binary files were split into the jar files. No errors, all cool. But once the application was started those nice "java.lang.ClassNotFoundException" came down on me. In the end I split the project into multiple projects that had a clear dependency structure. And since then: no more problems.

My sole intention was to avoid that just the same thing happens here.

Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Thu Mar 15, 2012 4:49 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
liamzebedee wrote:
I agree with @R.D. The only advantage I see here is allowing other devs to use just specific parts of the library. However this isn't really a necessity either. The size of Slick is incredibly minimal compared to other libraries. Organisation of components is not a priority on my list

Slick should still be modularized for the reasons I gave earlier. Especially for the sake of slick-util.jar, which IMO is going to be the future of Slick now that LibGDX supports HTML 5 rendering.

I'm starting to agree that multiple projects might be the best way. It may introduce more "clutter" in the sense of a fragmented folder structure, but it would also clearly separate sources. And if users wanted to pull slick-shader (for example, a LWJGL user) then they don't need to pull all of the other junk with it.

Of course, this means that things like slick-gui and slick-particle would not be very useful to the straight LWJGL developer, as they would also need to depend on slick-core. These packages would be more useful for removing clutter for those depending more heavily on Slick.

In the end, I feel that our priority at the moment should lie in fixing bugs and RFEs that have been gathering dust in the BUG/RFE forum, and improving features of Slick that are severely lacking. I would like to "re-introduce" Slick as a modularized set of utilities to the LWJGL community, as it would be useful for many of them, but we shouldn't do such a thing until Slick is a bit more stable, optimized, feature-complete, etc.


Top
 Profile  
 
PostPosted: Wed Mar 21, 2012 8:25 am 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
It's true the it would be nice for the user when he just want's a specific part of Slick. I still think it's a bad idea ( how does it works with SlickAE since it references Slick and so on) but I would suggest making a new branch where this stuff could be tested.

_________________
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 21, 2012 9:51 am 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
Slick-AE is implemented in exactly the way I suggested.
The eclipse project "knows" about the dependency between Slick-AE and Slick and makes all compiled sources of Slick available to Slick-AE during the development. (There is no need to implement sources twice or anything like this).

And to avoid running into more missunderstandings I will split slick into some atomic projects in my fork in bitbucket. If its still rejected then... so be it, we just don't pull it into the main repository when. But at least we are all talking about the same thing then.

Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Fri Mar 23, 2012 9:36 pm 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
Okay. I extracted two sub-projects from the main slick project.

Namely SVG and Pathfinding.

To be seen in my repository fork here: https://bitbucket.org/Nitram0815/slick/overview

I created the required Eclipse project files along with the build files.
The current result is that the slick-pathfinding.jar and slick-svg.jar contain only the parts the names suggest. Slick.jar still contains everything as I extended the normal building progress with merging both atomic-jars into the main slick.jar (for backward compatibility). That does not sound that useful now, but that is only because slick-core.jar is not yet extracted.

As I pointed out that is a example how I would picture the atomic structure of Slick to be designed. The other sub-projects still need to be extracted and the building progress can be done nicer as well. But I did not want to do all that work for nothing in case it gets rejected.

The advantages I see in such a structure were named by now often enough.

So... what do you think?
Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Tue Mar 27, 2012 5:35 pm 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
Anyone and thoughts about this?

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Tue Mar 27, 2012 5:54 pm 
Offline
Slick Zombie

Joined: Sat Jan 27, 2007 7:10 pm
Posts: 1482
My suggestion:
Let's wait until we merge the the development branch with the main branch (we can do that in the next couple days?).

After the merge, we can introduce modularization / atomic projects -- and that way we will have a month to tinker and get comfortable with it before merging again.


Top
 Profile  
 
PostPosted: Tue Mar 27, 2012 6:07 pm 
Offline
Regular

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
The point is rather:

Are you okay with doing it the way I created it as example? Or should it be done differently?
Its just about the general concept.

Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Wed Mar 28, 2012 8:04 am 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
I can't see the canges :/

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

Joined: Sun Oct 30, 2011 4:47 pm
Posts: 184
Location: Mittweida, Saxony, Germany
Yeah because bitbucket+mercurial is a pain in the ass if it comes to a complex version history tree.

https://bitbucket.org/Nitram0815/slick/changeset/f5294d7ec27e
This is the commit that contains the changes. Best use "get source" to download a snapshot of the repository with this version.

Nitram

_________________
http://illarion.org


Top
 Profile  
 
PostPosted: Wed Mar 28, 2012 9:33 am 
Offline
Game Developer
User avatar

Joined: Thu Mar 03, 2011 6:22 pm
Posts: 534
Ah thanks, I will look into ;)

_________________
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 Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


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:  
Powered by phpBB® Forum Software © phpBB Group