Tackling misconceptions:
That's the thing! Direct X 11 was the big difference. I still think thisnis significant in making it much better.
One thing to know about graphics APIs is that they are not the be-all and end-all of performance. A new API has the POTENTIAL to make a game faster, but only if you make use of that new structure. Given that the rendering pipeline that GM provides has practically remained identical in operation, you wouldn't really expect any significant gains vs DirectX 9 as you are pretty much still only using DirectX 9 features and style anyway. You can only really yield a significant improvement if you make specific use of API features and employ good engine-level graphics optimisations. Given how general GMs pipeline is, I would be impressed if there was any sort of significant improvement anyway, given that standard vertex batching and shader operation is quite barebones anyway.
For example, games that are directly ported from DX11 to DX12 can in some cases get slower, this is because DirectX 12 significantly changed the graphics programming paradigm. As one example, replacing constant communication streams between the GPU and CPU with pipeline state objects, so that any time you want to perform a state change, you can perform a bunch of changes in one go. Just throwing this out there as it complements my next point.
Why were view ports replaced with virtual cameras? I mean seriously this is not a 3d Engine. Maybe they could offer a patch for 2.0 to correct the importer.
From a general graphics programming perspective, and from a game design perspective, the concept of having a virtual camera is important. Generally speaking, 3D or not, a camera acts as a unified means of transforming the view. In a 2D game, this can simply just mean scrolling from side to side, but it also means zooming in and out. A "Camera" is a collection of matrices that apply uniform transformations to every subsequently rendered triangle on your screen (sprites are made up of 2 triangles). The reason you use a camera is so that you can generalise your rendering code so that no matter what camera you create, a correct representation of your game is created.
The issue with view ports by design was two fold:
- 1) There are two main matrices which build the viewport: Projection matrix and the view matrix. Views did not actively give you direct control over these matrices, instead, they did it behind the scenes, and overriding it using the d3d_set_projection function was less than ideal. (Note that this is still useful regardless of whether you are in 2D or 3D).
- 2) From a gameplay standpoint, it is common that you want to grant view dominance to different objects depending on the scenario. Camera's allow you to dynamically flip between different camera's. Lets say one moment, you want the camera to follow a given player, but after that, you want to switch to a different camera that either showed a different view of the room, or tracked a different object. Doing this conventionally is quite messy and requires lots of manual setting of the viewport variables. Essentially, you would have to fight what GM was doing under the hood to get custom behaviour.
I personally use view transformations for things like creating scrolling content in the UI, or mini-maps, as I can simply modify the transformation and that transformation subsequently gets applied to everything rendered after the base matrix has been modified. Which is far neater applying an offset to every object in that render call, especially if the same render function is used in two different places. As it stands, doing it that way works, but isn't as neat as it could be in 1.4.
Now, this new camera system keeps things general. Good engine design is one in which the programmer does not have to worry about implementing design patterns to achieve common engine functionality, they should instead be able to get straight on with what they want to do, no mess. This new system enforces view modularity, consistency and better habits from the programmer that will subsequently mean it is easier to use overall.
In the short term, you will just have to be willing to learn how to make use of the new and improved features. After all, a programmers #1 skill is being able to learn efficiently.
Considering a new perspective on what GMS 2.0 is:
I'm also personally of the opinion that it is not worth porting a project that is already in development to GMS 2. In some cases, the re-implementation of legacy functions (The ones that get generated in GMS2.0) could actually end up being slower than how they ran in GMS 1.4 given the increased overhead. Trying to retrofit an old project to a new engine prevents you from being able to use the very features and improvements that new engine has made. The one exception to that being that I know GMS 2 has much better resource management and in-engine editors, however level editors for example, are something that you can often implement effectively yourself, especially if you need special features for your project, or plan on making level building open to the players.
Perhaps that's just my opinion, given that the two engines share a very similar VM, in terms of performance. So my question to you is, why go to GMS 2 now, when GMS 1.4 seems to be working for you? I'm not saying GMS 2 is bad, I think it is very good, but I think complaints about the clear differences between the two engines, and YYGs clear intention to improve workflow by changing the way certain things work is a bit unreasonable.
Also, out of general interest, why are you so volatile with regard to staying or leaving? If you find a bug with the software, fair enough, report it on the bug tracker.. but I never understand what these topics where you threaten to leave achieve? If you want to leave, leave. If you want to stay, then stay.