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 »
1081
General ENIGMA / Re: Compiling from source
« on: August 29, 2013, 04:05:49 pm »
It is. The reason it seems it that it can compile only from bash. At least this is the error I get when compiling from cmd (which ENIGMA.exe/LGM tries to do). It does seem to work when doing it the first time though. Only subsequent runs trows this error.
edit: From LGM side of things I get crashes once in a while. Dump shows something like this http://pastebin.com/c1FknHS2.
edit: From LGM side of things I get crashes once in a while. Dump shows something like this http://pastebin.com/c1FknHS2.
1082
Issues Help Desk / Parenting and even inheritance
« on: August 29, 2013, 02:23:14 pm »
This are two things the new parser should fix right? Josh, how is it going?
A user asked me to convert this example for him: http://gmc.yoyogames.com/index.php?showtopic=456948
And besides things like variable_exists(), it uses a lot of parenting and inheritance (even the event_inherited(); function). And as many use them I just wanted to know how is that going?
I will probably rewrite the example to not use parenting, but that just involves a lot of code duplication.
edit: The parser also seems to fail a lot like this case:
edit2: Also, GM seems to allow break; outside a loop or a switch which makes it work like "exit": http://wiki.yoyogames.com/index.php/Break. ENIGMA doesn't allow that. Not sure we even should allow that... but you know.. compatibility.
A user asked me to convert this example for him: http://gmc.yoyogames.com/index.php?showtopic=456948
And besides things like variable_exists(), it uses a lot of parenting and inheritance (even the event_inherited(); function). And as many use them I just wanted to know how is that going?
I will probably rewrite the example to not use parenting, but that just involves a lot of code duplication.
edit: The parser also seems to fail a lot like this case:
Code: [Select]
var near=instance_nearest(x,y,obj_Player_Camara_Parent);
outputs as this:Code: [Select]
var = instance_nearest(x, y, obj_Player_Camara_Parent);
And Code: [Select]
var near; near=instance_nearest(x,y,obj_Player_Camara_Parent);
Error in the syntax checker with "Primary expression expected before operator". But it seems to be a variable issue, because when I rename "near" into "tid" or something else, then it works. Is "near" used specifically somewhere in the parser or the compiler? I see these problems with variable names a lot. I think other than type names (int, short, double etc.) all other should be available. Especially if it is not shown in the code editor (type names are bold for example, while "near" is just normal). So we should find all these variables and define them in a way that doesn't make the conflict.edit2: Also, GM seems to allow break; outside a loop or a switch which makes it work like "exit": http://wiki.yoyogames.com/index.php/Break. ENIGMA doesn't allow that. Not sure we even should allow that... but you know.. compatibility.
1083
General ENIGMA / Re: The Times They Are A Changin'
« on: August 29, 2013, 02:07:19 pm »Quote
This bechmark wasn't done well. Robert said in the forum that he was using the non-LLVM version of GM Studio. I ran YoYo's demos and the LLVM version gave me a 200 FPS boost (back when LLVM was in beta, and therefore free). In addition, Windows Task Manager is not meant for benchmarking. Use perfmon and resmon (both installed in Windows 7 by default).He was using task manager just to compare the ram usage. I think it's quite valid in that regard.
And I don't know about LLVM change, but you can probably run it faster in ENIGMA as well just by using types and such. I am not sure how effective it would be in this particular demo though (haven't seen the source).
1084
General ENIGMA / Re: GameMaker: Studio sucks dick, and is massively fuckin slow
« on: August 29, 2013, 06:53:32 am »
I like how you use swear words every 10 syllables and yet ironically was the one whining about them in ENIGMA.
Anyway, good job. Can you also test the current GL3 batching system and compare? Because while this is better on many levels (as in we should only use triangles anyway) I don't think there will be any noticeable difference between this and the one before. Less memory usage is nice of course.
I played around with shaders yesterday and had some problems with binding textures to texture units. It seems you also made a change to texture_set_stage() which maybe would fix the problem I was having.
Anyway, good job. Can you also test the current GL3 batching system and compare? Because while this is better on many levels (as in we should only use triangles anyway) I don't think there will be any noticeable difference between this and the one before. Less memory usage is nice of course.
I played around with shaders yesterday and had some problems with binding textures to texture units. It seems you also made a change to texture_set_stage() which maybe would fix the problem I was having.
1085
General ENIGMA / Re: Everything Is Good Now
« on: August 29, 2013, 01:00:38 am »
But did you try compiling from source? Like not using the zip.
Anyway, if you won't commit the change then I will later. No biggy.
Anyway, if you won't commit the change then I will later. No biggy.
1086
General ENIGMA / Re: Everything Is Good Now
« on: August 28, 2013, 02:10:54 pm »
But the attribute is not returned if ftyp is invalid. That means the && never succeeds and thus the if is useless. At least I think it goes like that, because it doesn't work. Your probably didn't test it anyway as always.
1087
General ENIGMA / Re: Everything Is Good Now
« on: August 28, 2013, 10:21:00 am »Quote
I'm shocked though that Josh just fixed it instead of complaining about it and leaving it broken... ? Maybe he's learnt.Robert fixed it, not Josh.
Quote
Harri, what did you mean by you can't get shaders working? I thought they were working for you in the past?They never worked for me. I thought I was pretty clear on that. I will check and see if glsl_shader_get_infolog(id) returns something.
In other news, I just upgraded to the newest ENIGMA.exe and you DID break it. That directory check should be this:
Code: [Select]
if (ftyp == INVALID_FILE_ATTRIBUTES || !(ftyp & FILE_ATTRIBUTE_DIRECTORY))
notice the or || instead of and &&. Technically it should work with just ftyp == INVALID_FILE_ATTRIBUTES, but I guess we must make this check in cases when there is a file named enigma-dev.edit: Is it possible to get index for each shader seperatly? Like now shr_cartoon is just one resource.. so how can I link it manually? And how can I get error for each script manually? You didn't add error reporting in OPENGL3std and I did that myself. But to get errors I had to just use glsl_shader_get_infolog(0) and glsl_shader_get_infolog(1) as I cannot set it like glsl_shader_get_infolog(shr_cartoon->vertex) and glsl_shader_get_infolog(shr_cartoon->fragment). So we really need to figure this out.. if we have only one resource then some additional name param for each is needed or something.
Quote
//Vertex shader output
0(3) : warning C7555: 'varying' is deprecated, use 'in/out' instead
0(7) : error C7533: global variable gl_NormalMatrix is deprecated after version 120
0(7) : error C7533: global variable gl_Normal is deprecated after version 120
0(8) : error C7533: global function ftransform is deprecated after version 120
Quote
//Fragment shader outputSo basically they are not working because they use deprecated (and in my case not supported at all) stuff. We need to add matrices and stuff ourselves.
0(3) : warning C7555: 'varying' is deprecated, use 'in/out' instead
0(10) : error C7533: global variable gl_LightSource is deprecated after version 120
0(20) : warning C7533: global variable gl_FragColor is deprecated after version 120
edit2: I just remembered you set the version at the top of the shader. So I just changed 330 to 120 and voila.. it works. But we do need to make them 330 compatible with passing our own matrices anyway.
1088
General ENIGMA / Re: Everything Is Good Now
« on: August 28, 2013, 07:33:17 am »
I think integration testing was almost complete. A little bit of automation, server space (which Josh has now as far as I know) and it should be good.
Someone (probably Fervi) just has to make a simple tutorial with guidelines on how exactly we use it.
Someone (probably Fervi) just has to make a simple tutorial with guidelines on how exactly we use it.
1089
General ENIGMA / Re: Compiling from source
« on: August 28, 2013, 02:04:11 am »
I doubt Josh of any people will trow binaries in git. It's more likely there will be space on ENIGMA server.
1090
Off-Topic / Re: What the crap YYG??
« on: August 28, 2013, 01:52:07 am »
Like all ad fashion they probably took a special case to have that number. Like created a simple loop which worked 100x faster in YYC. Same with ENIGMA where for (int i=0; i<1000000; ++i) runs several times faster than for (i=0; i<1000000; ++i).
1091
General ENIGMA / Re: Windows Zip Discussion
« on: August 28, 2013, 01:17:22 am »
For me it works with ENIGMAPortable.exe without adding git separately to PATH as all the necessary things really is in the mingw (at least it seems).
When compiling from source then you must add mingw and git to PATH manually (as it should be).
edit: Rober, ffs, you broke it already. This:
edit2: Which you understood at a later commit and fixed again. So maybe it does work now.
When compiling from source then you must add mingw and git to PATH manually (as it should be).
Quote
Robert says the working_path change that Harri made broke it for him, he's commented it out now.What? I don't think I commented anything out. I think the problem was/is that the .dll cannot be compiled from C::B or cmd. From bash it worked fine. After all of that is compiled I was able run just fine (has some LGM crashes, but just had to upgrade).
edit: Rober, ffs, you broke it already. This:
Code: [Select]
if (INVALID_FILE_ATTRIBUTES == GetFileAttributes(workpath.c_str()) && GetLastError()== ERROR_FILE_NOT_FOUND)
- {
- workpath = exepath;
- }
is needed to check appropriate working folder. Right now IT WILL NOT WORK WHEN COMPILED FROM SOURCE. And yes, you CAN check directories with that function. RTFM! So something else broke for it you.edit2: Which you understood at a later commit and fixed again. So maybe it does work now.
1092
General ENIGMA / Re: Compiling from source
« on: August 28, 2013, 01:13:07 am »
If you will push for this auto-update/compile bull* that will break installing from source again then we might as well make two ENIGMA.exe's, because the changes I made basically just disabled all of it. It is great if it just a setting in the .ini, but when you run the first time the ini isn't even there yet. So what I basically did is ask in a promp if run anyway if the init script is not found (that is only the case when installing from source. If it is installed from the installer, then the file will be present) and if so, then write a setting in the .ini that will skip all of the git and compile thing at every start. The only other change was to make sure ENIGMA.exe can be in the same folder as the ENIGMA itself, as there is no logical reason to create 1 subdir just for the .exe (as when installing from source you have mingw and git installed elsewhere).
So Robert, if you can make the changes without breaking this then it would be great. The best way would be to still check if "skippedinit" is false and then do the upgrade check/upgrade itself. Otherwise skip it.
So Robert, if you can make the changes without breaking this then it would be great. The best way would be to still check if "skippedinit" is false and then do the upgrade check/upgrade itself. Otherwise skip it.
1093
General ENIGMA / Re: Compiling from source
« on: August 27, 2013, 04:02:46 pm »
It works now. Some of the last changes in git might of fixed it as well as the fact that the .dll cannot be compiled from cmd and you must bash at all times.
So the ENIGMAPortable.exe works out of the box and installing from source works if calling "mingw32-make" from bash (git-bash in my case, but I think anything from Msys or Cygwin would do as well).
I also made changes described in the OP under "thoughts".
So it finally works again. Thank you all! Now we must make sure it doesn't break and update installation instructions.
So the ENIGMAPortable.exe works out of the box and installing from source works if calling "mingw32-make" from bash (git-bash in my case, but I think anything from Msys or Cygwin would do as well).
I also made changes described in the OP under "thoughts".
So it finally works again. Thank you all! Now we must make sure it doesn't break and update installation instructions.
1094
Announcements / Re: Shader Resources
« on: August 27, 2013, 01:25:35 pm »
Shaders still not working. Will investigate later. I think it was something with shader compilation error.
1095
General ENIGMA / Re: Compiling from source
« on: August 27, 2013, 07:14:01 am »
Will that fix my problems?
Will try to update everything again later.
Will try to update everything again later.
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 »