ENIGMA Forums

General fluff => General ENIGMA => Topic started by: TheExDeus on July 25, 2015, 09:20:55 PM

Title: ENIGMA progress
Post by: TheExDeus on July 25, 2015, 09:20:55 PM
Introduction
I wanted to make a topic about changes in ENIGMA. Forum has been quiet for a while and nothing much has been going on. But I'm still here and still working on ENIGMA. So some of the stuff done in the past few months will be described here.

TL;DR
At least 40 bug fixes. At least 297 new functions (about 262 for BasicGUI extension). Texture atlas which can increase FPS up 24x. A much more mature GUI extension. 64bit compilation for windows. ENIGMA not dead.

Texture atlas
It took years, but ENIGMA is officially as powerful as any decent engine in the beginning of last decade. :D We have texture atlas (or as GM call them - texture pages). It basically packs several sprites into one texture, so there isn't any expensive texture changes. This is extremely useful for 2D games and GUI/UI/HUD, as they usually involve a lot of 2D textures. This is less important for 3D games.
Previously a code like this was the worse case scenario for ENIGMA:
Code: (EDL) [Select]
int i = 0;
repeat (10000){
        int spr = spr_0;
        switch (i){
                case 0: spr = spr_0; break;
                case 1: spr = spr_1; break;
        }
        draw_sprite(spr,-1,random(room_width),20+random(room_height)-20);
        ++i;
        if (i>1) i = 0;
}

draw_set_font(font_0);
draw_text(10,10,string(fps));
draw_text(10,30,"The quick brown fox jumps over the lazy dog");
Here 10k sprites are drawn, but they change image one after the other. So in reality there are only two images - 5k times one is drawn and 5k times the other. Here one sprite is a green pentagon and the other sprite is a red one. Here is a screenshot:
(http://i.imgur.com/9R7nztQ.png)
You can see I only get 23FPS here. Reason for that can be seen here:
(http://i.imgur.com/DDOBqk1.png)
We can see in one frame we call 70k OpenGL functions. We actually call 10k draw calls (one for each sprite) as well as 1 for the text. So it's 10001 draw calls to draw the frame. You can also the there are 4 textures in memory and one of them is visible in the image (the red pentagon).
To use texture atlas I added a few new functions. Right now it is useable at runtime (unlike GM which can only be used in the IDE), so this is the code required:
Code: (EDL) [Select]
texture_page = texture_atlas_create();
texture_atlas_pack_begin(texture_page);
texture_atlas_pack_sprite(texture_page, spr_0);
texture_atlas_pack_sprite(texture_page, spr_1);
texture_atlas_pack_font(texture_page, font_0);
texture_atlas_pack_font(texture_page, -1);
texture_atlas_pack_end(texture_page);
That is easy right? We create a texture atlas page, then add two sprites and two fonts (including the default -1 one) and then _end(). In the _end() it actually does the packing. It is very efficient and uses the Josh's rectpack which we already used for fonts. Specifying a size for the atlas texture is optional and it is calculated automatically to be the smallest power-of-two texture it can be. After calling this code the texture looks like this:
(http://i.imgur.com/inE0ySm.png)
You can see we only need 12 OpenGL function calls per frame and there is actually only one draw call. There is only one texture as the rest were merged and destroyed. The packed texture is on the right. Now the fonts and sprites can be used as normal and nothing changes, so existing code works fine. You can also see that the font characters are packed per character, not per font texture, so spaces between sprites are packed with fonts. Unlike GM which is quite wasteful (can be seen here (http://docs.yoyogames.com/source/dadiospice/001_advanced%20use/more%20about%20backgrounds/texturepage.png)).
This is the output for the example after running the texture_atlas code:
(http://i.imgur.com/wLanNBc.png)
We get 560FPS instead of 23FPS. That is 24.3x speed up (2430%). This works in DX9, GL3 and GL1 graphics systems and you can pack sprites, fonts and backgrounds (so all textural resources in ENIGMA).

TODO:
1)This only works in code and is not implemented in LGM. I like it that way, but it would be useful for LGM to pack textures too so I wouldn't have to do it at runtime (which is extremely fast, but could still be a slowdown with thousands of sprites). Allowing to do it at runtime does seem important, as you can now even pack sprites you loaded externally. GM doesn't allow that.
2) There could be a few more options added, like padding. The system also doesn't check if a texture is already packed (if you try to pack the same sprite twice the result is undefined now). And lastly we could allow the same texture to be packed multiple times. So you could optimized the atlas at runtime. Like if you had a desert world it could be packed together with UI. Then the next ice world could also be packed with UI so you can draw as much as possible with one draw call.

BasicGUI improvements
Those who don't know BasicGUI is an extension I'm making for ENIGMA. It adds GUI stuff like windows and widgets. They are not meant to be external of the main window, so they are all drawn inside. Useful for game UI or editor UI. The extension includes windows, buttons, labels, toggles, scrollbars, sliders as well as skins, groups and parenting. It is inspired by Unity system, but it is a little verbose because of EDL limitations. So right now the extensions consists of 262 functions.
As simple example:
(http://i.imgur.com/se3Us23.gif) (http://imgur.com/se3Us23)
This shows windows, group toggles (basically radio buttons), sliders, buttons with child labels (the button with the "Lena" picture), scrollbars and labels (the larger "Lena" picture). I get 6600FPS here because I also packed everything into a single texture. This would draw in one draw call if it weren't for a stencil buffer I used that will be described later.
Another example is the node editor I'm working on.
(http://i.imgur.com/juc56DI.png)
Everything you see there is drawn using the BasicGUI extension (excluding the connecting curves, which are drawn using draw_bezier_cubic_color() function). I get 2430FPS and I also use atlas here, so here is the texture:
(http://i.imgur.com/dFdYz0w.png)
It takes a lot more OpenGL function calls here because I use surfaces and stencil buffers for cutting stuff off outside BGUI window. If I would hide those windows and not draw surfaces, I would be able to draw the whole thing in one draw call. It is a lot more cooler in action, so if I make a video of it I will post it here. The BasicGUI extension is graphics system agnostic - it uses only generic drawing functions and should work for all graphics systems that implement them. Now they are GL1, GL3 and DX9.

TODO:
1) Add textbox widget.

64bit for Windows
I say "for Windows", because I think Linux and MacOS had this working for some time now. But on Windows there had to be some few fixes for this to work. There is actually performance reasons to compile in 64bits, because it can increase fps. Like here (press to enlarge):
(http://i.imgur.com/I8jkrPZ.png)
The only difference is that one is compiled in 32bits and the other in 64. The difference is not large (about 4%), but it is still 100fps. 64bit of course uses a little more memory. 32bit uses 29.8mb or ram while 64bit uses 32.1mb.
Here is the atlas test:
(http://i.imgur.com/fCMVrWx.jpg)
Here we also get almost 100fps or about 14%. 32bit uses 50.9mb while 64bit uses 57mb.

All in all this is great. 64bit's of course also mean we can use more than 2GB of ram. Most 2D games don't care about the 2GB limit and most 3D games rarely hit it too (AAA games of course do). I'm dealing with a lot of data not connected with games and so for me the possibility to use more than 2GB is very useful.

TODO:
1) Compile the rest of libraries to 64bit and create a new windows installer which has these libraries. Right now I only compiled the libffi, so I can compile a game. I need to compile OpenAL, ALURE, Box2D and some others.

Stencil buffer
I added some simple stencil buffer functions. They are primarily used in the GUI system so that windows cut off content that is outside of it. It's like using surfaces to do it, but without the additional VRAM. A simple example:
Code: (EDL) [Select]
repeat (5000){
        int spr = spr_0;
        draw_sprite(spr,-1,random(room_width),20+random(room_height)-20);
}

d3d_stencil_start_mask();
draw_circle(room_width/2,room_height/2,room_height/2,false);

d3d_stencil_use_mask();
repeat (5000){
        int spr = spr_1;
        draw_sprite(spr,-1,random(room_width),20+random(room_height)-20);
}

draw_set_font(font_0);
draw_text(10,10,string(fps));
draw_text(10,30,"The quick brown fox jumps over the lazy dog");
d3d_stencil_end_mask();
And the output:
(http://i.imgur.com/cdMUZYb.png)
What happens here is that I draw 5000 red sprites. Then I start the stencil mask and draw a circle on it. Then I use the mask to draw the rest 5000 green sprites and the text. The green sprites and the text is limited to the circle I drew. So it is masking which pixels can be written to. This works in GL1 and GL3.

TODO:
1) The functions need to be changed so we can use several values in the stencil mask.

Fixes
-Fixed normal matrix. commit (https://github.com/enigma-dev/enigma-dev/commit/1a287d3b450188d990d5aca998b81d104d1d3831)
-Model_floor and model_wall fixes (changes necessary because of normal matrix change). commit (https://github.com/enigma-dev/enigma-dev/commit/23104111fe95c7dca0ad34cc2135d4f1b78f7c03)
-fixed sprite_create_from_screen and background_create_from_screen. commit (https://github.com/enigma-dev/enigma-dev/commit/6d2f9fc0958ec05c5e4205f39942e3ac82b07e77)
-Direction is now rounded. Fixes a problem where vspeed = 5, made direction = 269 instead of 270. commit (https://github.com/enigma-dev/enigma-dev/commit/0e358861fba53e7b6898df3696e94fc4fb2a3948) issue (https://github.com/enigma-dev/enigma-dev/issues/933)
-Added the maximize button if window resizing is enabled. commit (https://github.com/enigma-dev/enigma-dev/commit/a9f9238a2f50e423c567c50059b8e6765717d214)
-Fixes string_width(" "). Previously if the string only consisted of spaces, then string_width() returned 0. commit (https://github.com/enigma-dev/enigma-dev/commit/33c32b39f02ba552bd57dc9b40b35a5baffc8f14)
-Fixed definition of draw_set_line_pattern. commit (https://github.com/enigma-dev/enigma-dev/commit/8f93a49f5c6cbe5529932099d23705a3e7e33963)
-Fixed double define for draw_spline_part with wrong arguments. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Removed glsl_program_bind_frag_data from header. It was never implemented and I cannot even find out what it is (it's not a GM function either). commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Added definitions for font_get_glyph_texture_left/top/right/bottom. They were implemented, but not defined. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Remove matrix_ functions and d3d_transform_vertex which were not implemented. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Remove export_include_file,  discard_include_file and include_file_location as they were not implemented. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Added empty functions for d3d_set_software_vertex_processing in GL. Software processing is idiotic anyway, but D3D supports it, and I need to make a stub until we make platform specific functions easier to implement. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Fixed d3d_model_part_draw() definitions - they missed vertex_start argument. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Removed display_get_orientation as it hasn't been implemented (we don't even support devices with orientation right now). commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Removed joystick_map_button and joystick_map_axis from PFjoystick.h, as they are not implemented in Windows, but they are added in Linux. As they are defined in LINUXjoystick.h, then I guess they still should work on Linux. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Fixed sound_get_pan and sound_get_volume return's. commit (https://github.com/enigma-dev/enigma-dev/commit/5b0fbbe60228e09fb5141f6c2f6468ff57ae4bf8)
-d3d_draw_torus is now defined properly. commit (https://github.com/enigma-dev/enigma-dev/commit/5b0fbbe60228e09fb5141f6c2f6468ff57ae4bf8)
-Removed duplicate draw_mandelbrot define. commit (https://github.com/enigma-dev/enigma-dev/commit/5b0fbbe60228e09fb5141f6c2f6468ff57ae4bf8)
-Fixed room_get_name. For all resource get_name function the default return value was "<undefined>", but room_get_name is implemented differently. It isn't declared in IDE_EDIT like the rest. And when given incorrect room index it would just crash in non-debug version, so I made it return "<undefined>" in this case instead. commit (https://github.com/enigma-dev/enigma-dev/commit/a08bde2ea9809c615d9bcefb29342d5ed6f94db5)
-Surfaces are now using unordered_map instead of regular arrays of pointers. This was causing a memory issue (Dr. Memory crashed on "new surface"). This is more C++ way anyway. commit (https://github.com/enigma-dev/enigma-dev/commit/f7a4b9f71bb8bbdf6ba4329a091cdaf439ed1329)
-Fixed bug in the new surface creation, where I actually increment surface_max count even though the id itself was reused. commit (https://github.com/enigma-dev/enigma-dev/commit/50a8fea0c13d9181384e62da74f030d5a1f865a6)
-Fixed memory leak in graphics_copy_texture. commit (https://github.com/enigma-dev/enigma-dev/commit/f1973f1e4fb337f11ef620cf37d08cf41305a392)
-graphics_copy_texture now correctly crops the image. commit (https://github.com/enigma-dev/enigma-dev/commit/f1973f1e4fb337f11ef620cf37d08cf41305a392)
-Fixed the font packer so it would return power-of-two textures. commit (https://github.com/enigma-dev/enigma-dev/commit/f1973f1e4fb337f11ef620cf37d08cf41305a392)
-Some small optimizations in GSbackground. It's very possible compiler on O3 did that anyway. commit (https://github.com/enigma-dev/enigma-dev/commit/ad5a63a7d3d6b5c5ff2eff991bbdd2733e161190)
-Removed some warning from GL3textures.cpp. commit (https://github.com/enigma-dev/enigma-dev/commit/ad5a63a7d3d6b5c5ff2eff991bbdd2733e161190)
-Removed GSEnable.h and corresponding .cpp files. They are not used anywhere and they implement functions that are already in d3d_ category. commit (https://github.com/enigma-dev/enigma-dev/commit/7813dcd76a91a47fa43e00ef804086508fd82122)
-Fixed .obj loading. There was an error that when you load an .obj with normal values, but without texture coordinate values, then the normals were all messed up. This is now fixed in GL1 and GL3. commit (https://github.com/enigma-dev/enigma-dev/commit/96eec230f48ac8786bf88ba82aae320efd150fcd)
-Fixed d3d_set_fill_mode not drawing in GL3. commit (https://github.com/enigma-dev/enigma-dev/commit/60f4b33d1ac3bbc10cbf366764eff544fc00ad04)
-Added NOCHANGEDIR flag to dialogs. Previously the get_open_filename and get_save_filename dialogs changed working directory. It was messing with some other stuff and as we cannot change working directory with any built-in function right now, then I don't think this was intended. So I added a flag that forbids changing of the directory. commit (https://github.com/enigma-dev/enigma-dev/commit/f2c584d3be52e92c539b0f6757e4afa9ea037389)
-Disabling zwrite now works correctly in GL3. commit (https://github.com/enigma-dev/enigma-dev/commit/625465360ef7a938e30ce45818fd3c75d7dfed13)
-Widgets now compile for 64bit. Some code in win32 widgets needed to be changed so it would compile for 64bit. commit (https://github.com/enigma-dev/enigma-dev/commit/c1f1ae697dd57eef910c693df4b334d19cb9530c)
-Windows widget rc files don't show warning anymore. They were because of the manifest.xml include, but I added include guards in the files themselves just as additional measure. commit (https://github.com/enigma-dev/enigma-dev/commit/76d2f096ec215aa3edb1c416a282ecf421c0f00d)
-Fixed the for loop in makefile that dealt with windows resources (rc files) as it didn't run on cmd. It was made for sh.exe or something like that, but we can't use it. commit (https://github.com/enigma-dev/enigma-dev/commit/642ba867d5f3d170c857752818278525d65a14f8)
-It is not possible to pass flags to make. This is required to set SHELL=cmd in windows. It fixes problems described here: http://enigma-dev.org/forums/index.php?topic=2488.0 commit (https://github.com/enigma-dev/enigma-dev/commit/642ba867d5f3d170c857752818278525d65a14f8)
-Recpack had a limit of 255 rectangles it could pack. That is way too low for a texture atlas which can have thousands. So I fixed that. Texture atlas also had to be changed for this to work. Now the limit is an "max unsigned int". commit (https://github.com/enigma-dev/enigma-dev/commit/bcadaec40b15c2ef19833b0c6a7e97ea392508db)
-For 64bit's we need to pass a flag to windres. I added this to the e-yaml's and compiler, so it is possible to pass it. commit (https://github.com/enigma-dev/enigma-dev/commit/35dc5ade8e2739c5e186867d34e58191bc491aa8)
-The compiler is now compiled with -O3 which does make the parsing faster. commit (https://github.com/enigma-dev/enigma-dev/commit/35dc5ade8e2739c5e186867d34e58191bc491aa8)
-Built-in shader is now a C++11 raw literal. This makes it easier to maintain and copy, as we don't need those damn quotes and newlines. commit (https://github.com/enigma-dev/enigma-dev/commit/50a8fea0c13d9181384e62da74f030d5a1f865a6)

Added or implemented
-Added room_first and room_last. commit (https://github.com/enigma-dev/enigma-dev/commit/8f93a49f5c6cbe5529932099d23705a3e7e33963)
-Quadratic bezier curve now uses width given by draw_set_curve_width(). commit (https://github.com/enigma-dev/enigma-dev/commit/6eabf52e7df56c48175c8c0f85afab6c66fe0cb4)
-Implemented font_get_glyph_left/top/right/bottom. They were fined but not implemented. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Implemented triangle_area, which was defined, but not implemented. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Implemented sound_get_pan and sound_get_volume in OpenAL, both of which were defined. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Implemented display_get_gui_height and display_get_gui_width. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Implemented date_get_week and date_inc_week. Apparently I missed it when I wrote the thing in 2011. 4 years later, it's in (though not ISO). commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Implemented mp_grid_clear_cell which was clearly missing. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Implemented sprite_get/set_bbox_mode. This was also done in the .dll. commit (https://github.com/enigma-dev/enigma-dev/commit/75cab17c6bcf5202f88171298aa93dadeee59844)
-Implemented d3d_light_set_ambient and d3d_light_set_specularity in GL1. commit (https://github.com/enigma-dev/enigma-dev/commit/5b0fbbe60228e09fb5141f6c2f6468ff57ae4bf8)
-Added graphics_copy_texture() which is required for texture atlases. commit (https://github.com/enigma-dev/enigma-dev/commit/50a8fea0c13d9181384e62da74f030d5a1f865a6)
-Added graphics_copy_texture_part. This is also needed for texture atlas, as I need a way to copy only part of the source texture in fonts. commit (https://github.com/enigma-dev/enigma-dev/commit/f1973f1e4fb337f11ef620cf37d08cf41305a392)
-Added functions d3d_stencil_start_mask, d3d_stencil_use_mask and d3d_stencil_end_mask which allow easy use of stencil masking. commit (https://github.com/enigma-dev/enigma-dev/commit/eadeef26b10642c98a8a1c77a6b002398a5d9d08)
-Added d3d_transform_set_array and d3d_projection_set_array which take pointer to an array to set the 16 values. commit (https://github.com/enigma-dev/enigma-dev/commit/396a3eeb062e34a931ad5310947b313e2aed8d14)
-Added d3d_transform_add_array, so you can add an array as well as set it. Same with d3d_projection_add_array. commit (https://github.com/enigma-dev/enigma-dev/commit/76d2f096ec215aa3edb1c416a282ecf421c0f00d)
-Added at least 262 BasicGUI extension functions.
-Added 7 texture atlas functions.

And many more smaller fixes here and there. All of this is in this branch: https://github.com/enigma-dev/enigma-dev/tree/GL3.3NormalMatrix

Next for ENIGMA
I plan to work more on the stuff here as well as other interesting and useful features. But sadly I don't know how much I can do alone. There are not active developers right now besides me. One soar point is the parser. It was mostly written and rewritten by Josh, but he is not that interested in ENIGMA anymore. So there is no one that can actually fix the many bugs and issues we have with the parser. I propose changes to the EDL to make the parser a lot simpler, like getting rid of the dynamically added variables. All variables local to an instance will have to be declared as "local". This is actually a small change that would break little, but could fix a lot of problems we have now with std::maps crashing in the parser. I don't need - or even want - GML compatibility. Or GM compatibility in general. We don't need people porting stuff from GM to ENIGMA. We need people making stuff on ENIGMA. Seeing as GM is slowly dying anyway, I don't think we need to follow them. I would like if EDL was much more closer to c++ and it might as well be a little more strict.
Another problem is the IDE. LGM on Windows is extremely unstable. I have to restart it 5 times before the Run button actually runs, otherwise it just freezes. egofree mentioned he might be free at the end of this month and look into it. I heard others have continued to work on NaturalGM, but it doesn't have a commit since last year, so it does seem dead. Together with RadialGM and other IDE's.

So I might end up making a branch from ENIGMA. In it I would try replacing the parser with something much more simple (as I would basically need instance system to work and that is it) and the IDE. That of course is still a lot of work which I don't have resources for to do alone. I will probably make a separate topic about.
Title: Re: ENIGMA progress
Post by: TheExDeus on July 25, 2015, 09:25:01 PM
Reserved for future updates.
Title: Re: ENIGMA progress
Post by: time-killer-games on July 26, 2015, 12:17:38 AM
ya, the day enigma drops gm compatiblity, the day i delete it and my account, and many others will when they get that news after its happened, whenever they visit here again, as they rarely do enough as is. "they" as in the whole comminity who use enigma outside of staff, contributers, and darkstar2. "they" may not post or log in often, but "they" make up quite if chunk of this small community..

but hey thats life. not always gonna be fluffy pink clouds and rainbows.
Title: Re: ENIGMA progress
Post by: TheExDeus on July 26, 2015, 08:50:07 AM
Besides you I have seen nobody who cares about GM compatibility. There have been people here who wanted to port their GM games to ENIGMA, but they apparently didn't have problems using ENIGMA in first place. We gain nothing from GM compatibility. Originally the plan was that it would somehow attract people from GMC. That hasn't happened. So we must attract people from game development community in general. ENIGMA wouldn't be massively complex in any case - I want it to be as easy to use as GM, but trying to achieve a one click compatibility has in many ways ruined ENIGMA. We had to put up with so much YYG stupidity that it made the code awful and inconsistent. I want the IDE to function almost the same, together with the new EDL being close to the current one. I don't plan to remake ENIGMA into something totally different, like Josh talked about some "finite state machine editor". I agree that we could make a node system to help development, but we shouldn't drop EDL or coding.

So one-click GM compatibility - which we never achieved in most cases by the way - is a dead dream. We need it so people coming from GM feel at home and start coding instantly. But we don't need their projects to be ported without hassle. It is much easier to start from scratch. And seeing as GM and ENIGMA allows high-quality games to be made in a few weeks, the amount it takes to recreate something is quite minimal. It's not like a switch from JavaScript to Python or something. It's like a switch from C to C++.
Title: Re: ENIGMA progress
Post by: polygone on July 26, 2015, 11:04:43 AM
Well it's pretty clear that a general development of ENIGMA is dead. I think ENIGMA will stand now solely as something the odd developer may come across and find useful and as such wish to contribute to purely for their personal benefit of wanted functionality. This is how many a developer has been so far anyway. So there is no issue really with ExDeus or any other dev branching and progressing it how they wish, I would be very surprised if anybody joins in and helps with such a branch off though but you never know.
Title: Re: ENIGMA progress
Post by: egofree on July 26, 2015, 02:47:39 PM
You've done a really impressive work TheEdeux. Thanks a lot. For the IDE, as i said already, since early august i will work on the stability problem and try to fix.
Title: Re: ENIGMA progress
Post by: Darkstar2 on July 27, 2015, 12:04:12 AM
ya, the day enigma drops gm compatiblity, the day i delete it and my account, and many others will when they get that news after its happened, whenever they visit here again,

Speak for yourself mate. Harri gets my FULL 10000% support, I think his views are the best that could happen to ENIGMA.  What's wrong with learning something new, considering ENIGMA has and will retain the same ease of use - but just won't be tied with limitations and other crap, and sadly, in my opinion I do think GM compatibility has to go, if we want to see ENIGMA stand out, be unique and solid.
I'm all for the changes proposed, long overdue, and what a shame that Josh wants nothing more to do with ENIGMA......This is an issue with open source.....you have developer make stuff, break stuff, and then they fuck off, leaving the shite behind !

Good work Harri, brilliant, keep us in the loop, you're the best.  It would be great also if we can get more frequent stand-alone updates to the EXE and with updating the documentation with all the new functions.

What bloody use is to keep GM compatibility is it impacts on ENIGMA and many of it is broken, would you rather a half baked product or one that stands out and works better ?
Those who want half baked and limited, can continue using GM, YYG made a lot of positive changes to GM anyway why bother porting...... For those of us who want BETTER, faster, smaller and more feature rich whilst at the same time learning C++ and having more control, ENIGMA shines.
The only turn off with ENIGMA is its rubbish IDE that is bloody unstable, (actually the enigma.jar component, not the IDE itself).  Time to move on, change is good! GM is dying and is so outdated.  Right now they are clearly focusing on mobile !!! fucking mobile !

What Harri is proposing is heading in the right direction and right now he's alone and still ambitious, shocking ! 1 developer, anybody else would have simply left !  YYG is going in a different direction with GMS 2, don't you think ENIGMA should also go into a different direction - with GMS2 around the corner ENIGMA GM compatibility will be so fucking irrelevant anyway.
I think the timing is great and couldn't be better to cut the cord from GM's sticky knob.......

Title: Re: ENIGMA progress
Post by: time-killer-games on July 27, 2015, 12:19:13 AM
would like to apologise TheExDeus. your right, a lot of ppl dont agree with me about that. enigma being different is much better than no enigma at all. The changes you are making are great, they may not be gm compatible, but they are still great things the engine needs. sorry about that. i need to get my head on straight.
Title: Re: ENIGMA progress
Post by: Darkstar2 on July 27, 2015, 12:23:24 AM
At least 40 bug fixes. At least 297 new functions (about 262 for BasicGUI extension). Texture atlas which can increase FPS up 24x. A much more mature GUI extension. 64bit compilation for windows. ENIGMA not dead.

Very impressive there nice read.  I can already think of many good uses for the GUI functions......Something only GM folks can only DREAM of, short of buying rubbish extensions that don't do even a fraction of that.

One thing that would be nice, buffering function, like for example  reading binary data storing it in a variable, and allowing functions like sprite_add/sound_add, etc, to add from memory instead of disk.
Example sprite_add_from_memory(spr1, xyz)
where xyz is the variable containing the binary data for the sprite and spri1 index.
and some more OS specific functions like total memory, memory left, memory used by the running game, type of gpu, cpu, etc.

Quote
Next for ENIGMA
the parser a lot simpler, like getting rid of the dynamically added variables. All variables local to an instance will have to be declared as "local". This is actually a small change that would break little, but could fix a lot of problems we have now with

I agree with that.  Like that idea.

Quote
I don't need - or even want - GML compatibility. Or GM compatibility in general. We don't need people porting stuff from GM to ENIGMA. We need people making stuff on ENIGMA.

Words of wisdom, and agree 100% !
Besides with big changes YYG is heading for, porting will be irrelevant and so outdated.  Time to actually shine and be better and faster. (in more ways :D)

Quote
Seeing as GM is slowly dying anyway, I don't think we need to follow them.

I agree, this whole acquisition is big sham in my opinion, and in the end people will find out why it was never a good idea for a gambling company to have put its nose in GM....I think it's obvious what interests they are after and where they are heading.

Quote
Another problem is the IDE. LGM on Windows is extremely unstable. I have to restart it 5 times before the Run

lol you're lucky, in my case sometimes it closes taking away everything with it. It is an unstable piece of shite ! from the beginning.....It's actually
the enigma.jar component that is unstable.  Use the IDE without the enigma plugin it will be stable.
I think we should get rid of this bloody plugin and simply make compiling EXTERNAL and use externally saved resources instead of memory to memory, I think this is where GMS got it right, why save your project in 1 file when you can save it using folders and files and pass the external files instead..... an external module (separate to the IDE) would take care of this......

Nice update and thanks :D

Title: Re: ENIGMA progress
Post by: TheExDeus on July 27, 2015, 08:34:46 AM
Quote
Well it's pretty clear that a general development of ENIGMA is dead. I think ENIGMA will stand now solely as something the odd developer may come across and find useful and as such wish to contribute to purely for their personal benefit of wanted functionality. This is how many a developer has been so far anyway. So there is no issue really with ExDeus or any other dev branching and progressing it how they wish, I would be very surprised if anybody joins in and helps with such a branch off though but you never know.
I think ENIGMA has the potential to be a better game development tool/engine than at least 80% out there. I think GM isn't bad design wise, but people are used to tools and editors these days. That is what GM and ENIGMA is really lacking. People want built-in animation editors, shaders editors (ala Unreal4 node one), particle editors, sound editors, 3D world editors, UI/HUD editors and so on. We sadly are low-level enough not to provide that, even though we still allow easy use of all these features. I have no problems creating a node based shader editor or a UI/HUD editor in ENIGMA itself. But then we need a way to tie that with the IDE. This is where LGM creates problems. The only way this can work now is if the editors are external .exe's which LGM calls. Like for editing sprites.

Quote
Thanks a lot. For the IDE, as i said already, since early august i will work on the stability problem and try to fix.
Thanks! Looking forward to it. As Darkstart2 mentioned, the problem is probably in the enigma.jar plugin. Copying the resources in memory seems to be broken somewhere.

Quote
would like to apologise TheExDeus. your right, a lot of ppl dont agree with me about that. enigma being different is much better than no enigma at all. The changes you are making are great, they may not be gm compatible, but they are still great things the engine needs. sorry about that. i need to get my head on straight.
No problem. You do represent part of community we need to take into account. No matter how small. That is why I propose dropping GM compatibility, but that doesn't mean it will be totally different from GM. I know most people don't agree with me, but I like LGM/GM method of development - I would like to preserve that. We just need to allow custom resources, new editors for those resources and modified EDL.

Quote
One thing that would be nice, buffering function, like for example  reading binary data storing it in a variable, and allowing functions like sprite_add/sound_add, etc, to add from memory instead of disk.
Example sprite_add_from_memory(spr1, xyz)
They are not that hard to do, but we don't really support pointers to memory, which causes some problems with this. Just like we don't support returning arrays. So I can create "sprite_add_from_memory(spr1, xyz)" now, but there is no way to fill xyz with data.

Quote
and some more OS specific functions like total memory, memory left, memory used by the running game, type of gpu, cpu, etc.
This is something I also looked into, but I couldn't find a cross-platform way of doing it. I will search some more, as I also need these.
Title: Re: ENIGMA progress
Post by: time-killer-games on July 27, 2015, 08:47:09 PM
also while 64x bit may have not been as much work as adding all those functions, thats quite the impact too, a lot of windows users rely on game engines which only support 32 bit natively. So thats a huge plus that we have 64 bit windows now as well. Very exciting! :D now we can take advantage of those additional bits!
Title: Re: ENIGMA progress
Post by: Darkstar2 on July 27, 2015, 10:49:47 PM
also while 64x bit may have not been as much work as adding all those functions, thats quite the impact too, a lot of windows users rely on game engines which only support 32 bit natively. So thats a huge plus that we have 64 bit windows now as well. Very exciting! :D now we can take advantage of those additional bits!

I wonder on the increase in speed
for games with lot of scripting,
array manipulation, file access,
calculations, AI etc, you know the
non GPU stuff, I guess we could
expect some speed increase :D

I do a lot of authoring and video work on my PC and most software I use now is native 64bit, so it will be a nice addition to have a 64bit game engine.
If I understand correctly, at this current stage we will need to have both the 32bit and 64bit versions installed in parallel right ? Perhaps
eventually adding the selection in the
IDE would be nice.
Title: Re: ENIGMA progress
Post by: Wendigo on July 28, 2015, 03:53:27 AM
I'm so pleased that enigma isn't dead. Really like the new changes. Many thanks for your efforts.
Personally I don't care at all if enigma is compatible with Game Maker. When I found this engine I didn't even know about GM.
My biggest concern though (as already mentioned) is the stability of LGM. Good usability/stability of the tools (IDE) is way more important than a huge set of features imho.

Unfortunately my knowledge of C++ is very limited so touching the code would probably do more harm than good but I would be glad if I could be of help in another way.
Title: Re: ENIGMA progress
Post by: TheExDeus on July 28, 2015, 09:04:40 AM
Quote
I wonder on the increase in speed for games with lot of scripting, array manipulation, file access, calculations, AI etc, you know the non GPU stuff, I guess we could expect some speed increase :D
I was actually a little surprised by the speed increase. I knew it must be there, but usually the reported figure is in like 5% range max. Here I could get up to 15% increase in GPU heavy stuff. In a real game who knows, you could get more.

Quote
If I understand correctly, at this current stage we will need to have both the 32bit and 64bit versions installed in parallel right ? Perhaps eventually adding the selection in the IDE would be nice.
We already provide MinGW64 with the installer. It can compile both 32bit and 64bit, so you won't need two compilers or two ENIGMA's. The choice is provided in the IDE via the Compiler setting.
(http://i.imgur.com/chjqL4A.png)
The only thing I need to do is recompile the libraries in 64bit (which is not that easy) and create a new installer. Then anyone should be able to just choose the bitness in the settings and compile.

Quote
Unfortunately my knowledge of C++ is very limited so touching the code would probably do more harm than good but I would be glad if I could be of help in another way.
LGM (the IDE) is written in Java. That is one of the biggest reasons why I haven't been able to help in that front either. If it was C++ I would probably have been on it a long time ago. I also know how to debug C++ a lot better than Java, so it would be easier for me.
Title: Re: ENIGMA progress
Post by: Goombert on July 31, 2015, 01:07:26 AM
Very nice work Harri I like seeing the contributions you have been making. I am still too stressed out for ENIGMA development. I am working on something very cool right now on my vacation that I hope you will all enjoy very much, a lot simpler than ENIGMA but something you may not be thinking of. However some of the ideas are based on previous prototypes which I am not sure if I've shared.

And for anybody afraid to contribute you shouldn't be, ENIGMA is a great way to not only learn game development but to learn game engine development. I had never used Java before I joined the forums and most would say I really turned LateralGM around. I was not completely new to C++ either but I was fairly novice and managed to accomplish a number of tasks in the engine. It really only takes the perseverance but it is still a lot of work regardless of how much you know.

What's a better way to learn game development than GameMaker? I'll tell you the answer and it's by building GameMaker itself. The opportunity has presented itself, it's right here and it's called enigma-dev.org
Title: Re: ENIGMA progress
Post by: The 11th plague of Egypt on August 01, 2015, 05:27:29 AM
Quote
Next for ENIGMA
the parser a lot simpler, like getting rid of the dynamically added variables. All variables local to an instance will have to be declared as "local". This is actually a small change that would break little, but could fix a lot of problems we have now with

I agree with that.  Like that idea.

Quote
I don't need - or even want - GML compatibility. Or GM compatibility in general. We don't need people porting stuff from GM to ENIGMA. We need people making stuff on ENIGMA.

Words of wisdom, and agree 100% !
Besides with big changes YYG is heading for, porting will be irrelevant and so outdated.  Time to actually shine and be better and faster. (in more ways :D)

Quote
Seeing as GM is slowly dying anyway, I don't think we need to follow them.

I agree, this whole acquisition is big sham in my opinion, and in the end people will find out why it was never a good idea for a gambling company to have put its nose in GM....I think it's obvious what interests they are after and where they are heading.

If we could at least keep GM compatibility up to GM 8.1/GMS 1.4, that would be great.
A lot of work has been done on studying and supporting the .gml file format, and it would be nice not to throw it all away.
The importer is still there, right?
Freeze the GM(S) support to a specific version and move on.
There are a lot of GML examples around, and remaking all those tutorials may not be as easy as it sounds :eng101:
Title: Re: ENIGMA progress
Post by: onpon on August 01, 2015, 07:13:24 AM
Considering a large portion of Game Maker files can't even be run by ENIGMA... yeah, I don't think worrying about compatibility is worth it. Keeping use of ENIGMA and LateralGM similar to use of Game Maker is probably worth it, on the other hand.
Title: Re: ENIGMA progress
Post by: The 11th plague of Egypt on August 01, 2015, 08:38:33 AM
Considering a large portion of Game Maker files can't even be run by ENIGMA... yeah, I don't think worrying about compatibility is worth it. Keeping use of ENIGMA and LateralGM similar to use of Game Maker is probably worth it, on the other hand.
Of Game Maker files, or Game Maker Studio files?
Last time I checked, most GM files worked fine.
Title: Re: ENIGMA progress
Post by: onpon on August 01, 2015, 10:47:50 AM
The binary ones. I don't remember what I've tried other than this (http://sourceforge.net/projects/bowserlaststand/) and older versions of it, but none of what I've tried has worked. I think it's deleting stuff that confuses ENIGMA's compiler, isn't it? That must be a pretty common action.
Title: Re: ENIGMA progress
Post by: Josh @ Dreamland on August 01, 2015, 10:58:21 AM
I'm impressed, Harri. I don't have much else to say.
Title: Re: ENIGMA progress
Post by: time-killer-games on August 02, 2015, 03:38:16 AM
@onpon sorlok has gotten a lot of huge games built for gthe gm5/6/7/8 era working quite nicely on windows mac and linux, hes contributed a lot but got busy so its cool we have Harri to sub in the meantime, as enigma needs a lot of its own features too, i like the idea of port gm projects, but ppl who port their projecmts to enigma will want to make them better in enigma without re-writing much, so that were the enigma features harri is putting will also come to great use, bringing in ppl to make the full switch to enigma rather than just porting a game to enigma when bored saying, "hey, it actually works, cool beans" and moves on. I think its good we have a ballence. Enigma can be its own engine, but i find keeping support for at least up until 8.1 being the biggest thing as far as the basic functiobality, all the most important stuff, and when it comes to file format, 1.4 gmx is good enough. They "un-obsoleted" a lot of shit they got complaints for removing in gms, and yeah all my projects from gm81 ported over to studio just fine, as i dont really use any of that weird shit liket he cd functions, etc. Just the essentials.

also my game flippy biard multiplayer hd works out of the box now no questions asked. really cool. and my torture of tge afterflesh f ame which is my biggest and more serious project right now, a 3d game btw, can be played from start to finish with no problems at all except some ones with the graphics and view port, but theres not that much problem with that surprisingly, and i dont think it would take that many lines of code to f u x if the problem and solution is known agead of time without trial and error tweaking that can make more bufs, esp if not tested and launched in a new official commit release. Just my two cents at this point. There isnt mych lect to do with gm compatible regarding what i personally find essential, other than a crap liad of bug fixes. depends on what your game uses. If its uses all the shit that is currently proken, then forget it. I feel to be one of the luckier ones with that fortunately. Just depends on priorities and how much gm compatibilty gets in the way in contrast with how much ut would actually draw in more ppls desire to use the the engima game engine. (Y)
Title: Re: ENIGMA progress
Post by: TheExDeus on August 02, 2015, 03:14:56 PM
Quote
If we could at least keep GM compatibility up to GM 8.1/GMS 1.4, that would be great.
I don't plan on dropping file formats, like gmk, gm6 and so on. They are already implemented and nothing can change for them. They will not be able to save some stuff like .egm can (right now even). When I talk about compatibility I mean function compatibility and language compatibility. Like EDL supporting stuff GML doesn't and maybe not supporting something GML does.

Quote
Of Game Maker files, or Game Maker Studio files?
I think one of you talks about the file formats (loading a game in LGM) and the other talks about actually compiling and running. ENIGMA didn't achieve that level of compatibility with GM that many games ran without changes, though it did achieve compatibility that 99% loaded in the IDE.

Quote
I'm impressed, Harri. I don't have much else to say.
Thanks.

Quote
.4 gmx is good enough.
I think we need to fix and improve .egm. I already use it everywhere, but more things should be supported. Like room shouldn't be in binary and we need to support an extracted format for version control (like gmx). Technically .egm can be totally backwards compatible all the time if we manage to save everything in xml or other description language. Right now the only compatibility problems can come from the binary room data. I am still not sure why nobody has changed that, as it was discussed previously. And seeing as we already support xml's, then doing a change should be trivial. Heck, copy 90% of GMX room description if you have too. Just be more consistent than them and support all the stuff we do.
Title: Re: ENIGMA progress
Post by: onpon on August 02, 2015, 03:28:54 PM
Indeed, I was talking about compiling with ENIGMA, not opening in LGM.
Title: Re: ENIGMA progress
Post by: time-killer-games on August 02, 2015, 08:02:35 PM
@harri and onpon, i mention the compiled side of things too (how the game compiles and runs without errors with little or no bugs to notice off hand at runtime), and gave examples of specific games, most which are huge, and how well the work, which is close to perfect. sorry for the long post im not concise and need to be aware of that next time i post. :)
Title: Re: ENIGMA progress
Post by: BPzeBanshee on August 05, 2015, 12:51:58 AM
Seems there's a few elephants in the room here in this discussion. This may sound cynical but reading what's here I'd like to put my few cents in as well.

I'm all for taking .egm into the future with regards to breaking compatibility here and there so long as one can transfer the bulk of say, a GMK project and get it working with some alterations. GM8.x to GMS wasn't a painless process either and with features like BGUI it'd yield additional functionality without stupid sandbox restrictions. I was initially concerned about DLL compatibility with audio engines but looking closer with what ENIGMA provides there isn't that much of a need to use one, it's very functional as it is and much more so than legacy Game Maker.

As for GM compatibility in general, let's not pretend it ever really was the limelight goal of ENIGMA to make a complete stupidity-included GM clone. LateralGM maybe, but not ENIGMA. The potential *is* here to make a game creation engine inspired by GM's environment, but the biggest barriers that remain to bar people from taking serious interest in this project is not the compatibility (that's no.2) but actually getting the f**king IDE to work. Random crashes every 20 minutes, crashes when you press a button after doing a few compiles, modifying folder names to get it to start, modifying commandline arguments, having different versions of Java, error messages that give you no damn clue as to where things went wrong, etc all get in the way of providing a painless experience that both Mark Overmar's Game Maker and the new YoYo/PlayTech Game Maker provides. This combined with the licensing shenanigans is what's holding up adoption of the project.

Compatibility *was* a big deal once upon a time, when simple projects like my Warbird wouldn't behave because object inheritance and alarms were completely unsupported and graphical pipeline changes meant a build one week would display fine and next week have a big black triangle covering half of it and display everything in the wrong shade of colour. That stuff last I checked is long gone, with some of the remaining issues fixed I see has been listed in this very thread!

I feel the remaining barrier to compatibility here at this point (with exception given to unsupported functions that are also unsupported in GM:Studio) is exclusively ENIGMA's parser. The same parser that decided GMOSSE wasn't going to work because apparently the alarms I coded in GM8.0 aren't the same alarms it supports, because I did something slightly unusual in some Draw event and it panicked, because I don't even know what thanks to the completely useless error messages. Perhaps a strip-down of said parser as TheExDeus suggested may actually be a good thing to work towards this end-goal, start from scratch and build up as you say, have a fork of it for certain purposes and someone else can do another fork for GM-specific support, I don't know. Doesn't seem like anyone wants to touch the parser in its current state and I have next to zero C++ knowledge compared to my GML knowledge.
Title: Re: ENIGMA progress
Post by: time-killer-games on August 05, 2015, 08:41:04 PM
Seems there's a few elephants in the room here in this discussion. This may sound cynical but reading what's here I'd like to put my few cents in as well.

I'm all for taking .egm into the future with regards to breaking compatibility here and there so long as one can transfer the bulk of say, a GMK project and get it working with some alterations. GM8.x to GMS wasn't a painless process either and with features like BGUI it'd yield additional functionality without stupid sandbox restrictions. I was initially concerned about DLL compatibility with audio engines but looking closer with what ENIGMA provides there isn't that much of a need to use one, it's very functional as it is and much more so than legacy Game Maker.

As for GM compatibility in general, let's not pretend it ever really was the limelight goal of ENIGMA to make a complete stupidity-included GM clone. LateralGM maybe, but not ENIGMA. The potential *is* here to make a game creation engine inspired by GM's environment, but the biggest barriers that remain to bar people from taking serious interest in this project is not the compatibility (that's no.2) but actually getting the f**king IDE to work. Random crashes every 20 minutes, crashes when you press a button after doing a few compiles, modifying folder names to get it to start, modifying commandline arguments, having different versions of Java, error messages that give you no damn clue as to where things went wrong, etc all get in the way of providing a painless experience that both Mark Overmar's Game Maker and the new YoYo/PlayTech Game Maker provides. This combined with the licensing shenanigans is what's holding up adoption of the project.

Compatibility *was* a big deal once upon a time, when simple projects like my Warbird wouldn't behave because object inheritance and alarms were completely unsupported and graphical pipeline changes meant a build one week would display fine and next week have a big black triangle covering half of it and display everything in the wrong shade of colour. That stuff last I checked is long gone, with some of the remaining issues fixed I see has been listed in this very thread!

I feel the remaining barrier to compatibility here at this point (with exception given to unsupported functions that are also unsupported in GM:Studio) is exclusively ENIGMA's parser. The same parser that decided GMOSSE wasn't going to work because apparently the alarms I coded in GM8.0 aren't the same alarms it supports, because I did something slightly unusual in some Draw event and it panicked, because I don't even know what thanks to the completely useless error messages. Perhaps a strip-down of said parser as TheExDeus suggested may actually be a good thing to work towards this end-goal, start from scratch and build up as you say, have a fork of it for certain purposes and someone else can do another fork for GM-specific support, I don't know. Doesn't seem like anyone wants to touch the parser in its current state and I have next to zero C++ knowledge compared to my GML knowledge.

Im having a sore thoat and thus, *coughs out "viewport and graphical issues" again* lol

and i use gms as my ide and could still use gm 8.1 as my primary ide either way its not much different, so i dont need lgm at all, but would be super cool if that worked on its own, without the crashes the quote above also reiterated quite nicely, some of which mention by darkstar before, and the earlier points by myself.

long live enigmas big fat harri sausage! :p

edit:

almost forgot, gm and gms have ide's that are fully functional for free, so lgm is completely garbage and thats why no one uses it, lgm being free isnt why one should use it, that the argument to use enigma partially, but not lgm at any level. The reason to use lgm is 100% the same reason as the other half of why to use enigma's compiler and not GM's, and thats the funxtions and features engima has which gm gms do not. Making sense? So if enigma is a gm clone and thats all itll even be, put lgm in... the garbage can, as we already have two great ide's that will always work and be a lot better, in that said secenerio, but.. If we are to make enigma stray away from the compatubily of gm and gms at any level, whether whole or in part, it is vital that lgm doesnt crash and works at all, otherwise we cant stray away from gms and gm related stuff at all. Make sense?
Title: Re: ENIGMA progress
Post by: Wendigo on August 06, 2015, 02:16:30 AM
Well for Linux users like myself there is no way around LGM. It runs quite solid on Linux by the way, there are hardly any crashes.
Title: Re: ENIGMA progress
Post by: time-killer-games on August 06, 2015, 02:26:19 AM
^My point exactly wendy, the crashing is primarily a windows issue. GM and GMS ide's only run on windows so yeah. Ive never had it crash once on my ubuntu OS before, personally. At least, not from what i can remember, its been a while since ive used that harddrive..

I guess it could vary depending on the linux disro, but i doubt it.

Not to mention wine runs both YYG ide's on linux too, then compile outside of wine using enigma's compiler. (Many have tried GM with wine and reported is works as it should).

Wine for Mac OS X however may be a different story as its a lot earlier in the development stages and is still a lot buggier even today, so ive heard.
Title: Re: ENIGMA progress
Post by: Goombert on August 07, 2015, 05:28:47 AM
Yeah Windows is a large part of ENIGMA's problems. The OS has no package manager like any sane Linux distribution and every Linux distro comes with a C++ compiler generally. On Linux ENIGMA just utilizes the package manager to install OpenGL and other libraries but on Windows we have to ship the whole freaking MinGW compiler, plus all of its binaries that ENIGMA does not even use, plus all of the libraries ENIGMA uses but MinGW does not. That much really is a Windows problem and also a C++ problem because C++ has no standard ABI. This means you generally can't build C++ programs with one compiler and then link C++ code from another compiler. Such as writing Visual C++ dll's that are linked from a MinGW compiler. This means when you write a class in C++ the vtable or virtual table which holds all the pointers to the classes methods can be layed out in memory differently between each compiler, because C++ does not standardize how the implementation should work. The C++ standard only defines what the implementation of any standard function does not how it does it. This can even lead to problems linking C++ binaries to other C++ binaries that were produced with different versions of the same compiler.

https://en.wikipedia.org/wiki/Virtual_method_table
https://en.wikipedia.org/wiki/DLL_Hell
https://en.wikipedia.org/wiki/Application_binary_interface

This is also why I do not update the ENIGMA zip anymore because it's 100mb's and takes me an hour to upload which is a complete waste of time. We were going to make the server do this automatically but nobody has the time or interest to set that up.

Anyway I agree with BPzeBanshee, I really have no idea what this discussion or argument is about but I totally do not care. However I agree with him in that nobody wants to use ENIGMA because of how big a pain in the ass it is. This is especially true because of what I just mentioned above. These largely result from our use of JNA to communicate LateralGM's plugin with ENIGMA's C++ compiler interface. Related to the problems I specified above is the reason why a 64bit Java installation will not work when LateralGM is coupled with ENIGMA. I would also like to point out that because of the way Eclipse works it also does not work between different architectures of Java, so 32 bit Eclipse only works on 32 bit Java. But ENIGMA does not even have a 64 bit version on Windows because of the OS's above mentioned problems and the complete rubbish that is MinGW64 on Windows. It's a total nightmare to go and build this thing and that's why nobody wants to do it.

That aside if you take LateralGM and use it by itself without the ENIGMA plugin you rarely have problems but it is about as slow as GM8.1 with loading projects because both it and GM8.1 use managed languages (Delphi.NET and Java). This is also what a command line interface would solve because LateralGM and the Java Runtime would not have to link to ENIGMA at all and would not have to give a crap what architecture or compiler it was built for it would just pass command line arguments to it and be done. It's not even that these problems can't be worked around without a CLI it's just that nobody has the time or interest to do them and it's a lot of work to really do it correctly.

This is why I continued to package LateralGM separately from ENIGMA and why I feel it should continue to be done that way. LateralGM works great on its own and it's a wonderful and very stable program by itself with a lot of applications including recovering projects in niche cases that old and new GM versions can't handle.
Title: Re: ENIGMA progress
Post by: TheExDeus on August 07, 2015, 07:51:34 AM
Quote
I was initially concerned about DLL compatibility with audio engines but looking closer with what ENIGMA provides there isn't that much of a need to use one, it's very functional as it is and much more so than legacy Game Maker.
Technically a lot of DLL's should work too, but they haven't really been tested. I think the FMOD audio extension relies on a DLL originally made for GM and it worked. This hasn't been tested much though.

Quote
As for GM compatibility in general, let's not pretend it ever really was the limelight goal of ENIGMA to make a complete stupidity-included GM clone. LateralGM maybe, but not ENIGMA.
I think long ago ENIGMA really did start as "Open Source GM". It wasn't meant to have more or better features, just the possibility to add them. So for a time GM compatibility was pursued quite zealously, even adding GM5 compatibility (trough an extension though).

Quote
That stuff last I checked is long gone, with some of the remaining issues fixed I see has been listed in this very thread!
Yeah, it should be a lot more stable these days, but there are still problems with regressions. We don't have integration testing, so it is often possible for things to break.

Quote
Yeah Windows is a large part of ENIGMA's problems. The OS has no package manager like any sane Linux distribution and every Linux distro comes with a C++ compiler generally. On Linux ENIGMA just utilizes the package manager to install OpenGL and other libraries but on Windows we have to ship the whole freaking MinGW compiler, plus all of its binaries that ENIGMA does not even use, plus all of the libraries ENIGMA uses but MinGW does not. That much really is a Windows problem and also a C++ problem because C++ has no standard ABI. This means you generally can't build C++ programs with one compiler and then link C++ code from another compiler. Such as writing Visual C++ dll's that are linked from a MinGW compiler. This means when you write a class in C++ the vtable or virtual table which holds all the pointers to the classes methods can be layed out in memory differently between each compiler, because C++ does not standardize how the implementation should work. The C++ standard only defines what the implementation of any standard function does not how it does it. This can even lead to problems linking C++ binaries to other C++ binaries that were produced with different versions of the same compiler.
This isn't as big of a problem you put it to be. First, Windows 10 finally has a built-in package manager, so looking forward to that. Second, there really isn't that big of an issue of providing mingw in an installer together with "Additional". I think the current method works quite good.

Quote
This is also why I do not update the ENIGMA zip anymore because it's 100mb's and takes me an hour to upload which is a complete waste of time. We were going to make the server do this automatically but nobody has the time or interest to set that up.
I'm willing to do that. I think you even posted some tutorial or something how you did it, so if you could link it then I will start doing it. Internet isn't a problem where I live and 100mb's is really not an issue speed wise. Only need to find a good place to host - I think hosting on Dropbox isn't the best way. Maybe we have a way to host on ENIGMA's website? I don't know how much space we have though, Josh should know.

Quote
But ENIGMA does not even have a 64 bit version on Windows because of the OS's above mentioned problems and the complete rubbish that is MinGW64 on Windows. It's a total nightmare to go and build this thing and that's why nobody wants to do it.
I can compile ENIGMA (the plugin) on 64bit, but of course the LGM stuff needs to be changed too in that case.

Quote
That aside if you take LateralGM and use it by itself without the ENIGMA plugin you rarely have problems but it is about as slow as GM8.1 with loading projects because both it and GM8.1 use managed languages (Delphi.NET and Java). This is also what a command line interface would solve because LateralGM and the Java Runtime would not have to link to ENIGMA at all and would not have to give a crap what architecture or compiler it was built for it would just pass command line arguments to it and be done. It's not even that these problems can't be worked around without a CLI it's just that nobody has the time or interest to do them and it's a lot of work to really do it correctly.
Yeah, finish the CLI would be a good start. I think the only big thing missing there is rasterization of fonts? All the other things are either done or should be easy.

Title: Re: ENIGMA progress
Post by: time-killer-games on August 08, 2015, 09:40:09 PM
raymond married debora long before i met amy, they have a healthy marriage while me and amy just broke up. I got gored by a bull in the rear, the crazy frog lady who i had escape from out her window, and dads disgusting nudist lodge, everyone makes fun of that quirk i have with silverwear, raymond still has my foam finger, mom ignores me and dad actually get along with my brother sometimes, of all the sad misfortunes i have address amoung many more not addressed, one hated outshines all the rest combined, and double baby. I absolutely hate how EVERYONE LOVES MY HARRI'ER BROTHER RAYMOND!

nobody cares robert. see what i did there?

(https://dl.dropboxusercontent.com/u/79893663/memes/14070756372d4f1-150x84-1.jpg)
Title: Re: ENIGMA progress
Post by: time-killer-games on August 08, 2015, 10:43:18 PM
@BPzeBanshee

i believe the elephants are stomping so loud that they still can't hear us, which is odd bc u cant hear text u read it and they can read everyone else's sext just fine but we all know why that is, the reason is unfortuneate

this is why all the new members run away, the devs think for themselves and not what actually matters, the audience, the ppl who would want to use it and grow the community, not just the contributors, which would be the minority of members in most open source game engine communities. Here the game engine's devs themselves and the contributors is what the whole community is made of, like, 5 ppl, and theres a reason for that, which i just explained again in this here post

expect the community to grow at all with only the current staff's interests considered? trust me, this will die before its out of beta the road its heading. Ive tried staying positive but dang.

y'all need Shrek..

(https://dl.dropboxusercontent.com/u/79893663/Drawings/misc/(ch33ky_scrub_slave)11374137_1620003304937541_2132409468_n.jpg)
Title: Re: ENIGMA progress
Post by: TheExDeus on August 09, 2015, 07:11:41 AM
TKG: Please, post offtopic in the offtopic forum only. And it cannot actually "die" if the only ones interested in the project is developers. It can die if the only ones interested in the project are the users from community. I agree that a lot of things need to change, like releases, the site, more bugfixes instead of features and so on. But that is not done by one person alone.
Title: Re: ENIGMA progress
Post by: Goombert on August 09, 2015, 07:45:36 AM
Quote
This isn't as big of a problem you put it to be. First, Windows 10 finally has a built-in package manager, so looking forward to that. Second, there really isn't that big of an issue of providing mingw in an installer together with "Additional". I think the current method works quite good.
I've seen it already and I don't think I care, it will take some time for it to take effect either way. I really would just rather use Linux which solved all of these problems a long time ago. I don't switch to Linux full time because I really do need things like Word which does happen to be more reliable than Google Doc's or Open/Libre Office. While I may be exaggerating the problems they are very real and I think you are undervaluing them. There are a large number of complaints about C++ but most of them Bjarne Stroustrup dismisses except for a standardized ABI. I don't mind coding in C++ at all and I did make a number of substantial improvements to ENIGMA's engine including starting that model class (though I've learned much more C++ since then) but this really turns me off from trying to build cross-platform applications or applications to be distributed in the language.
http://www.stroustrup.com/slashdot_interview.html
Quote from: Bjarne Stroustrup
The compatibility with C at the system interface level has encouraged people to use C-style strings, arrays, and structs, where they would have been better off with some higher-level abstractions presented as classes or templates. Instead of leaving the low-level facilities at the system level and within the implementations of classes, people have let the low-level constructs - and pointers to them - permeate their designs. Type errors, wild pointers, array bounds errors, and memory leaks are the obvious results. Lots of macros and casts often adds to the obscurity of the code. It saddens me to see some of the unnecessary messes people get themselves into.

This is why I still really honestly like Java besides its amazing new MVC GUI API called JavaFX (which I am building some of my prototypes in). Java is still amazing in that you can generally build quick cross-platform applications, build them once, and deploy anywhere. This idiom only gets broken when you try to mix it with native code like ENIGMA which really sucks, it is the lowest common denominator, and gives you the benefits of neither Java nor C++. Regardless I agree with Mr. Stroustrup 100% on everything he's said there.

Quote from: TheExDeus
I'm willing to do that. I think you even posted some tutorial or something how you did it, so if you could link it then I will start doing it. Internet isn't a problem where I live and 100mb's is really not an issue speed wise. Only need to find a good place to host - I think hosting on Dropbox isn't the best way. Maybe we have a way to host on ENIGMA's website? I don't know how much space we have though, Josh should know.
The topic is pinned in "General ENIGMA" and I would appreciate it if someone else would build the ZIP occasionally. Josh could obviously give you FTP access to the server but I've just realized that we could just upload these to GitHub directly if Josh enables it on the repository. He does it this way for Calico (click "Releases"). I think we should upload the ENIGMA binary releases directly to GitHub since that is a standard/more common approach.
https://github.com/enigma-dev/Calico-Icon
http://enigma-dev.org/forums/index.php?topic=1399.0

Quote from: TheExDeus
I can compile ENIGMA (the plugin) on 64bit, but of course the LGM stuff needs to be changed too in that case.
That would be great as well because then users would at least be able to download a 32bit and 64bit version of ENIGMA and they wouldn't have to specifically install a 32 JDK/Java. You would have to recompile all of ENIGMA's plugins though and I also think you need to replace the jna.jar with the 64bit version. I hit too many errors and incompatibilities between MinGW64 and 32 and finally just gave up on packing it. It's sitting on my desktop and was the last thing I was trying to accomplish before I stopped contributing for this period of time. Largely because of my poor internet, if someone else were to begin packing the zip or just taking care of it instead of me by some standard/methodical approach as I did before it would make it easier for me to contribute to ENIGMA again in the future. I am actually mainly still interested in LateralGM's development so if I could maintain improvements and bugfixes to that and delegate the ENIGMA matters to someone else (regarding packaging LGM and everything) it would be a lot of work off my plate and free me up for more contributions to LGM.

In my honest opinion I still like ENIGMA on Linux because it just uses the package manager, you install the necessary components one time and then ENIGMA just works. You can easily replace the lateralgm.jar and the entire ENIGMA framework just as it is expected.

Quote from: TheExDeus
Yeah, finish the CLI would be a good start. I think the only big thing missing there is rasterization of fonts? All the other things are either done or should be easy.
Yes that is one thing that it needs but it is debatable whether the ENIGMA engine should provide such functionality as well, perhaps through a plugin because GM does have functions to add fonts at runtime that we never implemented and I believe Studio added TTF font support or w/e.

Quote from: TKG
@BPzeBanshee
Yes calm down TKG, you're being eccentric. You know some of the prototypes I've been working on and one of them is about to be released open source in a few days. It is a library that is a necessary component to bigger things I am developing and are ENIGMA related.
Title: Re: ENIGMA progress
Post by: TheExDeus on August 10, 2015, 04:57:38 AM
Quote
I've seen it already and I don't think I care, it will take some time for it to take effect either way. I really would just rather use Linux which solved all of these problems a long time ago. I don't switch to Linux full time because I really do need things like Word which does happen to be more reliable than Google Doc's or Open/Libre Office. While I may be exaggerating the problems they are very real and I think you are undervaluing them. There are a large number of complaints about C++ but most of them Bjarne Stroustrup dismisses except for a standardized ABI. I don't mind coding in C++ at all and I did make a number of substantial improvements to ENIGMA's engine including starting that model class (though I've learned much more C++ since then) but this really turns me off from trying to build cross-platform applications or applications to be distributed in the language.
http://www.stroustrup.com/slashdot_interview.html
Good read, but I agree with stroustup. Most of the "issues with C++" are either made up or just stems from not actually using C++. Like I work with a guy who doesn't like C++, because using STL relies you on "others people bugs", while himself writes everything in C with pointers and can hardly make code that doesn't explode. When I finally showed him how even a ranged for loop creates more optimized code than he could even write, he finally started looking more kindly on it.

Quote
The topic is pinned in "General ENIGMA" and I would appreciate it if someone else would build the ZIP occasionally. Josh could obviously give you FTP access to the server but I've just realized that we could just upload these to GitHub directly if Josh enables it on the repository. He does it this way for Calico (click "Releases"). I think we should upload the ENIGMA binary releases directly to GitHub since that is a standard/more common approach.
I will do it when I get something stable. I'm playing with compiler too now so I can pack the newest one with 64bit's, but I have problems with LGM. Like it crashes when I have a different compiler in PATH. How can that even be? It works if the /bin I point to is the one coming with the installer now, but when I point to /bin from Dragons release it just crashes on startup. I don't even compile anything with it as the .dll already exists. This kind of weird LGM stuff is something I have to deal with, but as I don't code in Java it's hard for me to debug. Maybe you can at least give we LGM and plugin with symbols? Because now it trows like 5 SIGSEV's on startup when debugging with GDB, but it has no backtrace as there aren't any symbols I guess. Lookee here: http://enigma-dev.org/forums/index.php?topic=2561.new#new
edit: It looks like I tries to call something to do with the compiler on startup whether it is needed or not, because a third compiler I tried adding in PATH made LGM trow something about incompatible .dll even though IT WAS NOT even recompiled. This is a strange behavior indeed. The thing about LGM compiling the .dll actually has never worked for me in Windows. I have always needed to do it manually trough shell. So maybe either a setting to disable this? It would make startup faster as well.

Quote
That would be great as well because then users would at least be able to download a 32bit and 64bit version of ENIGMA and they wouldn't have to specifically install a 32 JDK/Java. You would have to recompile all of ENIGMA's plugins though and I also think you need to replace the jna.jar with the 64bit version. I hit too many errors and incompatibilities between MinGW64 and 32 and finally just gave up on packing it. It's sitting on my desktop and was the last thing I was trying to accomplish before I stopped contributing for this period of time. Largely because of my poor internet, if someone else were to begin packing the zip or just taking care of it instead of me by some standard/methodical approach as I did before it would make it easier for me to contribute to ENIGMA again in the future. I am actually mainly still interested in LateralGM's development so if I could maintain improvements and bugfixes to that and delegate the ENIGMA matters to someone else (regarding packaging LGM and everything) it would be a lot of work off my plate and free me up for more contributions to LGM.
I will probably try creating both 32bit and 64bit installers. The difference only being the .jar's and .dll's. Both will come with 64bit compiler (which itself is 32bit exe) and both 32bit and 64bit "Additional's" so you can compile both from any installation of ENIGMA.

Quote
In my honest opinion I still like ENIGMA on Linux because it just uses the package manager, you install the necessary components one time and then ENIGMA just works. You can easily replace the lateralgm.jar and the entire ENIGMA framework just as it is expected.
That is great and hopefully this is how Windows10 will allow you to work. I have already mentioned that Package Manager is the only thing I really miss about Linux.

Quote
Yes that is one thing that it needs but it is debatable whether the ENIGMA engine should provide such functionality as well, perhaps through a plugin because GM does have functions to add fonts at runtime that we never implemented and I believe Studio added TTF font support or w/e.
I have looked at it and I think http://www.freetype.org/ is the way to go. I will at some point try implementing it if nobody else does.
Title: Re: ENIGMA progress
Post by: Goombert on August 10, 2015, 09:42:14 AM
Quote from: TheExDeus
Good read, but I agree with stroustup. Most of the "issues with C++" are either made up or just stems from not actually using C++. Like I work with a guy who doesn't like C++, because using STL relies you on "others people bugs", while himself writes everything in C with pointers and can hardly make code that doesn't explode. When I finally showed him how even a ranged for loop creates more optimized code than he could even write, he finally started looking more kindly on it.
Yeah, I pretty much agree as well. The only C++ arguments I've really heard are that it's difficult (totally not but a lot to learn though). I also disagree with your coworker because I encourage the use of the STL because it's written by very smart computer scientists who account for things that you may not consider and also does logarithmic growth (averages out the complexity of a resize etc etc). That's one of the benefits of using code by someone else and also that you are guaranteed for it to work specific ways across compilers and platforms. However I do kind of see his point too because I really hate waiting on JavaFX bug reports to get filed (I've filed about 20 on this new framework) and I know none of them will get fixed until JDK 9 which is a whole year from now. I was actually considering joining the OpenJDK project because I already have fixes available for the bugs I've discovered.

Quote from: TheExDeus
I will do it when I get something stable. I'm playing with compiler too now so I can pack the newest one with 64bit's, but I have problems with LGM. Like it crashes when I have a different compiler in PATH. How can that even be? It works if the /bin I point to is the one coming with the installer now, but when I point to /bin from Dragons release it just crashes on startup. I don't even compile anything with it as the .dll already exists. This kind of weird LGM stuff is something I have to deal with, but as I don't code in Java it's hard for me to debug. Maybe you can at least give we LGM and plugin with symbols? Because now it trows like 5 SIGSEV's on startup when debugging with GDB, but it has no backtrace as there aren't any symbols I guess. Lookee here: http://enigma-dev.org/forums/index.php?topic=2561.new#new
edit: It looks like I tries to call something to do with the compiler on startup whether it is needed or not, because a third compiler I tried adding in PATH made LGM trow something about incompatible .dll even though IT WAS NOT even recompiled. This is a strange behavior indeed. The thing about LGM compiling the .dll actually has never worked for me in Windows. I have always needed to do it manually trough shell. So maybe either a setting to disable this? It would make startup faster as well.
That would be ideal so the same compiler is used for both versions. I can't really say much about the random crashes that's actually all in JNA (we do not use JNI, JNI is older) if you are getting SIGSEGV. LateralGM will never throw a SIGSEGV by itself because it uses no other native code. Also in Java there is no concept of debugging symbols, the code is JIT'd to byte code which is fed to a virtual machine. Complete stack traces with the file name and line number exist for exceptions because of this. So in a way a Java application always has debugging symbols (though not really because it's a different concept). So any segmentation fault is either through invoking native code with JNA or a bug in the JVM.

Quote from: TheExDeus
I will probably try creating both 32bit and 64bit installers. The difference only being the .jar's and .dll's. Both will come with 64bit compiler (which itself is 32bit exe) and both 32bit and 64bit "Additional's" so you can compile both from any installation of ENIGMA.
That is ideal because then users can just install that compiler as well to offer a lighter weight ZIP. Not that the size matters since you are offering to upload but the download size may matter to them which is also something to consider.

Quote from: TheExDeus
That is great and hopefully this is how Windows10 will allow you to work. I have already mentioned that Package Manager is the only thing I really miss about Linux.
Yeah I was the one that originally posted it on the forums. As far as I know it is a fork of OneGet but I don't know if it's actually Microsoft developers working on it. As far as I am aware you are also unable to use it with anything but power shell. Also I feel that Windows 10 is better than 8 but 7 still trumps it for a desktop OS despite all of its fancy features that I do actually like. Some of the features I like is the package manager, return of glass/Aero theme and start button, the package manager thingy, and some others. The things I don't like are forced updates which are causing tons of problems for people including endless reboot cycles. I also do not like Apps like the Xbox one which I heard opens automatically when you start playing a game and tries to record it without you even asking it to by default. Just a bunch of annoying settings like that is why I turned around and decided not to upgrade. Not to mention the privacy of the thing, the whole OS is clearly a giant NSA playground. Call me crazy sure, I don't care if the NSA is watching me or stealing passwords or working with Microshaft to make back doors, but OMG they are so annoying about the way they do it lol.
Title: Re: ENIGMA progress
Post by: egofree on August 11, 2015, 01:08:03 PM
I didn't forget my promise to work on LateralGM. I was thinking at first to start last week, but in the end i will start tomorrow. Before trying to debug LateralGM, i will make a simple project to test how JNA work.
Title: Re: ENIGMA progress
Post by: BPzeBanshee on August 12, 2015, 08:26:24 AM
Stupid question from me and I'll shut up again: how does one actually get the GL3.3NormalMatrix branch running in Windows at the moment? I can get the normal ENIGMA seemingly fine in my existing folder but as soon as I replace the enigma-dev with the branch one, add the Windows utilities in and try to run a Hello World I get compile errors - http://pastebin.com/zzP8h44x. Am I supposed to rather overwrite the former with the latter?
Title: Re: ENIGMA progress
Post by: Darkstar2 on August 12, 2015, 07:28:37 PM
I agree with Robert, windows 10 is a fucked up mess.  I did use the tech preview and it was stable and fast, but no cunt is going to FORCE updates on me and have me reboot all the time. Sorry Micro$oft but you blokes screwed up again majorly, haven't you been listening !?!?!?! I agree, Windows 7 is still the best option for desktop OS.
Mind you I have recently upgraded to the latest stuff and a new DX12 graphic card, so I might install Winshite 10 dual boot to play DX12 games, as DX12 will offer good optimisations.

Other than that, leaving holes, forcing stuff, they are regressing these prats, not improving.  they give us back stuff but taking away some also.  There is adware and spying in win10, you lot didn't think M$ would give you a free OS for a year just like that right ?  upgrading to windows 10 is the equivalent of the mark of the beast.
What utter shite !!!
Major blow to us win7 users for making DX12 Win10 exclusive.
It's VISTA fiasco all over again!
And WTF, this xbox one rubbish and
recording games without bloody asking me, fuck you Microsoft.
Why not let your users make the decisions!!!!

Title: Re: ENIGMA progress
Post by: time-killer-games on August 12, 2015, 09:49:26 PM
My view on the win8-10 stuff - if they wouldve just stuck with windows 7 with everything the same but with better hardware and DX, my Windows experience would still be within the primary comfort zone.
Title: Re: ENIGMA progress
Post by: TheExDeus on August 13, 2015, 01:19:26 PM
Quote
Stupid question from me and I'll shut up again: how does one actually get the GL3.3NormalMatrix branch running in Windows at the moment? I can get the normal ENIGMA seemingly fine in my existing folder but as soon as I replace the enigma-dev with the branch one, add the Windows utilities in and try to run a Hello World I get compile errors - http://pastebin.com/zzP8h44x. Am I supposed to rather overwrite the former with the latter?
The error means you probably didn't copy the /Additional/ folder. That has the zlib and other dependencies ENIGMA needs. One way to get this would be pulling the git branch or downloading from git page and extracting over your ENIGMA. Note that you will need to delete the .dll as well as it needs to be recompiled (there were changes in it too).

NOTE: Trying to use this branch now will probably fail. My changes relies on newer GCC (the compiler) and MAKE. Thus if you do overwrite your current ENIGMA it is still very possible you won't be able to compile a game anymore. I will try packaging a new ENIGMA installer at some point.
Title: Re: ENIGMA progress
Post by: BPzeBanshee on August 13, 2015, 11:13:43 PM
Quote
NOTE: Trying to use this branch now will probably fail. My changes relies on newer GCC (the compiler) and MAKE. Thus if you do overwrite your current ENIGMA it is still very possible you won't be able to compile a game anymore. I will try packaging a new ENIGMA installer at some point.
Ah, this is probably my main cause for failure. Once I realised I missed the Windows dependencies I did the overwrite approach and got a different error that seemed to suggest something along those lines. I've compiled and messed around with MAME before so this might help me tinker in the right direction.

On the subject of Windows 10, as a retail worker I do not trust it. I crashed one of the display machines at JB HiFi just by navigating around with the mouse and I've already seen customers do returns on products where I work because Windows 10 screwed something up in the install process and wouldn't let them revert it back (deleting the factory default image of the system that Win8.1 uses for it's "Reset system" option is also bad jujus). Win7 and XP were pretty cagey initially though - give it a few months and we'll see how stable it is, NSA playground/control panel issues notwithstanding.
Title: Re: ENIGMA progress
Post by: HitCoder on September 02, 2015, 05:02:28 AM
I really like your futute ideas, ExDeus, and I don't see a need for GM support in all honesty, so it's all good there. I'd feel much more comfortable just from the IDE being improved, it's the only drawback with Enigma. I look forwards to future changes, and I was just thinking about your window GUI being used to make an IDE in Enigma, as I have heard suggested before. I'm not sure how I would make an IDE in Enigma that interacts with Enigma's system files however, but I honestly feel that following GM is no longer the way to go, and I would much prefer an IDE that looks more like Eclipse, or anything with tabs and an explorer panel for resources than it does as an MDI.
Then again, the comparison would be minor I guess.. I just feel like the current IDE is pretty clunky.
Aside from that, I don't use Enigma for the GM compatibility; I use it because it actually uses code, rather than D&D alone, and because it's available on Linux as well as Windows.
Title: Re: ENIGMA progress
Post by: FroggestSpirit on September 05, 2015, 08:10:25 PM
I'm a fan of LGM aside from the bugs and speed. I've always felt that it was a lot easier to organize code in it (within objects, step events, etc). I can't remember the last time I actually used the DnD functions though. I wish I knew enough to help with development, and maybe it's something I should take the time to learn, because in all honesty, I feel like portability and stability are the major pullbacks from me using ENIGMA for a full size game. It has the potential, and it's got to be the one coding software that I can work the quickest in (assuming stability). I want to see this grow, and I feel it's time to cut the ties to GM, because it can be so much more, and it already is improving quite nicely.