I would like to use the Sync class to maintain framerates in different threads, but at the moment it is not possible because the class is designed for a singly-threaded environment.
I suggest adding "public static long sync ( int fps , long nextFrame )" that will use the passed-in value for nextFrame instead of the static one, and will return the calculated nextFrame instead of updating the static value. This would leave existing uses of sync(fps) untouched while being able to add uses of sync(fps,nextFrame) alongside.
Since sleepDurations and yieldDurations are not thread-safe, they would have to be synchronized somehow, but it's in my mind that this would be fine, because (as far as I know) only contested synchronization in Java is particularly expensive, if multiple threads all need to sleep, time must be wasted anyway, and if the game is running slowly in the first place, it should do very little anyway.
(There still does seem to be the case that, when nextFrame is already reached when sync() is called, it still would synchronize in order to check "(nextFrame - t0) > sleepDurations.avg()". Perhaps add a check at the beginning, "(nextFrame - t0) > 0"? This would skip the entire function call in the event the game is running slowly, and if the game is running quickly, it will need to waste time anyway, so no loss.)
This is not really specific to LWJGL, and shouldn't really be in the main library for that reason. Why not roll your own library class to do this?
Not specific to LWJGL? The Sync class is part of LWJGL and this is a very minor extension of that existing class. It doesn't even add functionality: It just adds a multi-thread version of an existing single-thread method.
It is not specific to LWJGL because management of external threads isn't really part of the focus of the library.
I understand that you would want to utilize steady sleeping in threads, it's a potentially useful feature. But again, the best way of doing this is not to put it into LWJGL.
Consider this from another angle - could you only want to use the given functionality in a LWJGL-related context? No, it has other potential uses. Additionally, does the desired functionality directly interact with other LWJGL library calls? No, it's standalone in scope and concept.
The only way I can wrap my mind around your logic is if I take your motivation to be that you design the LWJGL with the intention that people create singly-threaded games, and if they want to go beyond that, they have moved beyond the scope of the library and are on their own.
If that's what you mean, then that's your choice, but I think it's a bit silly. You say "[...] steady sleeping in threads [is] a potentially useful feature [but] the best way of doing this is not to put it into LWJGL", but...it is in LWJGL: It's right there, Sync.sync(fps). Steady sleeping of a thread clearly is within the scope of the library, unless you have deprecated the Sync class and intend to remove it in the future, or at the least fork it out into some sort of plugin or helper library.
I'm not trying to be a pain, here: Clearly I can add this myself to my own project, just by editing the Sync class and recompiling. That's a benefit to open-source software. If you simply don't have the time to spare to put it into the library, then hey, just say so, and a patch file will be forthcoming: Community contribution is also a benefit to open-source software. But if you say you just don't want it...I don't get it.
Quote from: jakj on November 02, 2012, 06:35:55
The only way I can wrap my mind around your logic is if I take your motivation to be that you design the LWJGL with the intention that people create singly-threaded games, and if they want to go beyond that, they have moved beyond the scope of the library and are on their own.
Actually that is exactly the logic. LWJGL is supposed to be the bare minimum to make a game; just enough on top of an OpenGL/OpenAL/JInput binding to manage a simple window context. All the extra cruft that has floated along with it over the years is just more stuff that needs to be maintained and might not work quite in the way you want it to work (like, right here). We want to get rid of all this crap. Sync classes etc. belong in higher level libraries like libgdx and Slick and JMonkeyEngine.
In the meantime if there's code in there you want to use and bend to your will, just copy it and tweak to your hearts desire, but don't expect anyone else to have a use for it. I certainly don't and I've been making games for 10 years in LWJGL.
Cas :)
Alright then, I can accept that you want to pare down the library. I do like the bare-metal nature of the GL access, and I can agree with the philosophy, so long as it's consistent. I'll just do this in my project and leave it at that.
Lots of rumours abound about LWJGL 3.0 but one thing that I hope will be 3.0 is that we get rid of all the crappy broken utility classes :)
Cas :)
Yes, I did see mention somewhere (if I'm not imagining it) that the Matrix and Vector classes were on their way to deprecation, so I've just been avoiding them.
Part of me does kind of feel iffy about a library becoming less and less diverse, but when I really sit down and think on it, it is just a parallel of OpenGL itself, which has been removing crap with every release and just letting the programmer do what they want.
GL has improved vastly since 3 came out, in my opinion, because people are being forced to really think about what they do instead of just pushing and popping everywhere. I admit: I had horrible nests of that myself, and now that I'm having to actually manage my own matrices and upload them to my own shaders, I've collapsed my entire system of matrix usage to a bare three tiers and a lot of caching, and overall it feels awesome.
So, once my knee-jerk reaction is over, I'd just like to say I agree.
Also, I had no idea you made Revenge Of The Titans (just noticed your signature), and I must say, though I don't like that genre of game, I do really like that game specifically, from seeing TB's video on it. If you made that using LWJGL, I feel confident I've made the right choice of library for my own project.
We are the masters of the cheapass effect :) Nothing much fancy going on there but it is indeed LWJGL under the hood giving us the horsepower.
Cas :)