Open discussion: What game devs need from Delphi

[SilverWarior]

WARNING! Long post ahead

In short the small workgroup would discuss what we, the community, really need as game developers from Delphi.

I would be interested in being part of such group.
But being part of Embarcadero MVP program? I don't know. If I understand their decription of this program correctly the main goal of it is promoting of their products. Now I can't go and say to sme pepole "look this is a verry good feature" when I know myself that that is not good feature becouse it has some bugs etc.

Do we need or like FireMonkey?

Overal idea of FireMonkey is good but its implementation is verry poor (slow performance, ackward usablility, bugs, etc.). So until it improves a lot it won't play of much importance to me.

Do we like where the mobile compilers are going?

Since I still have no expirience developing mobile applications I cant actually express my opinion on this.
But when reading various blogs about the cahnges that has been done to the programming language itself for new compiler to work I must say that I don't like what I'm seeing.

Do we need specific IDEs or other tools that aren't with the suite right now.

Some features that needs to be fixed ASAP:

1. Imrovments to code editor to quickly alow you to view in which scope of the code are you currently on.
2. Fixing Error Insight:
   When you insert "{" for all the code from the current position of the cursor to the end of the unit gets marked as being comented out. This cause all folded code to automatically unfold. Code below cursor also gets unfolded when you write some syntactical error. This in turn makes code folding almost useless.
   I would suggest limiting Error Insight to checking only code which is in current scope and not whole unit. This would solve theese problems and make Error Insight much faster.
3. Fixing code folding (besides the pre mentioned problem:
   When folding code inner parts should fold first automatically (nested methods, nested regions, etc.)
4. Preventing block commenting (use of "{" and "}" characters) to span outside current code scope:
   Right now you can do this:
   

   procedure SomeProcedure1;
   begin
       I := I-2;
       {
   end;
   procedure SomeProcedure2;
   begin}
       I := I+1;
   end;
   procedure TForm2.Button1Click(Sender: TObject);
   begin
       I := 10;
       SomeProcedure1;
       Form2.Caption := IntToStr(I);
   end;

   In the above code I actually merged the two procedures into one which could result in terible bug which might not be easily found especially if you have huge amount of code and you comented out large protion of it.
5. Fixing and Optimizing RTTI:
   Since RTTI is most important part as it affect how your finall aplication would behave it is imperative that it has absolutely no bugs and that it is optimized as much as posible.
   Based on the many rants on varoius Delphi based blogs there are lots of isues with RTTI which are now being present for several versions of Delphi. As many others I think that this is unacceptable.
   When I'm dveloping applications of my own I never extend my code with new features until I'm sure there are no bigs or poor performance in the code which I'm extending. Why?
   If you extend bad code all the extended code will be affected by the bad code from which it was extended. And fixing bugs in this bad code which has already been extended could cause the extended part of the code to no longer work. So this would result in more code to have to be rewritten. And since we are only humans more code we write, more chances there are that we introduce new bugs.

I belive all of theese can be fixed by making code editor to actually treat code as blocks. Delphi (Object Pascal) is object oriented programming language so why not treat its code as such.
By doing so you can solve many problems and integreate many new features (some listed below).

There are several features that I would realy lke integrated in Delphi IDE which are not present right now:

1. Ability to time-profile any part of your code with ease:
   Currently you need to use complicated third-party tools. TStopWatch record also isn't verry handy to use as it needs quite some code to get the results out.
   What I want is timeprofiling which would automatically output profiling results back into the IDE itself so that you can reuse that information in future.
2. Ability to draw method dependancy charts:
   How many times were you wanderng which parts of your code would be affected when you make some changes to a single method of yours. In big projects making smal change to often reusable methods can cause large change in your projects behavior and could also easily cause lots of bugs.
   If you would have easily accesible information about where your method is being used you could more easily predict what changes you mus not make. Or athleast you could expect which bugs would ocur with the changes you will make.
   Another good thing that this will provide you is easily finding of unused parts of your code.
3. Ability to draw Flowcharts of your code:
   Being able to visualize how your code executes could help you understand your code better.
   Yes we have all been in position where we have been looking at part of our code and still not understand how it works even thou we have been comenting it. This can be especially hard with large prjects.
   And inf you combine this with Time-profiling information you could also quickly visualize which parts of your code takes longer to execute. This would greatly help you in finding out code botlenecks.
4. Ability to set special parameter to various variables and objects which would alow custom classification of these with memory manager:
   What this custom classification would provide is the ability to quickly get information of how much memory is being used for certain things.
   Imagine that you can quickly see how much memory is being used by every variable which has this special flag set to "Game units", or "Graphics", or "Game map".
   These would alow us to quickly find out which parts f our program use most of the memory and therefore make optimization process easier.

Now I could probably offer even more suggestions but I can't remember them now. Theese are the ones I would benefit the most from them right now.

How about bundling of "editions"?

Current bundling that EMBT uses is by my opinion compleetly wrong. Why? Becouse in many cases you are forced to pay for features that you might not even require. Let me give you an example.
If you need baic database support (local databases) you would buy yourself a Proffessional Edition. But if you need more advanced Database supoort (networked and online databases) you need to buy Enterprise Edition which brings you quite some other features that you might not even need but would have to pay for them.
So in such scenario many pepole go and buy Proffessional Edition and then get third party database component which also alows them to use ntwork based databases.

What I suggest is that Embarcadero compleetly changes the way they bundle their software. Instead of having pre set bundle packages (Proffessional, Enterprise, Architect, etc.) split your sofware into many smaller packages.
For example:

1. Base IDE
2. 32 and 64 bit Windows compiler, linker, debugger
3. 32 and 64 bit MacOS compiler, linker, debugger
4. 32 and 64 bit iOS compiler, linker, debugger
5. 32 and 64 bit Android compiler, linker, debugger
6. 32 and 64 bit Linux compiler, linker, debugger
7. Basic VCL components
8. Advanced VCL components
9. Basic FireMonkey components
10. Advanced FireMonkey components
11. Basic database components (for local databases)
12. Advanced database components (for networked components)
13. Basic networking comunication components (TcpIP, UDP Sockets, etc)
14. Advanced networking components (HTTP, HTTPS, etc.)
15. WebService components
16. Reporting components
17. OpenGL components
18. Sound components
19. Multimedia components
20. etc.

This will alow users to actually chose which components they actually require.
This would make Delphi more afordable as you will be paying only for the components you will actually use.
It would also give Embarcadero clear picture of what parts of their software is comonly used and what not.
And if they also make seperate survey for each smaller package they could get invaluable information about where they should focus their development more, where there are bugs, with which features are Delphi programers pleasend and with which not.


As I have written on some blogs already Embarcadero can contact me at any time if they want even better explanation of any of my suggestons.