This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »
136
General ENIGMA / Re: ENIGMA progress
« 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.
137
Function Peer Review / Re: Lua Extension
« on: July 31, 2015, 04:40:38 pm »
No, it is an extension and is not meant to be in main repo. It adds an additional dependency. We should have an additional way to share extensions trough some kind of extension database which could even be integrated in ENIGMA/LGM. But until more people are making extensions the forum suffices. I also have an AngelScript extension which I won't put in the repo. I haven't shared it here either though.
138
General ENIGMA / Re: ENIGMA progress
« 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 increaseI 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.
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.
139
General ENIGMA / Re: ENIGMA progress
« 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.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.
Example sprite_add_from_memory(spr1, xyz)
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.
140
General ENIGMA / Re: ENIGMA progress
« 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++.
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++.
141
General ENIGMA / Re: ENIGMA progress
« on: July 25, 2015, 09:25:01 pm »
Reserved for future updates.
142
General ENIGMA / ENIGMA progress
« 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. 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:You can see I only get 23FPS here. Reason for that can be seen here:
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: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).
This is the output for the example after running the texture_atlas code:
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:
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.
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:
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):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:
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: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-Model_floor and model_wall fixes (changes necessary because of normal matrix change). commit
-fixed sprite_create_from_screen and background_create_from_screen. commit
-Direction is now rounded. Fixes a problem where vspeed = 5, made direction = 269 instead of 270. commit issue
-Added the maximize button if window resizing is enabled. commit
-Fixes string_width(" "). Previously if the string only consisted of spaces, then string_width() returned 0. commit
-Fixed definition of draw_set_line_pattern. commit
-Fixed double define for draw_spline_part with wrong arguments. commit
-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
-Added definitions for font_get_glyph_texture_left/top/right/bottom. They were implemented, but not defined. commit
-Remove matrix_ functions and d3d_transform_vertex which were not implemented. commit
-Remove export_include_file, discard_include_file and include_file_location as they were not implemented. commit
-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
-Fixed d3d_model_part_draw() definitions - they missed vertex_start argument. commit
-Removed display_get_orientation as it hasn't been implemented (we don't even support devices with orientation right now). commit
-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
-Fixed sound_get_pan and sound_get_volume return's. commit
-d3d_draw_torus is now defined properly. commit
-Removed duplicate draw_mandelbrot define. commit
-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
-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
-Fixed bug in the new surface creation, where I actually increment surface_max count even though the id itself was reused. commit
-Fixed memory leak in graphics_copy_texture. commit
-graphics_copy_texture now correctly crops the image. commit
-Fixed the font packer so it would return power-of-two textures. commit
-Some small optimizations in GSbackground. It's very possible compiler on O3 did that anyway. commit
-Removed some warning from GL3textures.cpp. commit
-Removed GSEnable.h and corresponding .cpp files. They are not used anywhere and they implement functions that are already in d3d_ category. commit
-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
-Fixed d3d_set_fill_mode not drawing in GL3. commit
-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
-Disabling zwrite now works correctly in GL3. commit
-Widgets now compile for 64bit. Some code in win32 widgets needed to be changed so it would compile for 64bit. commit
-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
-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
-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
-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
-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
-The compiler is now compiled with -O3 which does make the parsing faster. commit
-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
Added or implemented
-Added room_first and room_last. commit-Quadratic bezier curve now uses width given by draw_set_curve_width(). commit
-Implemented font_get_glyph_left/top/right/bottom. They were fined but not implemented. commit
-Implemented triangle_area, which was defined, but not implemented. commit
-Implemented sound_get_pan and sound_get_volume in OpenAL, both of which were defined. commit
-Implemented display_get_gui_height and display_get_gui_width. commit
-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
-Implemented mp_grid_clear_cell which was clearly missing. commit
-Implemented sprite_get/set_bbox_mode. This was also done in the .dll. commit
-Implemented d3d_light_set_ambient and d3d_light_set_specularity in GL1. commit
-Added graphics_copy_texture() which is required for texture atlases. commit
-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
-Added functions d3d_stencil_start_mask, d3d_stencil_use_mask and d3d_stencil_end_mask which allow easy use of stencil masking. commit
-Added d3d_transform_set_array and d3d_projection_set_array which take pointer to an array to set the 16 values. commit
-Added d3d_transform_add_array, so you can add an array as well as set it. Same with d3d_projection_add_array. commit
-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.
143
Issues Help Desk / Re: Linker crash
« on: July 21, 2015, 06:17:57 pm »
Okay, so I found the problem. Finding it was a journey like no other. Basically it has nothing to do with the character limit I originally thought. Mostly because there is actually no cutoff when running make. The limit is when executing a command, but for that the command is a lot shorter:
I tried Msys-bash - same thing - http://pastebin.com/SRC8YB4v . But then I noticed something - I had to install msys, I didn't have it. Together with ENIGMA we don't provide cygwin or msys - only mingw and git. When I install ENIGMA and run it historically the first thing I see is this:
Also note that windows doesn't have uname to tell which OS is running the makefile. But that is okay, as "process_begin: CreateProcess(NULL, uname -s, ...) failed." doesn't stop the makefile.
But then there is another problem. Apparently there is a syntax error in the batch for loop. So I get this:
You can find the changes here: https://github.com/enigma-dev/enigma-dev/commit/642ba867d5f3d170c857752818278525d65a14f8
In the end nothing really has to be changed on user side, as msys is still not required. We can use the mkdir that comes with git, but we just need to force SHELL=cmd, which is now done.
Took a while to figure this out.
Quote
mingw32-make.exe WORKDIR="C:/ProgramData/ENIGMA/" GMODE=Debug GRAPHICS=OpenGL3 AUDIO=None COLLISION=Precise WIDGETS=Win32 NETWORKING=None PLATFORM=Win32 CXXFLAGS="-std=c++11 -I../Additional/i686-w64-mingw32/include -g -DDEBUG_MODE" COMPILEPATH="Windows/Windows" EXTENSIONS=" Universal_System/Extensions/DateTime Universal_System/Extensions/Paths Universal_System/Extensions/NoVi Universal_System/Extensions/DataStructures Universal_System/Extensions/MotionPlanning Universal_System/Extensions/Alarms Universal_System/Extensions/BasicGUI Universal_System/Extensions/ParticleSystems Universal_System/Extensions/Timelines" OUTPUTNAME="C:/Users/Deus/AppData/Local/Temp/egm2873666830888467289.exe" eTCpath=""Which is well within the limits of cmd. The larger linker part is the output which doesn't go trough cmd as far as I know. But CreateProcess (which I assume make uses) has an argument limit of 32,768 chars so it could be an issue as well later, but not here.
I tried Msys-bash - same thing - http://pastebin.com/SRC8YB4v . But then I noticed something - I had to install msys, I didn't have it. Together with ENIGMA we don't provide cygwin or msys - only mingw and git. When I install ENIGMA and run it historically the first thing I see is this:
Quote
Running make from `mingw32-make.exe'I figured this was just a path issue, so I added the git/bin to PATH as well (as it comes with ENIGMA). This worked for years, but that apparently is the problem. In git/bin is sh.exe. Something I thought was necessary for mingw32-make to compile ENIGMA. Turns out it is the contrary - mingw32-make DOESN'T work with sh.exe. And sh.exe is the thing that is crashing here (original post is about it and the solution was here: http://www.cmake.org/Wiki/CMake_MinGW_Compiler_Issues). So I removed git/bin from PATH, but then I can't compile (the error I just posted) as it cannot find mkdir.exe for some reason. Then I went into an adventure where I found out that cmd has mkdir function and windows has mkdir program. So when I type mkdir.exe in cmd instead of running the mkdir.exe it actually creates a folder named ".exe" (as it calls the function, not the program). I couldn't figure out how to fix this, as even when calling in quotes (as suggested here: http://superuser.com/questions/856582/force-windows-use-exe-on-path-rather-than-cmd-exe-internal-command) it didn't work. Then in our own ENIGMA wiki I found that it mentions msys as mandatory, as Windows mkdir.exe is somehow inferior and doesn't allow something (http://enigma-dev.org/docs/Wiki/MinGW). So I ended up putting msys/bin in PATH for the mkdir function. But then we are back to square one, as msys/bin ALSO includes sh.exe... One way is to either delete it or rename it, but that is ugly. Another way is to specify "SHELL=cmd" to "mingw32-make" (http://stackoverflow.com/questions/24066265/force-mingw32-make-to-ignore-sh). Surprisingly we don't have a way to pass this flag to "make" in "Compilers/../gcc.ey". So I added it to CompilerSource. Now there is a makeflags: field which allows me to set SHELL=cmd and that now works.
Full command line: mingw32-make.exe Game WORKDIR="C:/ProgramData/ENIGMA/" GMODE=Run GRAPHICS=OpenGL1 AUDIO=OpenAL COLLISION=Precise WIDGETS=Win32 NETWORKING=None PLATFORM=Win32 CXXFLAGS="-std=c++11 -I../Additional/i686-w64-mingw32/include SHELL=cmd" COMPILEPATH="Windows/Windows" EXTENSIONS=" Universal_System/Extensions/DateTime Universal_System/Extensions/Paths Universal_System/Extensions/TouchSurface Universal_System/Extensions/AngelScript_Test Universal_System/Extensions/NoVi Universal_System/Extensions/DataStructures Universal_System/Extensions/MotionPlanning Universal_System/Extensions/Alarms Universal_System/Extensions/BasicGUI Universal_System/Extensions/ParticleSystems Universal_System/Extensions/Timelines" OUTPUTNAME="C:/Users/Deus/AppData/Local/Temp/egm9080526457944138510.exe" eTCpath=""
mingw32-make.exe -C ENIGMAsystem/SHELL
mingw32-make.exe[1]: Entering directory 'C:/enigma-dev-master/enigma-dev/ENIGMAsystem/SHELL'
process_begin: CreateProcess(NULL, uname -s, ...) failed.
mingw32-make.exe[1]: makefile:7: pipe: No error
mkdir.exe -p C:/ProgramData/ENIGMA/.eobjs/Windows/Windows/Run/
process_begin: CreateProcess(NULL, mkdir.exe -p C:/ProgramData/ENIGMA/.eobjs/Windows/Windows/Run/, ...) failed.
make (e=2): The system cannot find the file specified.
mingw32-make.exe[1]: *** No rule to make target 'C:/ProgramData/ENIGMA/.eobjs/Windows/Windows/Run/', needed by 'C:/ProgramData/ENIGMA/.eobjs/Windows/Windows/Run/SHELLmain.o'. Stop.
mingw32-make.exe[1]: Leaving directory 'C:/enigma-dev-master/enigma-dev/ENIGMAsystem/SHELL'
makefile:12: recipe for target 'Game' failed
mingw32-make.exe: *** [Game] Error 2
Also note that windows doesn't have uname to tell which OS is running the makefile. But that is okay, as "process_begin: CreateProcess(NULL, uname -s, ...) failed." doesn't stop the makefile.
But then there is another problem. Apparently there is a syntax error in the batch for loop. So I get this:
Quote
echo "// GENERATED RESOURCE FILE FRONTEND" > C:/ProgramData/ENIGMA/.eobjs/Windows/Windows/Run/resources.rcTurns out the loop was written for sh.exe (or some other bash) as it didn't actually execute in cmd. There were several differences, but I fixed this too. Sadly now it doesn't run on sh.exe, but that shouldn't be an issue anyway. I don't know if you can write a shell for loop that runs both on cmd and sh.exe (or cygwin or something like that).
for res in Preprocessor_Environment_Editable/Resources.rc Widget_Systems/Win32/getstring.rc Widget_Systems/Win32/getlogin.rc Widget_Systems/Win32/showinfo.rc Widget_Systems/Win32/showmessageext.rc; do echo "#include \"$res\"" >> C:/ProgramData/ENIGMA/.eobjs/Windows/Windows/Run/resources.rc; done
res was unexpected at this time.
makefile:129: recipe for target 'C:/ProgramData/ENIGMA/.eobjs/Windows/Windows/Run/resources.res' failed
mingw32-make.exe[1]: *** [C:/ProgramData/ENIGMA/.eobjs/Windows/Windows/Run/resources.res] Error 255
mingw32-make.exe[1]: Leaving directory 'C:/enigma-dev-master/enigma-dev/ENIGMAsystem/SHELL'
makefile:12: recipe for target 'Game' failed
mingw32-make.exe: *** [Game] Error 2
You can find the changes here: https://github.com/enigma-dev/enigma-dev/commit/642ba867d5f3d170c857752818278525d65a14f8
In the end nothing really has to be changed on user side, as msys is still not required. We can use the mkdir that comes with git, but we just need to force SHELL=cmd, which is now done.
Took a while to figure this out.
144
Off-Topic / Re: New Update to GMS 1.4! Big update
« on: July 14, 2015, 12:51:18 pm »Quote
What about 64bit only Windows. I think eventually Windows will be native 64bit,64bit windows does support 32bit applications and probably always will. 32bit version of an OS can be dropped though, but that doesn't mean 32bit app's won't work. 32bit support for applications will probably only be dropped when we get 128bit CPU's and OS's. Both of which will not happen in the next 5 years probably.
no more support for 32bit, so that will be an issue
for ENIGMA and GMS. I think YYG/Playtec is already prepared and they will inevitably release a 64bit version of their software.
Also, ENIGMA already supports 64bit as far as I know. There probably needs to be changes here and there, but nothing massive. The problem is allowing the user to choose as the current LGM doesn't allow it.
edit: Just tested compiling for 64bit. Everything works except the libraries we include with ENIGMA on Windows also need to be 64bit. So we need another folder in "Additional\" with 64bit. I will maybe try getting them later.
145
Off-Topic / Re: New Update to GMS 1.4! Big update
« on: July 13, 2015, 06:25:24 am »
A 32bit app can use 4GB of ram on 64bit OS if linked using a special flag. On Visual Studio this is the LARGEADDRESSAWARE flag (also works with Delphi applications as can be seen here: http://stackoverflow.com/questions/2740308/why-2-gb-memory-limit-when-running-in-64-bit-windows) and on GCC it is "-Wl,--large-address-aware". On a 32bit windows it will still be limited to 2gb, on a 64bit windows it will be limited to 4gb. On Linux OS it will automatically be limited to 4gb.
146
Issues Help Desk / Linker crash
« on: July 02, 2015, 10:30:46 am »
I had a few linker crashes recently. I really cannot figure out why they happen. That only happens when I compile with Build>Compile. It works fine in Debug and Run modes. And the error also happens only when I enable one my extensions. It sometimes works, but often times it doesn't. I haven't yet checked what has changed on the extension side but I'm not sure that it is the problem. The LGM log is like this: http://pastebin.com/xFngiAMS
The error itself is very non-descriptive:
One thing I noticed is that the linker command is actually very long (more than 16k chars) and the Windows 8 limit is 8k. So I cannot even call the linker part from my cmd. But when I call the linker like this "g++ @commands.txt" where commands.txt has all of the string, I can get it to compile. No errors are thrown. Then I noticed ENIGMA uses sh.exe as the shell, probably just because of this limit. But when I call the same thing from sh.exe I still don't get the error. But when I use the "make", then it crashes: http://pastebin.com/ZUzmTcLp
So make.exe (or mingw32-make.exe if used instead) is the one that crashes. I looked on the net and few suggestions were given:
1) Disable AntiVirus or Windows Defender - did that, didn't work. This would also not explain why I can compile by just disabling an extension.
2) Run as Administrator - did that, didn't work. This too wouldn't make sense.
Later I will try installing new MinGW together with new Git and GCC and see if that helps. That will happen a week after the next one though.
Does anyone ever had this problem?
The error itself is very non-descriptive:
Quote
0 [main] sh 7632 handle_exceptions: Exception: STATUS_ACCESS_VIOLATIONThe crash dump is actually even less descriptive:
2288 [main] sh 7632 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump
2288 [main] sh 7632 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump
Quote
MSYS-1.0.12 Build:2012-07-05 14:56
Exception: STATUS_ACCESS_VIOLATION at eip=6E69572F
eax=00000000 ebx=6A626F65 ecx=FFFFFFFF edx=680A4C5C esi=69572F73 edi=776F646E
ebp=736A626F esp=0026B708 program=C:\ENIGMA\git\bin\sh.exe
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
4604 [main] sh 7632 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
4903 [main] sh 7632 handle_exceptions: Error while dumping state (probably corrupted stack)
One thing I noticed is that the linker command is actually very long (more than 16k chars) and the Windows 8 limit is 8k. So I cannot even call the linker part from my cmd. But when I call the linker like this "g++ @commands.txt" where commands.txt has all of the string, I can get it to compile. No errors are thrown. Then I noticed ENIGMA uses sh.exe as the shell, probably just because of this limit. But when I call the same thing from sh.exe I still don't get the error. But when I use the "make", then it crashes: http://pastebin.com/ZUzmTcLp
So make.exe (or mingw32-make.exe if used instead) is the one that crashes. I looked on the net and few suggestions were given:
1) Disable AntiVirus or Windows Defender - did that, didn't work. This would also not explain why I can compile by just disabling an extension.
2) Run as Administrator - did that, didn't work. This too wouldn't make sense.
Later I will try installing new MinGW together with new Git and GCC and see if that helps. That will happen a week after the next one though.
Does anyone ever had this problem?
147
Issues Help Desk / Re: Some Fervi's Question
« on: July 01, 2015, 04:57:24 am »
I wouldn't mind coding everything in C++ together with some of the ENIGMA semantics. Like the "with(){}" statement or referencing any instance with a dot. Language wise I think EDL isn't bad, but it is lacking. I don't think PHP, JS, Go or Python should be used though. I hate them. So a "simplified C++" what was in essence EDL seemed good. What would "finite state machine editor" look like?
I do think GM compatibility has made many things difficult. Like we don't have a way to differentiate between resources by their ID's (I made a topic about it long ago). The same compatibility also made the parser a lot more complicated than it should have been. Like I don't really think every variable should be a switch statement. Couldn't every object be a class and every instance an instance of that class? Then of course we couldn't as easily add new variables ("a = 5;" will init "a" if it is not used in the object and set existing "a" if it is), but that is also a GM compatibility feature. I wouldn't mind writing "local a" for all variables I want in a instance. And those that are used without some kind of declaration would trow an error. Right now debugging is pain in the ass for ENIGMA just because of this.
I do think GM compatibility has made many things difficult. Like we don't have a way to differentiate between resources by their ID's (I made a topic about it long ago). The same compatibility also made the parser a lot more complicated than it should have been. Like I don't really think every variable should be a switch statement. Couldn't every object be a class and every instance an instance of that class? Then of course we couldn't as easily add new variables ("a = 5;" will init "a" if it is not used in the object and set existing "a" if it is), but that is also a GM compatibility feature. I wouldn't mind writing "local a" for all variables I want in a instance. And those that are used without some kind of declaration would trow an error. Right now debugging is pain in the ass for ENIGMA just because of this.
148
Issues Help Desk / Re: Some Fervi's Question
« on: June 30, 2015, 12:55:01 pm »
No, it is not dead. There are stuff going on, but it is mostly me at the moment. I think it is time to decide on a different direction, like totally ditching GM compatibility (something I haven't considered important in years) and making a new IDE (on which apparently Robert and some other people are slowly working). This week and next week is totally full for me (next week I won't even have internet or computer), but the week after that I hope to make some kind of topic detailing stuff I have done.
For the php project you need a command line interface (CLI). ENIGMA has two of those. One is native (written as a separate program in C++), but is not finished. With that you can compile an .gmx using a cmd command (it is more of a dialog). The other option is more working as it uses LGM. You can basically tell LGM to use the ENIGMA plugin and compile a project. Something like "java <jvm options> -jar plugins/enigma.jar <game_file.gmx>" (more here: http://enigma-dev.org/docs/Wiki/CLI). This way you can load anything LGM can and compile anything your version of ENIGMA can. The only hard part is passing ENIGMA settings, which is not possible as far as I know. This needs to be added to the LGM or plugins/enigma.jar.
For the php project you need a command line interface (CLI). ENIGMA has two of those. One is native (written as a separate program in C++), but is not finished. With that you can compile an .gmx using a cmd command (it is more of a dialog). The other option is more working as it uses LGM. You can basically tell LGM to use the ENIGMA plugin and compile a project. Something like "java <jvm options> -jar plugins/enigma.jar <game_file.gmx>" (more here: http://enigma-dev.org/docs/Wiki/CLI). This way you can load anything LGM can and compile anything your version of ENIGMA can. The only hard part is passing ENIGMA settings, which is not possible as far as I know. This needs to be added to the LGM or plugins/enigma.jar.
149
Issues Help Desk / Re: Cant open ENIGMA because of LGM
« on: June 19, 2015, 03:39:38 am »
Well then one extension really had the wrong information given (probably corrupt). But you still need to get the extensions or else your ENIGMA would be quite limited (no datastructures, paths, motion planning etc.).
150
Programming Help / Re: Room Persistance?
« on: June 16, 2015, 12:51:25 pm »
I am pretty sure persistence was implemented at some point, but now when I check the code it seems that it is not. Not sure if it was removed or I'm just hallucinating. I'm 99% sure it worked for objects if not rooms. Either way this is something we should look into. Persistence is something very rarely used though, so it is not a priority. For example, global variables are persistent by design and can be used in place of persistence objects.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 »