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 »
541
Off-Topic / Re: NakedPaulToast
« on: July 29, 2014, 02:28:56 pm »
I haven't been on GMC for years. So I don't really know him. I do slightly remember him, but I don't really have a lasting impression on him. I do remember him being relatively competent and helpful.
542
Developing ENIGMA / Re: Redundancy
« on: July 29, 2014, 11:41:30 am »
So I went ahead and started running GL3 in debug context. This found quite a few bugs (like using wrong enums, functions) as well as deprecated stuff (which is what I actually wanted). After removing some deprecated stuff like glEnable(GL_TEXTURE_2D) and glEnable(GL_ALPHA_TEST) I found that the AMD bug was actually because of it. When alpha testing is enabled with shader Nvidia, seems to just disregard it mostly. On AMD it actually foobars the whole thing. So when I got rid of it and instead implemented it in the shader, it seems work fine now on both Nvidia and AMD and without that ugly hack I found earlier (where I always enabled and sent color even though the buffer didn't have any).
But then I found that Robert (I am pretty sure it was him as I even vaguely remember the commit) added glAlphaFunc(GL_NOTEQUAL,0) to d3d_Begin(). Now it is required if you want alpha to work properly in 3D, but for that GM:S and ENIGMA has a special function - draw_set_alpha_test(). Alpha testing by default is false, because it's just faster that way. So in this regard I have two questions:
1) For Robert - Does GM:S rendered Project Mario's trees correctly without using draw_set_alpha_test()? I think it didn't. So Robert added that line in ENIGMA.
2) Do we enable that by default when using d3d_begin() or do we ask the user to enable it manually via draw_set_alpha_test()? I think we should ask the user to do it.
Right now Project Mario launches and runs fine with GL3.3 core profile enabled on my old AMD laptop. This means that it doesn't use ANY deprecated functions at any time. This means, in theory, that it could technically work in GLES from graphics standpoint.
Performance wise no difference. I still get 1120FPS in Project Mario on 660ti. When I set draw_set_alpha_test_ref_value(50) to get rid of the ugly tree alpha, I get up to 1160FPS, because there is less to render. Surprisingly with draw_set_alpha_test(false) I get the same 1120FPS, while I expected to get more.
But then I found that Robert (I am pretty sure it was him as I even vaguely remember the commit) added glAlphaFunc(GL_NOTEQUAL,0) to d3d_Begin(). Now it is required if you want alpha to work properly in 3D, but for that GM:S and ENIGMA has a special function - draw_set_alpha_test(). Alpha testing by default is false, because it's just faster that way. So in this regard I have two questions:
1) For Robert - Does GM:S rendered Project Mario's trees correctly without using draw_set_alpha_test()? I think it didn't. So Robert added that line in ENIGMA.
2) Do we enable that by default when using d3d_begin() or do we ask the user to enable it manually via draw_set_alpha_test()? I think we should ask the user to do it.
Right now Project Mario launches and runs fine with GL3.3 core profile enabled on my old AMD laptop. This means that it doesn't use ANY deprecated functions at any time. This means, in theory, that it could technically work in GLES from graphics standpoint.
Performance wise no difference. I still get 1120FPS in Project Mario on 660ti. When I set draw_set_alpha_test_ref_value(50) to get rid of the ugly tree alpha, I get up to 1160FPS, because there is less to render. Surprisingly with draw_set_alpha_test(false) I get the same 1120FPS, while I expected to get more.
543
Developing ENIGMA / Re: Redundancy
« on: July 29, 2014, 02:59:11 am »
Most of those functions don't work anyway in GL3, because we already use a shader. I can implement things like alpha testing in the shader, but I don't really want too, as it's rarely used. And if a person needs it, then he can write a simple shader on his own. But if I do add it in the shader, it's possible the speed will not really decrease, because all these options used uniform bool to toggle. That means the whole shader is executed with one code path, and that probably means the driver just generates several shaders for this.
And yes, there are two major ways to do complex rendering. First is mega-shader (one shader to rule them all - has all the options and features, and activates them using if (some_uniform)) - surprisingly this method isn't that slow, because uniforms don't change between renderings. This makes constant uniforms to be very fast. This is also a method used in a lot of games. Most of the Physically-based shaders are also just one mega-shader.
The second method involves a shader factory - This means we generate a new shader for each possible option or permutation of the option. This means there can be A LOT shaders, and that they have to be changed all the time (which has some perf. penalty). So this might even be slower, as it's probably what drivers are doing anyway. But if the whole game uses only a simple shader (like a old school 2D platformer), then this would actually be faster. But that point I suggest the user to write a simple shader himself. I can provide examples on how to do them, as it's not that complicated.
I will delete some of the functions (the EGMenable.h), but still leave some in, because there are A LOT of deprecated functions still in ENIGMA GL3 (though normally not used). So this will probably take some time I don't want to waste now. But it is required if we want GLES to be even easier to implement.
Also, do we need _fog_ functions in GL3?
And yes, there are two major ways to do complex rendering. First is mega-shader (one shader to rule them all - has all the options and features, and activates them using if (some_uniform)) - surprisingly this method isn't that slow, because uniforms don't change between renderings. This makes constant uniforms to be very fast. This is also a method used in a lot of games. Most of the Physically-based shaders are also just one mega-shader.
The second method involves a shader factory - This means we generate a new shader for each possible option or permutation of the option. This means there can be A LOT shaders, and that they have to be changed all the time (which has some perf. penalty). So this might even be slower, as it's probably what drivers are doing anyway. But if the whole game uses only a simple shader (like a old school 2D platformer), then this would actually be faster. But that point I suggest the user to write a simple shader himself. I can provide examples on how to do them, as it's not that complicated.
I will delete some of the functions (the EGMenable.h), but still leave some in, because there are A LOT of deprecated functions still in ENIGMA GL3 (though normally not used). So this will probably take some time I don't want to waste now. But it is required if we want GLES to be even easier to implement.
Also, do we need _fog_ functions in GL3?
544
General ENIGMA / Re: New functions available in the rooms editor.
« on: July 29, 2014, 02:32:09 am »
Instance is a "clone" of an object. Or in C++ terms, object is a class, and instance is one individual of that class. From one class there can be many instances. That is what they are in GM. I personally haven't seen the word used otherwise. The word "instance" could of course be used differently in some contexts (e.g. "for instance"), but I don't think the official terminology should be mixed up in the room editor.
545
Developing ENIGMA / Redundancy
« on: July 28, 2014, 12:02:16 pm »
Why do we have "EGMenable.h", "GL3enable.cpp" and some of the same functionality in "GL3d3d.h"? I am now removing all deprecated functions from GL3, which sadly involves most of the stuff in the first to files (like alpha testing). I will see if I can implement them in the shader, but I don't really want too, as they are rarely used and can be implemented manually in a custom shader.
What's your all take on these functions?
What's your all take on these functions?
546
General ENIGMA / Re: New functions available in the rooms editor.
« on: July 27, 2014, 05:18:20 am »Quote
I was wondering if it was correct or not to write objects instances. At first i wrote 'Shift instances', but depending on the selected tab the command is not the same, so i think it's useful to write if we are shifting objects or tiles."Instance" is GM and ENIGMA is defined quite precisely. There is no such thing as "Tile instance" or something like that. Objects are something different from instances. So "Shift all objects" is not correct from the terminology standpoint. So I personally would like "Shift all instances" and "Shift all tiles". But that's just me.
Instead i propose the following titles : 'Shift all objects' and 'Shift all tiles'. By the way all labels are stored in the messages.properties file, so if one day another developer wants to modify them, it should be easy.
547
General ENIGMA / Re: New functions available in the rooms editor.
« on: July 26, 2014, 04:12:46 pm »Quote
It is present also in GM Studio. But i don't think i will add the possibility to undo the clear of instances, because it can use a lot of memory.Depends on the room. I don't think normally it would require that much memory, but not sure, as I don't know how the instances are stored in Java. But I still think this should require an undo. Every destructive action requires an undo. If you don't want this to have an undo, then at least make a popup window warning that this will not be reversible, and if you want to proceed. An action like that shouldn't happen without notice.
548
Programming Help / Re: Good tutorial?
« on: July 26, 2014, 10:30:17 am »
Most GM tutorials will work fine. Like this one: https://www.youtube.com/watch?v=hzMNunoPd0o
This site in general: http://gamemakertutorials.com/
This site in general: http://gamemakertutorials.com/
549
Off-Topic / Re: Freakin' Ouch
« on: July 26, 2014, 10:09:37 am »
Well he got 4 pulled. I don't know why though, as they are not usually pulled if everything is okay. And I doubt all 4 started to be problem. He probably looks like a pirate now.
550
Developing ENIGMA / Re: Accessing with types and passing by strong reference
« on: July 26, 2014, 08:43:33 am »Quote
Pointers are just sparse integers. Yes, it's easy to obtain the next sprite given the current one, because usually you just add one. Well, let's say we handed around raw pointers. Now you can usually obtain the next sprite given the current one by adding sizeof spritestruct. The only difference is that you'll get an access violation and kill your program if you're wrong in the pointer case. As I stated, I'm fine with having a typedef of size_t for each resource kind. This would be a hint to the compiler that it is not to be used in arithmetic. It could also be used to allow object-oriented programming around that type; eg, replace spr_whatever.draw(0, x, y) with draw_sprite(spr_whatever, 0, x, y). There only difference is that this "pointer" is small, dense, and managed by us.I don't want "spr_whatever.draw()" or any other function like that at all. I don't want spr_whatever to be a class with members. I want that when I pass spr_whatever (with ID = 2, for example) to a draw_background(), I would know that it's incorrect, and that I am not in fact drawing background with ID = 2. So I want it to trow an error, as well as allow me create more generic functions. Like draw_image() which would take both sprite and background. Or replace sprite_get_texture, background_get_texture and surface_get_texture with one function - get_texture(). Or even go one step further and allow draw_primitive_texture() to take sprites, backgrounds and surfaces directly, without specific query for the texture. So I want to be able to figure out what the hell I am passing to the functions, instead of just an "int".
So I also recommended the typedef for this, but how would casting work when using default variable types? Like this this code:
Code: (edl) [Select]
a = 5; //Here variant of type variant with value 5
a = spr_some_guy; //Now "a" need to be typdef'd type "Sprite"
Also, as I mentioned before - doing arithmetic with ID's is retarded. We should not encourage it, and if possible, deny that possibility.
551
Issues Help Desk / Re: Desktop Launcher error on linux
« on: July 25, 2014, 04:33:58 pm »
Imagine this - I have ENIGMA installed here: "C:\enigma-dev\"
On Windows if you open console (cmd) you are by default in "C:\user\username>", so when I type this: "C:\user\username> java -jar C:\enigma-dev\lateralgm.jar", then it will try to find the plugin folder and the .dll in the "C:\user\username\", so it errors. This is fixed by the ENIGMA.exe though. That automatically sets the working directory, so if I call it instead "C:\user\username> C:\enigma-dev\ENIGMA.exe" then it works fine. So if I make a shortcut to ENIGMA.exe it works fine too. But there is no such thing as ENIGMA.exe on Linux. Maybe we should make one...
On Windows if you open console (cmd) you are by default in "C:\user\username>", so when I type this: "C:\user\username> java -jar C:\enigma-dev\lateralgm.jar", then it will try to find the plugin folder and the .dll in the "C:\user\username\", so it errors. This is fixed by the ENIGMA.exe though. That automatically sets the working directory, so if I call it instead "C:\user\username> C:\enigma-dev\ENIGMA.exe" then it works fine. So if I make a shortcut to ENIGMA.exe it works fine too. But there is no such thing as ENIGMA.exe on Linux. Maybe we should make one...
552
Programming Help / Re: C++ short delay when using CIN + file access discussion
« on: July 25, 2014, 04:19:01 pm »Quote
#1) More memory consumptionThat is what I proposed to be optional. Like an additional argument to file_open functions which has a "bool preload = false" flag, so by default nothing changes. But if you want to load it in RAM, then you can. This way you won't have to make a duplicate set of functions just for this. I also don't think it will be slower for small files. You have to load the file in the ram always anyway. You will be able to load only parts of the file from HDD just like before, but I don't know how reading part of a file to RAM would work here. Maybe another two arguments would be required (read start and size to read).
#2) counter productive, especially if you need to open really small files which most people do, so you won't gain any noticeable speed, and in some cases the opposite.
I just don't want 100 file reading functions in ENIGMA, just for one reading in RAM, reading from HDD, reading from ASCII text, reading from UNICODE text, reading small endian binary, large endian binary etc. We should be able to do it with what we got, but expand to allow more. Like when you load in RAM, you should have an option to have access the buffer and then use buffer_ functions on them. So you can easily send the file via network. We basically need to tie all this together and not have a million different functions. Although that would allow the additional set to be as an extension, thus simplifying management.,
553
Developing ENIGMA / Re: Accessing with types and passing by strong reference
« on: July 25, 2014, 04:12:23 pm »
I think we should use it for everything. But we must overload the default variable type (variant or var) to support that. Because then at least I will be able to figure out what is actually passed to a function. GM:S seem to have a "ptr" type specific to textures. So you cannot use it for anything else, because it's not really descriptive. What I mean is actually less to do with regular pointers, but to references. I want textures to be "Texture", so when I make a function "draw_texture(Texture &texture, gs_scalar x, gs_scalar y){}" it would error if I pass a sprite, background, object, sound or anything else.
554
Issues Help Desk / Re: Desktop Launcher error on linux
« on: July 25, 2014, 04:06:45 pm »
Well the path is to the executable, but WHERE does the executable gets run from? Even in Linux, when you call a program it's called from current directory. So the question is it looking for the .so (the ENIGMA has a ".dll" on Linux right?) in the folder with the executable, or is it looking for it on the desktop? And it is looking for the plugin on the desktop? So the thing called "working directory" as it is called on Windows, is very important. But I am not sure how it works in Linux and how to change that.
555
Issues Help Desk / Re: Desktop Launcher error on linux
« on: July 25, 2014, 02:09:54 pm »
I guess it's something to do with working directory. Maybe the shortcut makes LGM to run in the desktop as working dir? Does your shortcuts have any options? On Windows every shortcut has a "Start in" parameter, which specifies where the exe is actually launched in. In your case it should be where LGM is located.
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 »