ENIGMA Forums

General fluff => General ENIGMA => Topic started by: Goombert on May 31, 2014, 10:13:52 AM

Title: New Beginnings
Post by: Goombert on May 31, 2014, 10:13:52 AM
Ok, there has been a lot of discussion of creating a fork of ENIGMA which actually fixes some things in GM. I am beginning to seriously consider this now.

The purpose of the fork is not to remain compatible with any other program, and takes the GM approach in a fundamentally different direction allowing for greater optimization and an intuitive redesign.

Some of the features and differences would be as follow:
* Windowing system would be completely abstract allowing the creation of multiple windows.
* No fake fullscreen, aspect ratio handled natively by the display.
* No view options in room editor and no global constants, views can be controlled via screen_set_viewport functions, because there is an efficient trick to speed up games by allowing two views to be rendered in the same draw call.
* Revamped non-retarded implementation of the audio_* functions.
* Complete redesign of graphics allowing not only vertex buffers but index buffers and instance geometry, with a proper bridge of OGL and D3D and not just a tacky way of emulating D3D by use of an OGL backend like ANGLE.
* Branching path system with improved A* motion planning.
* Cross-platform video interface for hardware accelerated video playback and rendering.
* All resources handled as included files, each will have a "preload" option and if it is unticked you have to load in manually using _load* functions asumming that all resources are extracted locally to the executable, but you will still be able to control how the resources are extracted, kind of like in Visual Studio
* Completely unrestricted file hierarchy, the IDE will also support loading multiple projects at once, and will support only one file format.
* Because the IDE will use a single uncompressed file format, the IDE will also be much quicker with loading and saving and compiling projects.
* CLI programs will exist for building projects outside of the IDE
* Non-object oriented method of compiling and linking code into your game.
* Possibly, strict C++, meaning no GML or EDL and no hybrid language, pure C++, variant type would remain most likely however, only differences would be more strict syntax, which ENIGMA kind of already has anyway.
* File reading/writing revamp, will support the ability to work with multiple INI files at once.
* Script redesign, they will be actual source files, if you want them to act like functions in GM you will have to prototype the function, not sure what to do about forward declarations.
* As a result of the script redesign, there will exist an object resource, but the object structure will be redesigned to allow you to easily and simply code an object using a script, so for instance if an object has a sprite it will inherit an object_sprite class, if it has a model it will inherit an object_model, if it has physics it will inherit object_physics, or a combination of these entities. An event listener and stack may be created similar to Java, C#, or Qt Also important to mention the object resource will not be removed, it will remain allowing a more graphical approach to create an object.
* Possible drag and drop redesign that will follow a more schematic approach like you often see with material/shader editors.
* Certain aspects may follow a more entity component style system, for instance, since views will be removed, you will be able to place camera/projection entities in the room to accommodate, which will also allow you to control aspects such as fog. Unsure of how to handle instance translations and properties however, as it will be dependent upon what entities their prototype class inherits.
* Full threading support, atomic and immutable types etc.

This project will basically allow us to address things immediately by doing them our own way, discussion of feature and implementations will not revolve around compatibility vs. incompatibility. These are simply ideas floating in the air, but I am seriously consider turning this into a practical implementation. I am just sick of working on something that I can't improve or innovate with. Suggestions and feedback is welcome. The project also has no name yet and is simply a proposal.

NOTE: This project would be licensed the same as ENIGMA once licensing for ENIGMA is established.

Just to put some names into the hat or some keywords to work with for a name:
Perform - not an acronym, pretty simplistic
Fluid or FLUID - possibly an acronym, meant to be intuitive, has no relation to F.L.U.D.D.
Formulate - key term, relates to variables/formulas/equations/functions
Title: Re: New Beginnings
Post by: egofree on May 31, 2014, 10:24:14 AM
* Possibly, strict C++, meaning no GML or EDL and no hybrid language, pure C++, variant type would remain most likely however, only differences would be more strict syntax, which ENIGMA kind of already has anyway.

For me, one of the most important aspect of GML and ENIGMA is the ease of use. If you impose C++, you will repel a lot of people, including myself. In this case, why bother ? Let's code everything with C++ and OpenGL. No need of GM or ENIGMA  ;)
But who will do this project ? You said you don't have much free time anymore  :D
Title: Re: New Beginnings
Post by: Goombert on May 31, 2014, 10:28:38 AM
Yes but egofree, you aren't considering that ENIGMA already has very poor compatibility with all the bullshit syntax of GM. Only real difference is you would need to start placing ; after every line, which I always did with GM anyway. To me it honestly doesn't affect ease of use at all. And it ensures your code won't break with future releases, it also removes the overhead of needing your game to be parsed before compiled. It can simply be copy and pasted and compiled.
Title: Re: New Beginnings
Post by: egofree on May 31, 2014, 10:43:13 AM
Only real difference is you would need to start placing ;

You are joking, right ?!!  :o  ;)
I don't pretend to know really C++, i've done only a little bit at university. But what i remember is that from me it was the least pleasant language to read. We have more modern managed languages, so i don't see the pleasure to manage again pointers hell !
In this case, why bother about C++ ? Let's code everything in assembly, as you don't even need to compile the code !  ;)
Title: Re: New Beginnings
Post by: egofree on May 31, 2014, 10:45:28 AM
It's a little bit off-topic, but do you still want to support ENIGMA ? As you are the only developer doing it for the moment, if it's not the case, for me ENIGMA will be a dead project.
Title: Re: New Beginnings
Post by: Goombert on May 31, 2014, 10:49:18 AM
Who said anything about pointers? All modern managed languages C#/Java are pretty strict with ';' and they are both very easy to read. Also resource identifiers will still be numerically unsigned, the only difference is that they will be reusable, so for instance if you delete sprite #3 and then add a sprite it will take that sprite identifier, so it will act like a pointer. Actually, since pointers kind of act like integers, there may in fact be no need to differentiate the two, in fact using pointers would probably be just fine, in fact, Studio does use pointers now for some of its resources.

Yes I would continue to support ENIGMA, another goal of this project is to potentially help ENIGMA better identify with itself, so in other words, be less confused about its sexuality. I would continue to work on both projects in fact. My project will allow breathing room from GM, allow developers to be innovative and get creative about approaching certain aspects of development, and allow ENIGMA/GM users an advanced step up to a more intuitive and efficiently designed engine. This would also probably lead to less bugs, a lot of ENIGMA's issues are related to incomplete discussions regarding GM compatibility, GM compatibility in fact inhibits a lot of ENIGMA's functionality.
Title: Re: New Beginnings
Post by: Rusky on May 31, 2014, 12:32:11 PM
Anything intentionally breaking compatibility with GM needs to focus on a better workflow and experience for experimenting with game design. You've got several good internal, technical improvements you could get even when staying similar to GM, but there are conceptual changes that would make things much easier to use- make everything as immediately visible and directly modifiable as possible.

Component-based entity design is pretty much essential. It doesn't necessarily need to be entity/component, although that is a good, clean, efficient way to do it. This is primarily an editor feature to let people describe game objects by which behaviors they have. User components also need to be first class, able to provide just as rich editor interfaces as built ones. They would ideally written exactly the same way as built in ones, which should really be replaceable to avoid engine bloat.

Josh's build mode is also pretty essential- it makes design much easier, and makes many kinds of experimentation possible that otherwise would just never happen. A good design would let this run in the editor itself with an instrumented version of the engine to combine it with profiling and debugging. It doesn't even have to be used only when the game is run- it could be used to preview individual objects, effects, etc. Also, time rewinding is cool.

Good D&D is also essential to ease of use. The phrase "design and build quality games quickly and without code" on the old GM website is the reason I downloaded it as a kid. D&D itself was lacking- just a Scratch/Stencyl-like interface, ideally with the ability to type things in as well as discover them in lists, would be a major improvement, because it's not modal so you can see and edit a script all from one view. Construct has a variant of this where you pick things from drop down menus rather than dragging from a different area, which I actually like (and it makes the typing side of it make even more sense).

Even better, however, would be something like Subtext, which takes all the data flow hidden in off-screen variables and makes it immediately visible and modifiable. The variable D&D actions are another hurdle that can be reduced not only for ease of beginners, but ease of anyone trying to understand and debug the code. Something like this, combined with keyboard controls on the same level as directly typing in code (think supercharged intellisense rather than keyboard shortcuts), could even completely replace textual programming.

Another advantage of this kind of scripting interface is error handling. A visual and highly-intellisensed language can be much more statically typed, without sacrificing ease of use. Anything that now pops up an error message in the middle of the game, potentially getting missed by the developer, and potentially getting all useful debug information stripped out in a release build, should be caught at compile/edit time if possible. The visual part of the design can even make several classes of errors impossible to express, making it even easier to learn and understand.

Rather than trying to fit these kinds of features into an engine, the engine should be designed around these features. If something makes it harder to do time rewinding, or Subtext-like scripting, it should be rethought before the interface design. Interface design and behavior is key. It's easy to forget this as a programmer, but it's the first and biggest thing end users see. Excusing bad interface design with an internal technical reason is worthless.
Title: Re: New Beginnings
Post by: Darkstar2 on May 31, 2014, 12:46:28 PM
For me, one of the most important aspect of GML and ENIGMA is the ease of use. If you impose C++, you will repel a lot of people, including myself. In this case, why bother ?

He just put the final nail in ENIGMA's coffin.  :D  Looks like we're all headed back to our roots very soon :D :D

The first person who makes an extension in GMS to bring back some deprecated windows functions back, including video, improving on existing functionality, or anything worthwhile, including bringing back external resource access _add functions, I'll be their first customer when they release it in the new extension store.

Talk about  drastic actions ! lol.  Not everyone has the time or could be bothered to code their game in pure C++ ! I guess that defeats the entire purpose and would not attract any people that's for sure and would probably push existing users away.
Ease of use and speed. 

Quote
Let's code everything with C++ and OpenGL. No need of GM or ENIGMA  ;)

Exactly, if imposing strict C++ then might as well use that.  The product would target only one market......Advanced C++ coders.

Quote
But who will do this project ? You said you don't have much free time anymore  :D

Our existence is infinitely multiplied across a span of parallel universes.  He may be working already on this in another dimension. :P

Nothing prevents being a unique product and not compatible to GM but for the sake of ease of use adopting some GML/EDL functionality.  Making a strict C++ scripting that has to be one of the worst ideas !  Not every developer has years time and intentions of writing millions lines of code to do their games.   :D
Title: Re: New Beginnings
Post by: Darkstar2 on May 31, 2014, 12:48:47 PM
ase, why bother about C++ ? Let's code everything in assembly, as you don't even need to compile the code !  ;)

LOL ! Good idea mate, I say we do direct binary whilst we're at it ! :P :D
Title: Re: New Beginnings
Post by: Goombert on May 31, 2014, 01:11:01 PM
Very nice Rusky, I like your assessment. Some of the things I disagree with you on, but mostly I agree. While I do agree with you saying it should be designed around these features, I am not sure about a bottom-up approach. In a way I am suggesting a bi-directional approach to redesigning GM being developed discontinuously.

And yes as far as your design mode suggestions, one of the things that need seriously considered are to what degree the program needs certain parsing capabilities for reflection and things. Interestingly LLVM provides nice reflection features.
http://llvm.org/releases/3.0/docs/ReleaseNotes.html

As for drag and drop, you also gave me another idea as far making it more powerful, directly editing the code translation of a schema node. We could also parse the engine and collect all functions making them directly usable in the drag and drop mode. So you could essentially toggle between a graphic and textual representation of your objects.

Quote from: Darkstar2
He just put the final nail in ENIGMA's coffin.  :D  Looks like we're all headed back to our roots very soon :D :D
What the hell does any of this have to do with ENIGMA? And besides, I just addressed this question above.

Quote from: Darkstar2
Talk about  drastic actions ! lol.  Not everyone has the time or could be bothered to code their game in pure C++ ! I guess that defeats the entire purpose and would not attract any people that's for sure and would probably push existing users away.
Ease of use and speed. 
Despite the fact it maintains a variant data type? You literally wouldn't even notice the difference is what I'm saying. Irrlicht is pretty fucking popular, so is Unity, in fact a lot more popular than GM and all 3 of its scripting languages (C#, JavaScript, and something else) enforce ';'

Quote
Making a strict C++ scripting that has to be one of the worst ideas !
You wouldn't notice the difference, and second a lot of people would prefer it, myself included. It would also make your code a hell of a lot more portable.
Title: Re: New Beginnings
Post by: Darkstar2 on May 31, 2014, 01:53:45 PM
LOL.

I wouldn't notice the difference are you joking ?

You said you would restrict to C++ only, no GML, EDL etc...... Again defeating the whole purpose.  How wouldn't we notice the difference ?  I sure know the difference between coding in pure C++ and pure GML. !
and I'd notice the difference even drunk !

Yeah you mention unity and others, those have a steep learning curve and cater a more advanced market.  Some people may have creativity and tools but lack coding skills, this is what GayMakerStudio targets, poorly, yes, but it's easy to use and also offers more advanced functionality to those who want to use it (GML, Shaders, etc.)

More so, there are many C++ / skilled coders who also would use GM and such, as sometimes coding is not the only limiting factor, but time is........ Not everyone has months/years time to write billion lines of code for a simple game.  One of the selling points aside from ease of use is speed.
Some people are hobbyists and don't necessary want to make games for commercial release and spend 2 bloody years working on their games like most commercial games with an entire dev team!

So by your strict C++, this means that what I could do with 1 or 3 line of GML, I'd have to do in 20 lines of C++ code ! Nice.

 
Title: Re: New Beginnings
Post by: Goombert on May 31, 2014, 02:11:15 PM
You wouldn't notice the difference because variant would remain, and you already don't notice the minor differences in ENIGMA, since EDL does not fully support GML yet, not even close. The only real difference you would immediately notice is having to ';' at the end of each line. GML is practically C anyway, there's not much structure to it.

Unity caters to the lowest common denominator and so does YYG. Also those C++ coders you speak of are also probably bitching like crazy over the fucked up syntax, lack of ISO, and restricted functionality. The very act of featuring C++ would actually make them much more inclined to use such software, since they are by definition, C++ coders, not GML coders, which is what you referred to them as.

And also no, this would further cut down on the amount of coding you would have to do, it would also eliminate the need for extensions, since you could directly access resource structures for instance.
Title: Re: New Beginnings
Post by: Darkstar2 on May 31, 2014, 02:29:05 PM
not even close. The only real difference you would immediately notice is having to ';' at the end of each line.

That's what I've always been doing anyway, the end line ;.

What I am referring to is with GML or whatever name given, you can do things with fewer lines of code.  If I wanted to draw text centered vertically and horizontally on screen, it's easy:

draw_set_valign(fa_center);
draw_set_halign(fa_center);
draw_text((room_height/2),(room_width/2),"Hello World");

Result: Hello world centered on screen.

That's 3 lines of code.

So now you are telling people to fuck off and go learn C++ and do the same task in multiples of lines of code and in C++.

Now this is a simple example.  Now imagine more complex shit that has dozens or more lines of GML code, file reading, processing etc, so asking your users to use C++ !

Quote
GML is practically C anyway, there's not much structure to it.

I am not talking in terms of structure but code. 

Quote
C++ coders you speak of are also probably bitching like crazy over the fucked up syntax, lack of ISO, and restricted functionality. The very act of featuring C++ would actually make them much more inclined to use such software, since they are by definition, C++ coders, not GML coders, which is what you referred to them as.

So basically this caters to advanced developers and pushes away any beginners or people looking for creation speed and ease of use.  Counter intuitive.  This is like YYG all of a sudden saying they would drop GML functions and require all their users to use C++ in their projects, no more GML, if you want to draw a circle, draw text, move sprites, you have to do it through C++.

Quote
And also no, this would further cut down on the amount of coding you would have to do, it would also eliminate the need for extensions, since you could directly access resource structures for instance.

and exponentially increasing the amount of time required to a finished product, no ?
Title: Re: New Beginnings
Post by: Goombert on May 31, 2014, 02:44:37 PM
Ah, yah no, in fact, my engine would probably handle that in one line.

gui_create_label((room_height/2),(room_width/2),"Hello World");

Since, of course, I am not an asshat like Dailly and recognize the need for static text. And those functions are functions for use with GML, they don't really have anything to do with the language, I'm talking about syntactical structuring, and for some reason you think that's relevant.

That said if you can't recognize this, and you don't like C++, then my engine is not for you, stick with ENIGMA/GM or w/e you're comfortable with.
Title: Re: New Beginnings
Post by: egofree on May 31, 2014, 02:52:57 PM
If you want to throw away GML and EDL, what about using C# instead of C++ ? From my point of view it's much more friendly than C++, it has compiler on Windows, Linux and Mac (mono), and Microsoft says the future of C# is open source and it's also possible now to make very fast applications with .Net Native :

Code: [Select]
.NET Native gives you the performance of C++ with the productivity of C#.
http://blogs.msdn.com/b/dotnet/archive/2014/04/24/dotnetnative-performance.aspx

But again if think if GM was so successful, despite all its flaws, it's because it has the reputation to be very easy to learn. Well, i know that you could explain to users that the only difference between GML and C++ is only the semi-colon at the end, but i doubt they would listen to you !  ;)

Anyway Robert, that's was only my two cents. I am always grateful for all the work you've done and all the support you give on this forum, and whatever you want to make, it's YOUR decision, and i will wish you the best in any case !  (Y)
Title: Re: New Beginnings
Post by: Rusky on May 31, 2014, 03:14:32 PM
There are more performance problems with .NET than just JIT. It's garbage collected, its object in-memory layout is terrible, calling non .NET code has all kinds of performance loss converting objects, etc. It is a little better than Java, at least in what's possible to express.
Title: Re: New Beginnings
Post by: Goombert on May 31, 2014, 03:31:16 PM
Thanks ego, and I hope you will give my engine a try as well. You know I will be very helpful to users and developers if it comes to fruition.

Also, yes I would continue the engine in C++ as well, it's the only way I could bring all of my ideas to fruition to do it in C# and Java is a complete rewrite of the code base.
Title: Re: New Beginnings
Post by: egofree on May 31, 2014, 03:38:58 PM
There are more performance problems with .NET than just JIT. It's garbage collected, its object in-memory layout is terrible, calling non .NET code has all kinds of performance loss converting objects, etc. It is a little better than Java, at least in what's possible to express.

I've used .Net application only for business applications, not for games, and of course it's not the same. But i guess, except if you want to make very complex 3D games, it's not so important. As i see it, we are talking here about making a game engine for simple games, not making competitors to Unreal engine 4 or Unity !
Title: Re: New Beginnings
Post by: Rusky on May 31, 2014, 04:10:09 PM
Yes, most of the time you can get away with something like .NET without noticing the performance cost. I don't think that usually makes it worth it, though- consider Twitter. They started with Ruby on Rails, which has terrible performance on top of a language with terrible performance, but which is much friendlier than Scala, which they switched to because Rails couldn't scale.

In our case, there's no reason we wouldn't want to scale to more complex 3D games. Why wouldn't we compete with UE or Unity? I know I would enjoy using an open source engine with this kind of interface design to build a game like that. I do agree C++ as the only user-facing language would be painful, but C# probably isn't the best choice either. Unity is now hitting growing pains with their choice of C# as the user-facing language.
Title: Re: New Beginnings
Post by: Goombert on May 31, 2014, 04:34:21 PM
Anybody else got any good suggestions? Don't be afraid to mention them, if there was anything you could change about GM or revamp let's hear it.
Title: Re: New Beginnings
Post by: The 11th plague of Egypt on May 31, 2014, 05:21:49 PM
I love Java, even though I think some of its standard library could use an improvement.

If you want to use C++ to do away with the parser that has been slowing this project down forever, that's fine for me.
GML is not garbage collected, after all, just like C++, but similarities stop there.
GML is much more similar to C than to C++. There's very little structure and no generics in GML.

C++  is freaking huge, and it has pointers and scary things in that hugeness.
If you allow all of C++ then this would for sure drive away most of the GML crowd as quickly as you can dereference a pointer.
Yet, it would drag in others, so, a mixed bag indeed.

My only strong suggestion?
If you can do away with the parser, don't get your self lost coding a new IDE.
There are plenty of good IDEs for C++ out there you could make use of.
Pick one, write a custom plugin and be done with it.
Title: Re: New Beginnings
Post by: Goombert on May 31, 2014, 05:30:45 PM
I don't anticipate scaring away GML users, I hope to provide my engine as a stepping stone from ENIGMA, which is itself a stepping stone from GM.

The IDE will be a fork of LGM for the time being.
Title: Re: New Beginnings
Post by: Rusky on May 31, 2014, 05:47:12 PM
Dropping the parser would necessitate using another one- either another compiled language (unlikely to be one suitable), or another scripting language (Lua?), or a non-parsed language (i.e. graphical).
Title: Re: New Beginnings
Post by: Goombert on May 31, 2014, 05:59:16 PM
Oh, that's the other thing I was going to mention, I was thinking about maybe LLVM since it has reflection.
Title: Re: New Beginnings
Post by: edsquare on May 31, 2014, 06:09:47 PM
As long as this does not herald the demise of ENIGMA I'm all for it. And since Robert already said he would keep working in both projects...

As and offtopic : How come there's not a croudfunding campaign for ENIGMA?
You could hire developers to squish out the bugs and/or to add functionality.
Title: Re: New Beginnings
Post by: edsquare on May 31, 2014, 07:49:01 PM
Rob, I am all for it and am more than happy to help with the project ;)

Wish I could help but I don't know C++  :(


As and offtopic : How come there's not a croudfunding campaign for ENIGMA?

I have wondered the same thing in recent times.

I guess the answer would partially be 'commitment'. Once you successfully crowd-fund you are committed to the task. Most how the devs have voiced that they do this as a learning project and/or a hobby.

When you have people all over the world paying for this to be done it is a whole new ball game.

You may be on to something there...
Title: Re: New Beginnings
Post by: Darkstar2 on May 31, 2014, 09:18:31 PM
Ah, yah no, in fact, my engine would probably handle that in one line.

gui_create_label((room_height/2),(room_width/2),"Hello World");

Actually there would have to be 2 lines.  Remember this would be centered providing the x/y alignments are ALIGNED.
Example,
if in ENIGMA you do alone:
draw_text((room_height/2),(room_width/2),"Hello World");
Text would not be quite centered, you'd have to compensate by using string height/width, whereas if you use draw_set_halign(fa_center) and draw_set_valign(fa_center) the X/Y origin becomes center of the text instead of 0,0, so you can use the room_height/width /2 and nothing more and it will be centered.  Don't forget that some people might want to use left or right text alignment (fa_right, fa_left).  Your 1 line example would work providing the default X/Y alignment is center.

Quote
Since, of course, I am not an asshat like Dailly

:D

Quote
That said if you can't recognize this, and you don't like C++, then my engine is not for you, stick with ENIGMA/GM or w/e you're comfortable with.

Could you give more examples of how you would replace the GML functions ?

Collision, movement, etc.

Certain things would be unchanged I guess such as an object's X/Y position (x=whatever y=whatever), the if/for/while/with, etc. 
What about sprite_add, sound_add, background_add, place_free, place_meeting, and the rest of the GML functions ? give some examples.  If it means the same one line functions, I'm all for it, but if it means that we are required to do many C++ lines to do what could be done with 1 GML line, then it is ridiculous, and yes  I will stick to GM, and many people will feel that way except advanced C++ users.
I am not talking in terms of structure etc, I am already familiar with it, but what scares most people including me is going from few lines of code to hundreds, as you referred to strict C++.  Also would steer clear and not use anything around the .NET framework or requiring a dependency on a person running my game.  :P  That was the whole idea behind GM to begin with, D&D for people who don't want to code and GML, an easy scripting for people who want to do more advanced stuff without having to write millions lines of code or learning C++, etc.
Basically taking this all away and telling people, if you are not an advanced C++ user, you can't use our application.

Title: Re: New Beginnings
Post by: Rusky on May 31, 2014, 09:29:03 PM
The entire GML library can be implemented 1:1 as a C++ library. Even things that specify object names can just use macros or, if you're willing to move around some arguments, templates.

The hard part is with(), the more lenient syntax, specifying objects (which could be done in an IDE with a code generator rather than a parser), etc.

The reason you think C++ takes a lot of code to do simple things is that it doesn't provide those things by default. If you put them in a library, which is most of what ENIGMA does, it's pretty much the same as GML.
Title: Re: New Beginnings
Post by: Darkstar2 on May 31, 2014, 09:31:15 PM
know that you could explain to users that the only difference between GML and C++ is only the semi-colon at the end, but i doubt they would listen to you !  ;)


Unless perhaps he means things would not change for most people, there would be 1 line functions still and they would already be defined by the C++ engine, such as this
1 line function
d3d_set_projection_ortho(...)

refers to whatever code is within

void d3d_set_projection(gs_scalar xfrom, gs_scalar yfrom, gs_scalar zfrom, gs_scalar xto, gs_scalar yto, gs_scalar zto, gs_scalar xup, gs_scalar yup, gs_scalar zup)

So basically all the hard work is already done for you by the C++ engine, you are just passing values back to it using C++ but without realising you are......

Right ? Wrong ?  Then I guess for people already using ENIGMA might not feel a difference, but people completely new to coding might thing they would have to actually code the entire process in C++ to do for example drawing of text when only 1 line of code would be needed.  Sorry about the confusion, I kinda see what Robert means, at least I hope so and all for it, so long as the process of creating a game is not complicated and requiring more time.  If it only means a structure change that's another story, it's all a matter of learning new keywords to do the same thing you did with a GML exclusive function.



Title: Re: New Beginnings
Post by: Darkstar2 on May 31, 2014, 09:40:28 PM
The entire GML library can be implemented 1:1 as a C++ library. Even things that specify object names can just use macros or, if you're willing to move around some arguments, templates.

The hard part is with(), the more lenient syntax, specifying objects (which could be done in an IDE with a code generator rather than a parser), etc.

The reason you think C++ takes a lot of code to do simple things is that it doesn't provide those things by default. If you put them in a library, which is most of what ENIGMA does, it's pretty much the same as GML.

Yes sorry about the confusion indeed, you would not need to know C++ from the grounds up as all the difficult task is handled by the engine / libraries, you are simply passing along info to C++ libraries.  So yes technically you could have the same GML functions or equivalents, but still requiring the same number of lines or less.   So basically his new engine would not need to parse and convert / generate C++ code, right ?
Title: Re: New Beginnings
Post by: Darkstar2 on May 31, 2014, 10:13:39 PM
Depends on how Rob want's to approach this. But if if were upto me it wouldn't be parsed at all.

I believe that is what he wants.

BTW, Robert since you asked for suggestions here is a list of things I would change about GM and some even about ENIGMA and would use in a new engine:

* Improved IDE, and dynamic resource handling.   Not have the entire resource trees loaded in memory upon opening a project, but having this optional, either preload all resources or dynamic, load as needed.

* Bult in documentation listing all possible functions, auto complete (optional turned on or off) (in GMS it is always on).

* Built in project analyser that goes through your project making recommendations on how to shorten code, optimise it, etc.  If it finds any error, highlighting the exact spot and offering suggestions to fix.

* Ability to disable D&D from IDE for those who want to do their entire project by code.  I personally do my entire project on code, not a single D&D.  I mention optional for the ability to enable/disable it depending on the need of whoever is using it.

* Setting automatic saving time, incremental saving, backup, etc.  as optional.  If the IDE crashed, upon restarting it would automatically load the recently saved point.

* A much improved room editor, more interactive and more control over room creation.  Ability to scale, rotate individual objects, backgrounds, tiles, etc.  Set view areas and ports numerically or visually, by adjusting and scaling an outline inside the room, on the part you want to be visible (view) and translate that to the number values needed.

* Advanced video rendering.  Rendering of video full screen, window, region, inside 2D/3D surfaces, independent of game, allowing to make interactive gaming experiences using video (MYST style games, allowing live people shot against a chromakey to be overlaid on top of your actual game graphics, etc.).

* Advanced 3D game creation, along with an interactive, 3D room editor.  Having your new engine a 2D and 3D would be a great thing, and a 3D room editor maybe like FPS Reloaded has and even better of course.

* Built-in shaders templates.  Much like particles have pre-made stuff (snow, rain, etc.)  why not have some pre-made shaders, for those who are not familiar with SL. and it would be used like the functions dealing with rain, snow, etc.  Example shader_type(water,....followed by the params)

* Bulk loading assets as separate entries.
Currently, you have to load every single bloody sprite yourself. That's fine if you have few of them.  But for huge games where you have loads of them, it would be nice to being able to bulk load them.  Currently if you do this, they will load as ONE sprite with several sub images.  With what I am suggesting, they could each be loaded as separate sprite indexes in your tree.  Of course once you select more than 1 sprite, it would ask you if you want 1 sprite with multi subimages or separate sprite indexes.  Same concept for sound, backgrounds, etc.

Followed by the option of allowing bulk object creation, instead of individually creating new objects in a tree.  For example if I highlight and select 4 sprites from the sprite tree, I would hit a key and it would automatically create 4 objects assigned to their respect sprite index.  (This falls under changes in the IDE).  As with the current IDEs it can be a pain in the arse to work with big projects.

* Allow loading external resources from raw data.  This was discussed in another topic and Harri agreed with the concept.

So instead of having sprite_add loading from disk, there could be sprite_add_from_raw or data, adding a sprite/sound/background, etc from data !

Example, if I use a single resource file and use file read commands to binary extract data from position x to position y and store it in data.  I would then use sprite_add_from_raw(data, spr_index, etc.) instead of a filename.  This would allow for amazing possibilities and avoid 1 write and 1 re-read cycle.

* interactive code ... A good way to get people to code and learn your product is provide interactive help.
Let's say I want to do something, play a sound, I would like on an option and get a menu (sound, graphics, drawing, physics, etc.....) click on the category and a tree opens, selecting what I need to do and seeing the code appear.  Much the same way you read a manual and learn, but only it is included as an interactive element.

There are probably many more ideas I have.  but will leave it at that for now.

Title: Re: New Beginnings
Post by: Darkstar2 on May 31, 2014, 11:15:55 PM
Yeah it's funny because I had initially also thought about the dropping D&D, but that all depends what he wants to target, only advanced or beginner and advanced.  Personally, I don't use any single D&D element in any of my projects, and if it were up to me I would fully encourage people to learn to build from code and I would make the transition easy and well documented.  I used D&D only for a short while and found out what a mess it  could be with bigger games, and was surprised to find out how much faster and easier it was to work in pure GML all the way than D&D, so I stopped using D&D and would never go back.
Also you are not asking your users to learn C++ but the functions you have set in your engine which are of course tied to your C++ engine libraries. 
Leaving D&D in would be better as it would pull more people in, having it optional and ability to disable from view would be great.
Instead it would be replaced by an interactive code assistant.
Title: Re: New Beginnings
Post by: Goombert on June 01, 2014, 12:10:22 AM
Yes, I've decided I am going to make this an engine for advanced users.

No drag and drop, strict C++, and an entity-component system.
Title: Re: New Beginnings
Post by: Darkstar2 on June 01, 2014, 12:57:43 AM
Yes, I've decided I am going to make this an engine for advanced users.

No drag and drop, strict C++, and an entity-component system.

I'll be glad to try it out when it's done.  Since I already am very comfortable using ENIGMA and do strictly code, no D&D, will learn it in no time.

One thing that was asked before, you mentioned many times you had no more time to devote to ENIGMA other than stability and minor fixes.  So now you are talking about a complete rewrite, that will require massive time.  Unless you already secretly was working on an engine :D  Otherwise I think it would be realistic that such a project would materialise in 2+ years MINIMUM.

Whatever it is, best of luck and appreciate many of the things done with ENIGMA and the recent fixes and all the help.



Title: Re: New Beginnings
Post by: egofree on June 01, 2014, 04:01:56 AM
Why wouldn't we compete with UE or Unity?

Making a game engine for simple games is already a huge and very difficult task, so imagine doing a competitor of UE or Unity ! I think only a company can make such a project. Do you know an open-source project similar to UE or Unity ? It is no accident you will not find such a project.
Title: Re: New Beginnings
Post by: egofree on June 01, 2014, 04:29:41 AM
Yes, I've decided I am going to make this an engine for advanced users.

No drag and drop, strict C++, and an entity-component system.

Ok, fine. Let's think about this : if you are making a project for advanced users, why such a user would use your project instead of ones already existing like Unity or Unreal engine ? These projects are already mature, stable and comes with a lot of advanced tools.

If we think about the existing creation tools for games, more or less, we can list the following types (not exhaustive) :

- Powerful languages (e.g Darkbasic, Blitzbasic), or libraries (e.g XNA) which are easy to use and are optimized to make games. From my point of view the major drawback is that they don't have an integrated IDE for managing the resources of the games (sprites and maps editors for example). This means you have find different tools, compatible with your programming environment, in order to make these resources.
- Tools (e.g Stencyl, Construct) which are made for people who don't want to program. They use visual metaphors instead. I think this is a serious limitation.
- Professional tools for advanced users (Unity, Unreal engine, etc). They take a lot of time to learn and are used mainly for complex games.

And finally we have Gamer maker. It's very easy to learn, and users can quickly make and test simple games. You have also integrated IDE for managing all aspects of the game. I think that's why, despite all its flaws, it is so successful.
Title: Re: New Beginnings
Post by: egofree on June 01, 2014, 04:40:44 AM
Why i don't like C++ ? Here is an example :  :D

Code: [Select]
float InvSqrt (float x){
    float xhalf = 0.5f*x;
    int i = *(int*)&x;
    i = 0x5f3759df - (i>>1);
    x = *(float*)&i;
    x = x*(1.5f - xhalf*x*x);
    return x;
}

Of course in all languages you can find examples of codes difficult to read, but the most horrible examples i've found are in C/C++.
Title: Re: New Beginnings
Post by: egofree on June 01, 2014, 04:44:23 AM
Same could be said about the ENIGMA project. Why use ENIGMA over GM:S?

Because it's open-source and free.
Title: Re: New Beginnings
Post by: egofree on June 01, 2014, 04:47:40 AM
You have answered your own question then ;)

Yes, but i said also :

Quote
Making a game engine for simple games is already a huge and very difficult task, so imagine doing a competitor of UE or Unity ! I think only a company can make such a project. Do you know an open-source project similar to UE or Unity ? It is no accident you will not find such a project.
Title: Re: New Beginnings
Post by: egofree on June 01, 2014, 04:55:45 AM
Concerning new ideas for your project : i think the features which are missing the most are in the IDE. The rooms editor for instance sucks. It doesn't any advanced functions to modify a group of objects or an undo method. Concerning the code editor, there is no global search. All modern IDE should have a global search function.
Title: Re: New Beginnings
Post by: egofree on June 01, 2014, 05:00:58 AM
I wouldn't imagine competing with Unity or the likes.

GM:S, Construct, etc.. for sure :)

When Rob say 'advanced users' he is not referring to Blizzard or EA, he means not kids who rely on drag and drop.

Well it depends of the definition of 'advanced users' of course.  :) If you are talking about GMS users, i doubt they would like a language like C++ (sorry to repeat myself). If we are talking 'advanced users' of professional tools, as i said before, it seems to me useless to compete against these tools.
Title: Re: New Beginnings
Post by: The 11th plague of Egypt on June 01, 2014, 07:03:54 AM
Why wouldn't we compete with UE or Unity?

Making a game engine for simple games is already a huge and very difficult task, so imagine doing a competitor of UE or Unity ! I think only a company can make such a project. Do you know an open-source project similar to UE or Unity ? It is no accident you will not find such a project.

JMonkeyEngine (http://jmonkeyengine.org/).
It's a full fledged engine (not just graphics) to make 3D games.
And they did it by recycling and integrating a lot of work done by others.
The IDE is a modded version of Netbeans, for example.
The pathfinding system is a port of Recast (https://github.com/memononen/recastnavigation), and they are planning on making it a simpler wrapper to reduce maintenance work. Etc.
It's written in Java (with C++ bindings under the hood) and BSD licensed.

LibGDX (http://libgdx.badlogicgames.com/index.html)
Not 3D, but a strong competitor to Unity and UE on the 2D field.
They integrate LWJGL (http://lwjgl.org/)and Box2D (http://box2d.org/).
They use Gradle  (http://www.gradle.org/)to compile and deploy to the shitload of platforms they support.
Oh, and they don't do IDEs, they just let you use the IDE you like.
It's written in Java (with C++ bindings under the hood) and Apache 2.0 licensed.

The only guys I know that are trying to make everything from scratch are the Enigma guys.
With less successful results.
Title: Re: New Beginnings
Post by: egofree on June 01, 2014, 07:25:08 AM
The 11th plague of Egypt:

Yes, but all these engines don't have an IDE which manages the resources of the games (like a maps editor for example). I guess some people don't care, but i care !

Edit :
As i said in a previous message, for 'beginners' you find a lot of excellent tools, but without an IDE dedicated specially for games, or you have tools like Stencyl, with all the tools needed to make sprites and maps, but which don't have programming languages. And in the middle you have ENIGMA, which does have an easy programming language and IDE which manages resources.
Title: Re: New Beginnings
Post by: Goombert on June 01, 2014, 10:41:32 AM
Ok, a couple of things.

1) XNA, BlitzBasic, DarkBasic are all proprietary.
2) BlitzBasic, DarkBasic, and XNA are not very modern.
3) XNA is C#
4) 99.99% of the time your C++ code would not look any different, lol, you guys keep failing to understand this, just because you can use C++ doesn't mean you have to use pointers, you've coded in GM fine for years without pointers, and just because all of the sudden you can use pointers, doesn't mean you have to, it just means that you can if you want and you can also learn to write your games more efficiently that way, but overall the difference does not affect you except provide you with more power, why do you guys keep failing to recognize this?
Title: Re: New Beginnings
Post by: edsquare on June 01, 2014, 11:21:13 AM
Yes, I've decided I am going to make this an engine for advanced users.

No drag and drop, strict C++, and an entity-component system.

Count me out for about two or three years before daring to try it.  :(

Why not both settings like lonewolf proposed?

Begginers with all the bells and whistles

Advanced with just the code editor

Even advanced users take advantage of something like GMS to do quick prototypes, if you, as an advanced user, can do both in the same ide with the same engine; you would save much more time!
Title: Re: New Beginnings
Post by: Darkstar2 on June 01, 2014, 12:26:33 PM
And finally we have Gamer maker. It's very easy to learn, and users can quickly make and test simple games. You have also integrated IDE for managing all aspects of the game. I think that's why, despite all its flaws, it is so successful.

Spot on !  GM had the potential of being so much more, but YYG came along and turned it into rubbish, to some extent, does not mean it is not good enough for a certain market, but there is another market looking for more, advanced stuff, and now they adopt a "let our users make stuff we were supposed to and enjoy the $$$" let's see how many said "extensions" will be worthy or start selling .....

Perhaps it's that  most GM users don't realise all the flaws in GM because they are not advanced or they don't make advanced games.  Or they settle for mediocrity.

@Lone
Quote
Same could be said about the ENIGMA project. Why use ENIGMA over GM:S?

That's an easy one to answer.
#1) It's FREE! It's OpenSource you can tweak it, modify it as you want.
#2) Non interpreted nature!  It is a C++ engine, it compiles your games, no dealing with gay runners.  Smaller files, faster games!
#3) For advanced users allows C++ in your projects, includes unique set of functions as well (EDL).
#4) Developers who listen and go out of their way to HELP, and who fix as much as they can any bugs / issues, even though they are severely understaffed.
#5) For windows developers especially, includes most functions that were deprecated from GMS for silly, unjustified reasons because of laziness !
there are probably more reasons too.

Title: Re: New Beginnings
Post by: Goombert on June 01, 2014, 12:47:46 PM
My only complaint with ENIGMA is the fact that it is sexually confused.

Anyway I am thinking of keeping the object resource for my spinoff and allowing sources and headers to be added with a simplification of the instance system allowing it to be easily coded giving you more control.

I am not sure if any of my ideas will come to fruition or not.
Title: Re: New Beginnings
Post by: Darkstar2 on June 01, 2014, 01:00:54 PM
My only complaint with ENIGMA is the fact that it is sexually confused.

Do elaborate ! :D

Quote
Anyway I am thinking of keeping the object resource for my spinoff and allowing sources and headers to be added with a simplification of the instance system allowing it to be easily coded giving you more control.

I am not sure if any of my ideas will come to fruition or not.

How long do you think this could take you ?  I've mentioned minimum 2+ years and that is being generous.  How long do you expect to do this, alone........  If you can pull this off, then someone should sign you up right away and hire you ! :P

I know of another project that was crowd funded, has an entire team and years later they still are working on it.  So how the bloody hell are you going to pull this off anyway, alone when you mentioned you barely have time to take care of ENIGMA ?

Either way, I am always willing to try something new and will be glad to take your new engine for a spin when it's done, assuming it's done on time before the end times :D
Title: Re: New Beginnings
Post by: egofree on June 01, 2014, 01:28:24 PM
Ok, a couple of things.

1) XNA, BlitzBasic, DarkBasic are all proprietary.
2) BlitzBasic, DarkBasic, and XNA are not very modern.
3) XNA is C#......

Not very modern ? Do you know when C++ was created ? 1983 ! Very modern indeed !  :D (Hey, Robert i am just teasing you !  ;) )
More seriously, i was talking about these tools and languages not to say we should imitate them, but to see what type of tools are available and to understand why GM is so successful.
As you said you don't care about the compatibility of GM, i was wondering if it's really necessary to make a new games engine. It seems that there is already a lot of excellent games engines existing, but very often they don't come with an optimized IDE for games. What about making instead a new IDE for one/or several existing game engines. Just thinking...
Title: Re: New Beginnings
Post by: egofree on June 01, 2014, 02:01:13 PM
I was talking about interesting game engines. For example Microsoft has dropped support of XNA, but a new open-source project has been made : Monogame. (c.f http://en.wikipedia.org/wiki/MonoGame). The repository is here : https://github.com/mono/MonoGame. I didn't test yet, but at first glance it seems very interesting. It is a modern framework based on a well know framework made by MS, it is cross platform (OS, Android, Mac OS X, Linux, Windows, and PS4 soon !) and for the programming language, you can use the .Net languages. As i understand, what is missing is an IDE similar to GM Studio.

Edit:
For the IDE, you have the following choices:
MonoGame for VisualStudio
MonoGame for MonoDevelop Windows
MonoGame for MonoDevelop Linux
MonoGame for MonoDevelop Mac
Title: Re: New Beginnings
Post by: edsquare on June 01, 2014, 02:56:19 PM
I was talking about interesting game engines. For example Microsoft has dropped support of XNA, but a new open-source project has been made : Monogame. (c.f http://en.wikipedia.org/wiki/MonoGame). The repository is here : https://github.com/mono/MonoGame. I didn't test yet, but at first glance it seems very interesting. It is a modern framework based on a well know framework made by MS, it is cross platform (OS, Android, Mac OS X, Linux, Windows, and PS4 soon !) and for the programming language, you can use the .Net languages. As i understand, what is missing is an IDE similar to GM Studio.

Edit:
For the IDE, you have the following choices:
MonoGame for VisualStudio
MonoGame for MonoDevelop Windows
MonoGame for MonoDevelop Linux
MonoGame for MonoDevelop Mac

Actually what is missing (Much more important than a friendly IDE) is a full content pipeline that works on other OS than Windows and without the need to install VisulStudio and XNA on windows!

The addin they have for linux needs the newer monodevelop, which you have  to compile in several steps since you cant compile it in the version most distros provide; you need to compile two or three versions in order to get it working, and learn how to have two or more mono versions working in your system without breacking it!

Also if you want to use monotouch or compile for ios your closed source game you need to buy the licence!
Title: Re: New Beginnings
Post by: Rusky on June 01, 2014, 05:08:30 PM
Darkstar2's suggestion of a menu/interactive manual/whatever is essentially Construct's system. It seems to work pretty well for them- it's very discoverable (like he suggested), it's easier to use than D&D, and it's just as powerful as textual programming.

On visual metaphors: They are not necessarily limitations, and in fact can be much more powerful than textual programming, for two reasons:

1) Your brain has a massive chunk of itself dedicated to visual processing and pattern recognition. Static text limits that to OCR, while interactive visual representations of programs and logic can display information in different and often more helpful ways. Do you prefer tables of numbers or graphs when trying to understand a dataset? Visual programming can un-hide things like variable contents, data flow, possible control flow paths, and patterns over time, which are completely invisible in static textual programming.

2) You have a massively powerful CPU not only to run your game, but which you are using to program it. It is, like your visual cortex, vastly underutilized by your text editor. You can spare a few CPU cycles to compute things about your code so you can display the patterns I talked about in point 1. How many times have you had to sit and think through something about your code that a computer could've just automatically displayed for you? (Or, how many times have you shotgunned and tried random things because you didn't understand why your code didn't work).

On competing with Unity, et al: why put arbitrary limits on what you can achieve? If you have concrete ideas about how you can improve on those tools, why not try them out? You don't have to put in all the effort they did, on all the same things, if you're improving the interface, for example. What's to say you can't grow into a bigger project or turn into a company?