ENIGMA Development Environment

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   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.

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.

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.

Robert, just curious, out of all the ranges in green I posted, is this the only set that worked for you ? or are there others ? The ranges in green I tested cover a wide range.

fact remains we are only shifting the problem, and I still think there is more to this glitch.

BTW cancel the pull request........ There is something I need to resolve.

//update: Somehow there was a small mistake when I updated my ranges at the last minute forgot to edit the forum post.
Please refer again to the ranges in green I tested, I have updated them.  Unfortunately, 0.375 / 0.375  + 0.175, 0.175 GLVIEW does not work for me on lower screen res.  At 1920x1080 it did.  but not lower.  So for that range 0.3125, 0.3125 + GL VIEW 0.175 work on all screen res, I also updated the rest of the ranges.
This shit can become tricky, might work on several screen res but not others.  It can be tedious to test each resolution for each offset.

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.

 

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.    Looks like we're all headed back to our roots very soon

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. 

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.

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

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

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.   

First I am uploading an EGM, this is the projectchaos game I stripped down, removed sound, logo and kept scrolling and the black background that fades in.
I added a text display on top.  This is what I am using to test.

I have a second project I modified to allow me to dynamically sweep ranges for the ortho offsets without having to go in the CPP and recompile each time.  Of course just to recap GLScreen.cpp is untouched now, GLMatrix, d3d set projection ortho offsets are set to 0, and controlling them from the project. Only the GL MODEL VIEW offsets I change in the source after I do each range sweep. This allows me quicker testing of ranges.  I input all the GL MODEL VIEW ranges you gave me that you said worked, but I tested different ranges for the ortho.

Here are results, I won't go into details on each, to me a test that is PASS means no text glitch in window and full screen, no border, no scrolling glitch, and tested on all range of screen resolution up to native.


d3d set projcection ortho offset values
All these are X/Y offsets. These were tested with latest NVIDIA 337.88 WHQL, and all pass window and full screen.

0.00 ~ 0.375  (increments of 0.0625) -- Excluding 0.1875
with GL MODEL VIEW
0.1875

basically in all tests when the ortho is 1:1 with the model view there is text glitching.  AGAIN I stress I am talking about the weird lines next to letters and numbers, not blurriness nor am I referring to some letters appearing fatter than others, that's the result of monitor upscaling / game scaling and is NOT a problem. 

======================
d3d ortho
0.0625 ~ 0.1875  (increments of 0.0625)

with GL MODEL VIEW
0.00
======================
d3d ortho
0.00 ~ 0.3125  (increments of 0.0625) (0.375 did not fully work with lower screen res) so exclude this number in this range.

with GL MODEL VIEW
0.175
======================
d3d ortho
0.1875 ~ 0.3125  (increments of 0.0625)

with GL MODEL VIEW
0.375
======================
d3d ortho
0.0625 ~ 0.3125  (increments of 0.0625)

with GL MODEL VIEW
0.275
======================
d3d ortho
0.1875 ~ 0.375  (increments of 0.0625)

with GL MODEL VIEW
0.4
======================
GL MODEL VIEW
0.6 no go, bad range for me to test

----------------------------------------------
So surely there is something in there that works for you, I don't know what more I can do to contribute in this, I feel have provided more than enough information.

If you still have issues, I will send you a dynamic adjustment project for you to use so you can find more working ranges.

Right now I am attaching the stripped down projectchaos that I use for testing.

/side note:

I have finished testing all possible settings combinations in NVIDIA panel, none have affected outcome.  So honestly cannot explain why I saw vertical lines on scrolling backgrounds with a previous driver (335 March WHQL).