...snip...
In terms of the things listed here - which is all about backward compatibility, I've already stated our reasons. Whether you agree with them or not is irrelevant, we considered a lot of things when doing the product, and backwards compatibility was a major requirement, and as such we had to make certain choices. This will not change. We are not going to put in a runtime switch that would require massive amounts of dev and testing, and would probably slow things down as there would be a low level IF at every step of rendering. BGR is irritating, I agree - but it is not limiting, and that would be the main concern to us.
So agree, or don't. If you read the reasons behind it, and think about the amount of dev work required to have a switch on every rendering path, on every platform, the speed impact of having an extra IF every time you drew something, not to mention the testing involved and it's a massive undertaking - all for something that is a small irritation. I'd much rather use that effort putting in significant new features like runtime language support, or a particle editor - something like this.
So change it to RGB.
Tell everyone you are going to change it to RGB.
Make an import script that converts the old BGR to RGB as needed.
You get to use the same color scheme as everyone else and maintain a 'standard of practice' used across the computer graphics industry, and maintain backwards compatibility at the same time. Yes, it will be a bit of work, for you the dev team to write that script, instead of each user changing their code, but in the end you get what is a better product. You even say its an inconvenience. Eliminating inconveniences for your user base should be a core goal.
Earlier, you stated:
...snip...
Again, you may not like or agree with it, but these are the choices we've made, and it's not going to change.
...snip..
We're hardly noobs either, and we make our choices for what we believe are good reasons - some of which we can not tell you; accept this, you do not get to dictate business strategy to us.
Now, give us good features that we agree with, and we'll certainly consider them. If we don't we'll try and give you reasons. By all means, feel free to convince us. But we are a limited resource and will implement the things we deem are the best thing for the product.
So I'll say again. You may not like our choices, but unless we get a robust reason and solution to an issue we won't do them. I find it incredibly offensive that you say we're closed to change and feedback, and even a quick search here will show you this isn't the case. So if you simply want to insult us, keep it to yourself, I'm not interested in reading your abuse. Got some positive suggestions that will help and not cripple the product in other ways? Then I'm all ears.
That highlighted part, thats a no-no in game dev 101. You do not make the game
you want to play, and you shouldn't be making the GameMaker
you want.
You make the game
your players want. You should be making the game maker
your users want.
We all dictate business strategy to you, in whether we buy your product or not. Its hard I imagine, to have your job, to be this open and direct with your customers and communicate with them. A lot of factions here want different things, you personally want different things as a developer, and even your parent company may dictate certain things.
I can tell from your posts you are worn thin. As this is a Public Beta, expect a lot of opinions to get voiced and feathers ruffled. Ive seen some really immature things be said by YoYo staff in the past. I know Ive said things here and there on the net Id like to take back. As a company,
All of you must remain professional. Some of us are deciding to continue using your software based on how you interact, on how you have matured as people, yes people, with feelings, a job and a lot of love and passion for GM.
Me,
- I want a professional IDE that allows for common industry standard practices with modern languages decoupled from the engine.
- I want a modular interface where I can change how I make games as much as what platform I export to.
- I want to get rid of GML, a proprietary language and use C# or Python or Javascript, that translates to other skills later
(or can be brought in by people that already know one of them).
- I want a tile and sprite editor better than or at least as good as common freeware pixel editors.
- I want a soundboard at least as robust as musagi and sfxr (or bfxr).
- I want a room layout editor that functions from multiple perspectives, side view, top down, 3/4, isometric.
- I want Box2d or similar physics.
- I want internal variables exposed.
- I want a scene graph view of things I can work with.
- I want OO coding and interfaces. I want to define structs.
- I want one heck of a 2d gane environment that leverages the best in underlying libraries on todays hardware to compete with Unity, Unreal and Godot.
Backwards compatibility is great. Its also holding you back from making GM be the Best it CAN be. You have to cut the apron strings sometime. Moving to a C++ codebase is great. It should have been the turning point from the old, to the new. There is a middle ground here.
We the community are reaching out to you, now, while the product is under development in a public beta, telling you what we need. This is demand. If you dont supply it, we will buy other software that does. This isnt a dictation of business strategy, its simple economics. Try to remember who uses the software at the end of the day. Listen to what we are asking for. Make that software first, then fit in your personal wishlist. Please, try to relax and remember, some of us are trying to help you and may be from different cultures with different norms and language barriers. Im sure it is stressful and at times trying. You ar an ambassador and a proprietor.
Im not just doing business with 'Yoyo', Im doing business with Mike, and Nocturne and others. People helping people right?
Lets help each other make games, thats what this software, and especially this community, has been about from the beginning. If anything should remain 'backwards compatible', it should be that.