Terrain indeed is the most “complex” code in the SDK, that’s what the static analysis pointed out, mostly because the top component has 2000 LOC, but most of it is just swing/UI.
Don’t overthink this, get a feeling for jme3-terrain first. Adopting to API changes is easy, specifically when doing so step by step instead of 100 changes at once. That is under the assumption the way things like modifyHeight are called is changed and not that such support is dropped. Also note that users have written their custom editors which would suffer as well.
I guess for excellent terrain most changes would be under the hood and to the SDK Editor itself, but not really to the API.
@Darkchaos, I agree with making the changes to the SDK Editor.
Different Topic:
Earlier Today, I moved into core lib to do some cleanup, and I moved the checker.quals to a new com.jme3.detector package. I’m not too sure what else to name it as I don’t know what its for. Why exactly is that package there?
As far as I’ve heard, one has to select 3.2 for Mac support now. So leaving it at 3.2 would allow one to develop for any of the 3 desktop platforms. If Mac supports 2.0, I’ll leave it like it was.
Euhm, it’s apple that decided to deprecate OpenGL and OpenCL from OSX 10.14, not JME.
It’s deprecated, which means it might or might not work, they just don’t support it anymore and want to force developers to embrace Metal.
In JME OpenGL 3.2 is used to give 3.x support to Mac users.
The engine uses by default the compatibility profile. My opinion is that the engine should use by default a more recent core profile, where 3.2 would be probably the most logical choice.
But be aware that this is a drastic change that will have a serious impact.
It is supported, but there are caveats. The same holds true for mobile platforms, too. It should be documented on the wiki - and in my experience - setting a few params is the equivalent of a month off compared to actually writing a game. It’s inconvenient but I mean… I can live with reading a short document if it means supporting an entire platform.
Are we yet to jme-Beta2? I know @pspeed said he would really soon make it Beta2, but I havn’t seen anything new yet besides @danielp’s work yesterday.
Maybe Wednsday or so I’ll submit my PR, but I’d prefer to not have to switch to Beta2 to fix some issues.
I strongly agree with using core profile by default.
Compatibility profile is implementation specific, and unreliable. It is not just a mac thing.
I think the default should be a reasonably old core profile.
Well I’m no expert, so explain what I should do. I’ve as I said earlier in this topic, I’ve fixed a bunch of warnings in Terrain and Core libs and updated license headers.
It’s up to you, but the bigger your PR is the more likely there is one thing wrong that keeps the rest of it from getting merged. It’s better to do things like change the license headers as a separate PR, etc… Changes to jme-core should a be different PR than changes to jme-terrain… because changes to jme-terrain are more likely to get rubber-stamped than jme-core changes… and so on.
If it all comes in as one giant PR then it is less likely to get reviewed, certainly less likely to get reviewed properly, and less likely to get merged without a lot of back and forth.
This bears emphasizing. I’m one of 2 maintainers for a separate project, and the time and effort required to properly review a PR rises exponentially with the extent of the changes.
I can usually review 4-5 tightly focused PRs of 10-25 lines each in an afternoon, give feedback, and if I get responses, be ready to merge them all the next time I look at the project.
If they’re all squished into one PR, it will take me twice that time to even understand what the contributor is trying to do.
(Note: I’m not saying that all changes can or should be that small. They can’t. It’s just that the more focused and concise a PR is, the sooner someone will have the time to consider it deeply enough to move things forward.)
You can’t submit a PR with beta1 fixes. You submit a PR to master and then if we want to port them to 3.3 then we will.
But the ship has sailed for porting things to 3.3 today… regardless of what you do it won’t be in time for a beta2. But it also won’t affect the 3.3 branch at all unless there is a beta3 someday. I’m hoping beta2 is the last one but folks seem to find critical things only after a release… so we’ll see.