10-11-2022, 01:22 PM
To answer this, one has to ask, "What features are being developed in QB64pe? Are those features unwanted or something that won't be used?"
Let's look back at what we've added here recently:
A new build process, which allows the end user to choose which flags and optimizations they want to use with qb64pe. There's a dozen posts concerning this change, and it's one of the most interacted topics on the forums, so I'd say it's safe to say that people are interested and using the c++ optimization flags.
There's the new work which has been done on the image library front. We now load images faster, as well as support more image formats than before. The vast majority of users end up making use of images with their programs, so this isn't an unwanted or unused change.
Same thing with the sound library. We've gotten rid of the LGPL licensing requirements, which were a large concern to many people, as well as expanding and enhancing our sound routines. Back at last Christmas, I ran into an issue with loading multiple X-mas songs into my little game program, due to the time it required to load them all. 20 songs took almost a full minute to load... Now, those same 20 songs can be loaded and ready for use in around a second. That's a HUGE change -- and something which I sure as hell am appreciative of, even if no one else ever is.
We've redid the wiki - rebuilt it from scratch almost. Who doesn't use it?
Exactly what have we been pushing into the language that's unwanted or unused? All the changes I've seen in qb64pe are ones which people make use of. There's nothing which has been worked on that's been wasted effort, as far as I can tell.
As far as surveying what features to create, we simply don't work that way. Each developer we have is basically nothing more than a hobbyist who is willing to contribute to changes and adding features which they tend to need in particular with the language. The community could vote and say, "Add array use in UDTs next!!", and sadly -- but honestly -- the devs would just roll their eyes and shrug their shoulders at the suggestion. I wouldn't know where to start to do such a thing. I don't know if any of our other devs know how to tie in to the existing system and make such a change either -- or if they'd be willing to put off their own personal projects/enhancements to jump on such a request.
Truly, if the community started voting on what to develop next, I imagine the dev response would be, "We'd love to see this addressed as well. I wish you the best in luck in finding someone who can address the issue for you, as it's not something which we currently know how to correct."
At the end of the day, we make a lot of changes and correct a lot of glitches in the codebase, but when all is said and done, we're still just trying to maintain and improve somebody else's code -- and poorly documented code at that! For years now, I've been gnawing at the lack of full keyboard support and mismapped/multimapped keystrokes, and I still haven't sorted out how to correct the issue -- and I'm one of those guys who folks point to and say, "Steve's a dev on this project!"
Feel free to suggest anything in the world that you'd like to see us fix, add, or work into the language. Just do so while remembering we're just human, and we may not have any clue in the world to how to do whatever you'd like to see done. We're still learning as we go along everyday with the project.
Let's look back at what we've added here recently:
A new build process, which allows the end user to choose which flags and optimizations they want to use with qb64pe. There's a dozen posts concerning this change, and it's one of the most interacted topics on the forums, so I'd say it's safe to say that people are interested and using the c++ optimization flags.
There's the new work which has been done on the image library front. We now load images faster, as well as support more image formats than before. The vast majority of users end up making use of images with their programs, so this isn't an unwanted or unused change.
Same thing with the sound library. We've gotten rid of the LGPL licensing requirements, which were a large concern to many people, as well as expanding and enhancing our sound routines. Back at last Christmas, I ran into an issue with loading multiple X-mas songs into my little game program, due to the time it required to load them all. 20 songs took almost a full minute to load... Now, those same 20 songs can be loaded and ready for use in around a second. That's a HUGE change -- and something which I sure as hell am appreciative of, even if no one else ever is.
We've redid the wiki - rebuilt it from scratch almost. Who doesn't use it?
Exactly what have we been pushing into the language that's unwanted or unused? All the changes I've seen in qb64pe are ones which people make use of. There's nothing which has been worked on that's been wasted effort, as far as I can tell.
As far as surveying what features to create, we simply don't work that way. Each developer we have is basically nothing more than a hobbyist who is willing to contribute to changes and adding features which they tend to need in particular with the language. The community could vote and say, "Add array use in UDTs next!!", and sadly -- but honestly -- the devs would just roll their eyes and shrug their shoulders at the suggestion. I wouldn't know where to start to do such a thing. I don't know if any of our other devs know how to tie in to the existing system and make such a change either -- or if they'd be willing to put off their own personal projects/enhancements to jump on such a request.
Truly, if the community started voting on what to develop next, I imagine the dev response would be, "We'd love to see this addressed as well. I wish you the best in luck in finding someone who can address the issue for you, as it's not something which we currently know how to correct."
At the end of the day, we make a lot of changes and correct a lot of glitches in the codebase, but when all is said and done, we're still just trying to maintain and improve somebody else's code -- and poorly documented code at that! For years now, I've been gnawing at the lack of full keyboard support and mismapped/multimapped keystrokes, and I still haven't sorted out how to correct the issue -- and I'm one of those guys who folks point to and say, "Steve's a dev on this project!"
Feel free to suggest anything in the world that you'd like to see us fix, add, or work into the language. Just do so while remembering we're just human, and we may not have any clue in the world to how to do whatever you'd like to see done. We're still learning as we go along everyday with the project.