[Smarty]

Please read this entire message before responding, I don't want to read "everyone knows it is!".

I've seen numerous demands on this forum that Game Maker, or at least it's engine, should be rewritten in C++. There are always two arguments to the demands: Game Maker would be able to compile, and it would be a lot faster.

Let's first finish off the compilation argument and get it over with: a Game Maker written in C++ will not produce compiled games. C++ does not produce applications that are automatically compilers. To let Game Maker compile a game, it has to be made a compiler itself. This is a task of considerable proportions, regardless the development tool used for it. C++ does not make this easier than Delphi.

Now the second and most heard argument: speed. An engine in C++ will run our games faster then an engine written in Delphi. Really?

Both Delphi and C++ produce compiled executables. Why would a Delphi compiled EXE be slower than a C++ one? I have been looking around on the net for any substantial proof of this claim, but so far haven't found any explanation why this would be the case. In fact, I have read a few claims on discussion pages that Delphi EXE speed is 'on par' with C++ EXEs, in some cases even faster, thanks to code optimalisation done by the Borland Delphi compiler.

There aren't many developers with enough experience on both platforms who can back up their claims with fact. People who choose for C++ do so mostly because it appears to be more low-level, closer-to-the-core. Delphi is a RAD tool (Rapid Application Development) with many high-level extensions. That sounds less l33t, but it does not hinder a developer from going under the hood (in fact, even inline assembly is supported).

An interesting note is that an application like the GM engine relies heavily on third party libraries in Windows and DirectX. Those have all been written in C++, so a lot of your game already uses C++ routines.

I realise that part of the problem of this comparison is that the code of a same-purpose application may be significally different. And if GM is ever rewritten in C++, it is likely that the entire code gets a major overhaul only because it now developed with the knowledge of the previous development in mind. But that means that GM's supposed speed issues are related to inefficient programming and not to the development platform.

I think the development tool should always be the decision of the developer, not the decision of the user of the application. The developer chooses the tool on the basis of his personal expertise, the capabilities he requires for the development, and the speed and ease of development with which he can fulfill the task. You are requesting the engine to be redeveloped in a programming language that the developer has little experience with. You are requesting a rebuild which may take months, if not a year or more to complete. If you request this, you have to bring a few damn good arguments to why it is necessary.

I am very interested in hearing those arguments so that I can support GM to be rebuilt in C++. Right now, I have little reason to believe it is necessary.

[UndergroundGames]

ive been reading lots about pros and cons between different languages lately and have links in my favourites at home i'll post up later!

wikipedia.com is a good site to compare them! search for programming languages!

fact is, a massive majority of programmes in this world are written with the C side of languages, including Windows itself! and it goes without saying, that a programme designed for Windows that has been coded in the same language Windows uses is a good start yes? a massive majority of people use C for a reason! it's the "industry standard" if you like! sure that doesn't make it the best, but something doesn't get the tag "industry standard" for nothing.

i wouldn't say it's necersary to change gm from delphi to C, but it certainly couldn't be a bad thing. EVEN IF ALL that comes out of it is (like you say smart), that the whole thing is written from the bottom up with the last 7 editions complaints in mind!

i will post up some very interesting links for you later when i get home from work! but for now, have a look at wikipedia's write ups and comparisons between the languages for some eye-openers! there ARE of course things delphi can do that C can't (at least as easily), but when it comes to making computer games, the majority of professional programmers use C based languages, and as i said, that HAS to be for a reason yes?

good topic. one i hope can be filled with facts and not a 'this ones better than that one mentality' answer!

and let's get things straight from the start, GM is a brilliant application that more than fulfills its purpose of being an introduction to newbies into programming! 8-)

[Smarty]

If anyone has a link that compares C++ to Delphi executables, then I'd really like to see it. But don't tell me to look around myself, I've tried that already and I couldn't find a reliable source. I guess I suck at Googling.

[JaketheSnake3636]

Couldn't the speed of each .exe depend on what that program is doing at the time? I'm not very knowledgeable on this subject but I would think that each programming language would be faster in different areas.

[EricDB]

Here's a lengthy discussion on the subject by people who seem to know what they're talking about.

It appears that there isn't a huge difference, if any. They're both roughly in the same spot on the low-level -> high-level language spectrum, so compilers can make roughly the same degree of optimization.

I think the main advantage would be the bottom-up rewrite itself, not the C++ language. Of course, only Mark knows just how much a total re-write could help. Maybe a lot, maybe very little, depending on how previous development has gone.

[Jo-Jo Bob Joe]

Quote

fact is, a massive majority of programmes in this world are written with the C side of languages, including Windows itself! and it goes without saying, that a programme designed for Windows that has been coded in the same language Windows uses is a good start yes? a massive majority of people use C for a reason! it's the "industry standard" if you like! sure that doesn't make it the best, but something doesn't get the tag "industry standard" for nothing.

So your saying that Game Maker should be re-writen in C++ because it is the "industry standard" and all the cool kids are doing it?

From what I have read, Delphi seems to be faster than C++. This would be a nice and polished paragraph with the pros and cons of Delphi and C++, but sadly I could only find pros and cons of Delphi and Java. I could edit this later if I do find anything, but I will likely forget I even posted here

[rinkuhero]

It might be more useful to identify the problems with Game Maker and then identify whether a re-write will fix those problems. I'm not an expert programmer, so I don't know. But I can identify some of Game Maker's current problems.

1. FPS is about sixty times slower than compiled programs (the number isn't exact, maybe it's 10, maybe it's 100, but I think I'm in the ballpark), given the same amount of drawing to the screen. This is probably mostly due to it being interpreted rather than compiled, but take a look at this game, Shoot the Bullet:

http://www.youtube.com/watch?v=hw2u0PEwgQ0...related&search=

Now can you imagine that running at more than 3fps on most computers if it were written in Game Maker, no matter what optimizations you performed? Yet Shoot the Bullet runs at 60 FPS on my relatively slow computer.

2. Large games in Game Maker take a huge amount of RAM, I had a game that used 300 MB of it once, before I started loading external resources from file. I know it's mostly the developer's fault that it uses that much RAM, but shouldn't there be some type of built-in functionality to load resources from file only when they're needed, and free them when they aren't? Why should the Game Maker even store resources in the gm6 file, why not have them entirely in an external cabinet file, and give the Game Maker smart routines to determine when they'll be needed and when to free them from memory (such as loading them when they're referenced by an existing object, among other tricks).

3. CPU usage is very high when there is a lot of processing to be done; if you have about 500 objects or so, processor usage begins to reach 99% and stays there, even though the objects don't do much. Again I suspect this is because it's an interpreted language, simply calling an empty user-defined GML function call 1000 times a step often uses 99% of CPU usage, which isn't very good because a lot of games are complex enough that they need to use hundreds of GML function calls per step.

Will re-writing it in C++ fix 1, 2, or 3? I agree that I don't immediately see how it would. Number 3 seems like it'd be the easiest to fix with more efficient programming, but I'm basing that on almost no experience.

This post has been edited by rinkuhero: 05 February 2007 - 03:32 PM

[Pogo708]

Something I kind of messed around with trying to do was a gm6 > C++ converter. Instead of straight compiling the GML, it seems like it would be a lot easier to convert it like this (Maybe to Delphi instead, given that's what it's written in), and compile. It would just need to go through, replace each function call with the actual code used to complete that (in Delphi), and output a source file. If this was kept hidden from the user, that could be done and then compiled with a Delphi compiler to create a compiled exe. What would the plausibility of that be? It'd be difficult, but far less difficult than writing a compiler yourself.

[Tera4d]

Well i created two of the same applications one in gamemaker and one in c++.
The application just shows a 3d model from my newest game (made in c++) and it has 19600 polygons.
In c++ it took about 1 second to load and it took up 5% of my cpu and about 25 mb ram
And in gamemaker it used all my ram and all my cpu! And the model didnt appear on the screen.
But the c++ game is bigger because of the massive 3d engine (ogre3d).
And with c++ u have major advantages such as building ogre3d or any other 3d engine directly into gamemaker.
Because delphi doesnt support many of these engines.

And if you create gamemaker in c++ maybe u can then use a external compiler.
When you click on the compile button that gm then translates its stuff to c++.
The 2d commands to allegro or sdl and the 3d ones to ogre3d.
And then use mingw as an compiler or something,

This post has been edited by Tera4d: 05 February 2007 - 03:45 PM

[Xception]

The best solution would be to keep it in Delphi and write some critical parts with optimized assembly.
This would make more sense to me than rewriting the whole thing in C++.

[Pogo708]

Sounds like you hit an infinite loop there in GM when you were loading. You might want to check that out for an actual comparison.

[blueangel99]

Old

This post has been edited by blueangel99: 02 March 2008 - 03:56 AM

[Daniel-Dane]

blueangel99, on Feb 5 2007, 06:47 PM, said:

well what about C#<{POST_SNAPBACK}>

Isn't that the .NET thing? If so, then no!

[rinkuhero]

blueangel99, on Feb 5 2007, 01:47 PM, said:

well what about C#
<{POST_SNAPBACK}>

Um... think of it like this: which language you use is not the main thing that determines how fast a program runs. How you code it matters much more. Sort of like which language in real life you speak doesn't determine how articulate you are, you can be articulate or inarticulate in any -- English, Chinese, Malay, etc.

This post has been edited by rinkuhero: 05 February 2007 - 05:50 PM

[pstudio]

Quote

The best solution would be to keep it in Delphi and write some critical parts with optimized assembly.

The chances of the programmer writing better assembly than the compiler is quite small. You should be a talented assembly programmer and have a good understanding of the compiler, to be able to do what you're suggesting.

When it comes to rewriting GM in c++ it just doesn't make any sense. Just because a program is written in c++ doesn't make it better than any other program written in an other language. Ofcourse it depends on the compiler, but Borland/Devco/CodeGear is a company with great experience on this subject, and their Delphi/Pscal compiler is highly optimized.

I know both languages pretty well, but I preferre to write in Pascal (using Turbo Delphi). It's not becuase it makes better executable, but because it makes programming easier. In the end it all depends on which language the programmer likes to work with, and the Delphi enviroment is a lovely enviroment.

An a last thing. Someone mentioned that c++ is a industry standard. First of all, Java and c# is probably the most prominent languages at this moment (c# is ofcourse pretty much c++), and it is likely that these will replace c++ totally. The only reason c++ is widely used is because of historically reasons. If you look at c++ from a language designers view, it is quite old, and should not be used. This is ofcourse a flaw with many languages, but c/c++ is the most noticable example.

This post has been edited by pstudio: 05 February 2007 - 05:52 PM

[CyberTwister]

Quote

The best solution would be to keep it in Delphi and write some critical parts with optimized assembly.
This would make more sense to me than rewriting the whole thing in C++.

I completly agree...
What people want want is just a game wich will use less of RAM, get more FPS... Imagine (dont do it) that u tell them it's in C++, even if it is in delphi, every people will be happy

Also, i think the fact to look what the "concurence" is doing should be a good thing (MMF,...)

This post has been edited by CyberTwister: 05 February 2007 - 07:17 PM

[Null]

http://shootout.alioth.debian.org/gp4/benc. ..p&lang2=fpascal
That is the best link I could find for a good comparison between two languages. Please note that it compares Free Pascal and g++ on a Debian Linux system. So, the comparison isn't really relevant until anyone can find a version for Windows compilers. To sum the results up from that test though, Pascal programs are usually smaller and use less memory than C++ programs. But the C++ programs are almost always faster.
EricDB, that discussion is old and compares Delphi to VC++ 6. VC++ 6 is just an all-around bad compiler. It is not standards compliant and produces inoptimized objects. On the same note, I would bet that a few enhancements have been made to the Delphi compiler since 2000 too.
Anyway, regardless of the speed tests, C++ does offer RTTI and generic programming, of which I know of no Delphi implementations. Not only that, but it comprehensively facilitates numerous programming styles, not limiting the author to a single one.
[-EDIT-]
Ah, I've found these pages.
http://dada.perl.it/...ut/mingw32.html
and http://dada.perl.it/...out/delphi.html
These benchmarks show some dominance - the C programs are faster, use less memory, and have only a few more lines of code than their Delphi counter-parts.

This post has been edited by Null: 05 February 2007 - 07:23 PM

[FredFredrickson]

Tera4d, on Feb 5 2007, 07:45 AM, said:

Well i created two of the same applications one in gamemaker and one in c++.
The application just shows a 3d model from my newest game (made in c++) and it has 19600 polygons.
<{POST_SNAPBACK}>

This is neither a useful test, nor a reliable comparison to gauge performance.

[uuf6429]

Rewriten in c++ doesn't make much difference. My real interest is in creating a real GM compiler. I know that it isn't that feasable so i won't suggest Mark creating it. This seems a task suitable for a group of GM+ASM programmers (if the compiler is built from ground up). The best option in this case is making the GM ide issue c++ code (or any compilable language) and use a free compiler (in this case mingw is suitable).
As I already said this option should be considered by some experts on this forum. Myself (and some help from a friend or two) did this sort of translation+compilation but the problem is in creating all does classes. Needless to say that it was a mere free-time experiment and not one to be considered as developable (by us at least).
Regards,
Covac Software Team

Edit:
After reading here and there I am sure that Smarty wrote this thread to ask for speed considerations. This is a bit of an unbalanced question to ask. A small example is when having a game with one object, one sprite and no code does the porgram need such functions as show_message()? It seems that the better consideration is not weither c++ is 500millisecs less or more but my idea of removing unused functionality is much better to consider. Ok there might be hidden code needed (ie: no need for show_message() in program but used in execute_file() in an external file) in this case Mark might put a checkbox if the users want to remove unused functionality or not. Look at c++, when merely creating a PE and using some API or dlls the final version doesn't use all dll calls found in the header. C++ might be old but it is sensible to hold off unused resources. GM can't i've worked with delphi exes in the past and they all get out with a set of toolbar images (in bmp format with most size) i'm sure that GM exe have this same extra piece of useless data.

This post has been edited by uuf6429: 05 February 2007 - 08:26 PM

[RhysAndrews]

It's good to see the more advanced people being able to state their opinion, as they were all covered up previously by the less knowledgeable members begging for C++ GM.

I'm not incredibly advanced when it comes to other programming languages, their speeds, etc. However, would the lack of performance in GM have anything to do with the fact that it isn't compiling the games? I believe the major part of performance in Game Maker depends on the developers ability to optimize code and features. I mean, we really just plonk code together, sometimes grabbing third-party sources and whacking them in too - then when the FPS goes down to 14fps, we say "oh well, that's Game Maker for you". Though I hate to put my own project into the discussion (this isn't a promotional act!), Conflict: Online was rewritten 3 times - and during that year in which I kept rewriting the same game, I learnt a lot about optimizing code - from other team-mates and just experience. So much, in fact, I was able to improve both performance and quality by tons.

Regards
Rhys Andrews