You could still post about it here… I think he’s just suggesting that the code be put somewhere other than in forum code blocks.
@t0neg0d said:
Not sure how this was meant :( But no happy feeling are surfacing atm
Lol, sorry, I meant that as a compliment. You've made a great resource that'll provide game developers with a very easy way to create impressive visuals.
(...) Some of the code I've posted here has prompted changes to core that wouldn't have been considered otherwise (...)
I don't know if I get exactly what you are saying. Do you think those changes would not have been considered if you immediately went the plugin route and just made it work?
@pspeed said:
You could still post about it here... I think he's just suggesting that the code be put somewhere other than in forum code blocks.
Yes, that is exactly what I'm saying. If the "process" that t0neg0d described is the norm, then yeah, we should take a good hard look at our development conventions. But I think that's a different conversation from plugins. You could make a plugin for your contributions and still post your code and design challenges just the same. The point of the plugin is safe-keeping and future-proofing your code by keeping it "closer to core". If anything, it'll just make your case stronger.
Sorry for the delay in responding… for some reason, my husband and kids feel that food is necessary to stay alive. 
@erlend_sh said:
Lol, sorry, I meant that as a compliment. You've made a great resource that'll provide game developers with a very easy way to create impressive visuals.
Sorry for taking offense to the reference to the mmo plugin... I wasn't sure how to take it after reading the second part.
@erlend_sh said:
I don't know if I get exactly what you are saying. Do you think those changes would not have been considered if you immediately went the plugin route and just made it work?
Unfortunately, without feedback from other, yes. I don't think they are considered because it is sometimes impossible to explain the reason why I think they are necessary without a working example reason as to why they would be helpful/necessary/useful/etc.
@erlend_sh said:
Yes, that is exactly what I'm saying. If the "process" that t0neg0d described is the norm, then yeah, we should take a good hard look at our development conventions.
I'm not trying to be mean by mentioning this, but in many cases, it seems decisions are made based solely on ego, not what is best for the SDK and it's users. I'll site two examples that come to mind...
@zarch 's ImageEditor - he was actually told that it was outside the scope of JME. Less than two weeks later a rewrite of his work (that performed worse than his) was added to core, crediting someone other than him for the work. This was COMPLETELY ego-based, not what was best for the SDK.
My SSAO filter - It uses nothing past OpenGL 1, it performs 2x as well as the current SSAO filter and produces results that are more accurate (at least look better) then JME's current SSAO. I set it up to be like the BasicShadow renderer... a simple option for users who can't use JME's SSAO due to the fact that it is a resource pig that can up to half your frame rate for visual results that don't really look good (no offense intended here... nehon's work is close to godliness, and something I strive towards achieving). However, instead of considering adding mine as a Basic version of SSAO... it is going to be picked through for ideas to fix the current.
My problem with this is the following... Many times, things are developed with "using the latest techniques" as the driving force, not what produces the best visual results... which when it comes right down to it... is ALL that matters.
@erlend_sh said:
But I think that's a different conversation from plugins. You could make a plugin for your contributions and still post your code and design challenges just the same. The point of the plugin is safe-keeping and future-proofing your code by keeping it "closer to core". If anything, it'll just make your case stronger.
Knowing that I can continue to post code here, I'll make sure I post to both from now on.
The issue with zarch wasn’t based on ego. The end solution tried to solve a subset of the problem that the engine actually has… lack of consistent way of getting/setting pixels. zarch’s cool classes were much broader in scope since they start to enter the realm of reimplementing Java2D for textures… which is something that was decided against a long time ago and just not well communicated in this case. This leaves aside the idiomatic issues since I don’t like either solution on that basis.
Regarding everything else, if these were standard plug-ins in addition to being posted here then users could try them out simply by installing them through the SDK. Even I might have tried it out in that case. (As a rule it’s 1000x times as much trouble to cut and paste 90 files from a forum post than it is to check a box and hit update.) Then it doesn’t matter if they are in core… people will use them if they are good. I think about 50% of the stuff that already is in “core” should have been plug-ins but I’m kind of in the minority on that one.
Make plug-ins so the stuff is easy to use. Post here so we know about the goodness, can see sample code, etc… Best of all worlds.
Just a side-line thought:
Has anyone bothered to pole the current user-base to find out what feature are not being used and why? You have a captured audience here, who would be more than willing to shared this information with you. This would allow the core developers to create a check list of features that a) suck b) are unusable do to performance issues c) Are useless to begin with but hey, cool! We have um anyways. This check list should be used to narrow down what in core needs to be changed and why.
Why this isn’t being done is beyond me… most software companies would DIE for this type of guaranteed feedback.
As an aside: we get some of this information indirectly by seeing where the more developed game projects struggle. A lot of times the deficiencies are widely known but no one has the time to implement them… core devs or otherwise. Or when they are implemented they are so specific that it takes as much work to make them general as it does to implement from scratch.
Blasting out a broadly worded request for feedback is sometimes a double-edged sword. Every suggestion not taken is a person potentially ticked off that otherwise wouldn’t have been. Also, given that the majority of JME users are just starting out, the quality of suggestions will vary greatly.
@pspeed said:
The issue with zarch wasn't based on ego. The end solution tried to solve a subset of the problem that the engine actually has... lack of consistent way of getting/setting pixels. zarch's cool classes were much broader in scope since they start to enter the realm of reimplementing Java2D for textures... which is something that was decided against a long time ago and just not well communicated in this case. This leaves aside the idiomatic issues since I don't like either solution on that basis.
Another approach that would have not stepped on the guy:
Hey @zarch ... the current version of this is beyond the scope of JME, however it contains elements that we are adding to core. Is it possible to pair this back to x, y... or should we just completely rewrite this? But to say... this is outside the scope and then not even wait for the dust to settle before rewriting it?
I still completely believe the decision to write a class that paired this back to what was acceptable for core without using his code (I'm betting that the class added to core doesn't credit his work towards this) was
a) ego-driven
b) a waste of time and resources if existing code could have been leveraged (even worse if the person who wrote that code was willing to change it to spec).
@pspeed said:
I think about 50% of the stuff that already is in "core" should have been plug-ins but I'm kind of in the minority on that one.
I understand your reasoning behind this completely... but in it's current state, it is not the case. And maybe this is why most contributions are not considered.
Only one of my classes was broader - and that was clearly separated from the core implementation of get/set which was self-contained in the first one. 
I don’t know whether it was arrogance, ego, or just a desire to avoid arguments but a lot of the mistakes in the second one could have been avoided had the person involved bothered to talk to me instead of ignoring me… I’m not interested in reopening old arguments though… except to say that I have at least three things that I think would be generally useful to people to contribute and I haven’t bothered wasting my time to clean them up and present them. I’ve got better things to do with my time than have it thrown away and it’s not even like getting prior approval is any guarantee…
Oh… back to the topic at hand. I’m almost done with a lens-flare post filter that was inspired by making this look more “real”. It’s pretty twisted looking. I’ll probably add a the ability to reference the user’s… um… light dispersion? is it called? To update the direction based on all of the above.
To make the lens flare work, I’ll have to add a texture for the sun… swap this and the moon out depending on time of day. But the over-all effect is looking awesome so far.
(As a side note as far as I’ve seen the new version doesn’t use any of my code (it’s a full rewrite) so I would have been surprised to see myself credited anyway)
@zarch said:
Only one of my classes was broader - and that was clearly separated from the core implementation of get/set which was self-contained in the first one. ;) I don't know whether it was arrogance, ego, or just a desire to avoid arguments but a lot of the mistakes in the second one could have been avoided had the person involved bothered to talk to me instead of ignoring me... I'm not interested in reopening old arguments though... except to say that I have at least three things that I think would be generally useful to people to contribute and I haven't bothered wasting my time to clean them up and present them. I've got better things to do with my time than have it thrown away and it's not even like getting prior approval is any guarantee...
This is why I was saying that decisions are made without the SDK and it's USERS being the focus. I'm missing out on his work because he is 99.9% sure his work will be disregarded based on the way things are handled currently.
@zarch said:
(As a side note as far as I've seen the new version doesn't use any of my code (it's a full rewrite) so I would have been surprised to see myself credited anyway)
Why I said the rewrite was a complete waste of time a resources. This code should have been leveraged if nothing else. Even better, your time and knowledge on the subject should have been leveraged.
Ironically film makers and photographers go to great lengths to get rid of lens flare - only to then see games programmers putting huge effort into making it appear in virtual environments 
@zarch said:
Ironically film makers and photographers go to great lengths to get rid of lens flare - only to then see games programmers putting huge effort into making it appear in virtual environments :D
That's very funny... It is such a cool looking effect.
@t0neg0d said:
Why I said the rewrite was a complete waste of time a resources. This code should have been leveraged if nothing else.
I agree, and made this point quite vehemently at the time. It would have taken me two hours (including testing) to make the changes to break out ImageRaster into a separate class instead of being built into Image (and ImagePainter could have been a stand alone thing, or plugin library, or whatever). Instead the full rewrite was done which took several weeks real time (I've no idea how much actual programmer time but it wasn't a trivial job).
Having said that - the two approaches were and are pretty incompatible so once the decision was taken to make the change not much of my code was re-usable.
Actually this has reminded me, I need to schedule some time (hopefully next week) to look at the more recent changes to and performance of ImageRaster. I'm hoping it's good enough now that I can move ImagePainter over to it and get rid of my patches. In his most recent reply the developer in question has resorted to "well performance doesn't matter anyway" though so I'm not exactly overflowing with optimism...
1 Like
More food for thought…
I know that this implementation of a sky would never be considered for core as an alternative to the SkyBox class. Though, why it wouldn’t be at least considered is BEYOND me… environment maps are a HUGE pain in the ass to create (even using an existing tool) and the final visual effect simply sucks. It’s static and ugly. But, it’s a known way of rendering skies /shrug.
I guess my point is, if the final visual effect sucks… I think the underlying reason for even having it as part of the SDK was the WRONG reason. Great, I can have a sky box… it looks like shit… but why would I care what my game looks like… I have a sky box!
This is just an example of why I was saying that some of the decisions for filters, controls (visual based), shaders and the like are based more off of “Did I implement the latest technique?”, not “Does the final output look as good as it could?”, or “Huh… would I actually use this if I was writing a game?”
@zarch said:
I'm not interested in reopening old arguments though... except to say that I have at least three things that I think would be generally useful to people to contribute and I haven't bothered wasting my time to clean them up and present them. I've got better things to do with my time than have it thrown away and it's not even like getting prior approval is any guarantee...
(sigh) this is kind of my point with the whole too much crap in core thing. It's like something is only useful if it is downloaded by default with the SDK... which is a shame since there could be 100 useful plug-ins just a click away. I think we stifle the ecosystem by including everything and the kitchen sink.
A few things I can say with certainty:
1) I (personally) will never (or rarely ever) add things to core that I can't test myself.
2) Whether I (personally) get to test something myself is directly related to how much time it takes me to try it out.
3) In order of easiest to least easiest: plug-in, external source repo, random code blocks in a forum post.
I'm a reader of the forum and not a compiler... I still spot a lot of stuff in forum posted code, though.
1 Like
@t0neg0d said:
More food for thought...
I know that this implementation of a sky would never be considered for core as an alternative to the SkyBox class. Though, why it wouldn't be at least considered is BEYOND me... environment maps are a HUGE pain in the ass to create (even using an existing tool) and the final visual effect simply sucks. It's static and ugly. But, it's a known way of rendering skies /shrug.
I guess my point is, if the final visual effect sucks... I think the underlying reason for even having it as part of the SDK was the WRONG reason. Great, I can have a sky box... it looks like shit... but why would I care what my game looks like... I have a sky box!
This is just an example of why I was saying that some of the decisions for filters, controls (visual based), shaders and the like are based more off of "Did I implement the latest technique?", not "Does the final output look as good as it could?", or "Huh... would I actually use this if I was writing a game?"
Why would you not make it a plug-in? Then everyone can use it regardless of what the petty egotistical gate keepers think of it. ;)
Even better, you get testers, potential updates, retesting, etc... and then it's five seconds to put it in core if everyone is using it.
You speak a lot about feedback but you are ignoring one of the most critical ways to get feedback: putting working code in a widely accessible format.
Indeed, and only the get/set pixel really needed to be in the core (I never had a problem with ImagePainter not going in the core and said so repeatedly - although no-one ever answered my question as to where would be a good place to put it so people could access it conveniently if they needed it). Of the other things I have two wouldn’t need to be in core at all (one definitely shouldn’t be, one maybe would be useful but could go either way) and I can’t even remember what the third was.
Having had a contribution kicked in my face in the past though makes me unwilling to spend time on future contributions of any kind. Whether core or not. It’s an emotive response not a logical one, and I’ll most likely change my mind about it at some point (probably when I write something that’s really easy to contribute - the existing ones would all need quite a few hours to clean up and document), but we’re all human.
@zarch said:
Indeed, and only the get/set pixel really needed to be in the core (I never had a problem with ImagePainter not going in the core and said so repeatedly - although no-one ever answered my question as to where would be a good place to put it so people could access it conveniently if they needed it). Of the other things I have two wouldn't need to be in core at all (one definitely shouldn't be, one maybe would be useful but could go either way) and I can't even remember what the third was.
Having had a contribution kicked in my face in the past though makes me unwilling to spend time on future contributions of any kind. Whether core or not. It's an emotive response not a logical one, and I'll most likely change my mind about it at some point (probably when I write something that's really easy to contribute - the existing ones would all need quite a few hours to clean up and document), but we're all human.
Indeed. I hope you don't let the one incident taint your opinion for too long. Many of us (core devs included) respect and value the contributions you make, code and otherwise... regardless of one colossal miscommunication.