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 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
616
Off-Topic / Re: YoYoGames Compiler for 300$
« on: July 27, 2013, 01:13:30 pm »
A measly $300 for shaders? I should stop developing ENIGMA and use GM:S.
617
General ENIGMA / Re: Scalar Types
« on: July 27, 2013, 06:33:24 am »
The coordinate space uses the collision system/physics system scalar.
This seems to universally be float.
This seems to universally be float.
618
General ENIGMA / Re: Automated integration and regression extension and library
« on: July 27, 2013, 06:31:34 am »
Agreed.
While this would ideally be done as a complement rather than supplement to manual testing, until the regression testing suite is more complete, I think it's in our best interest to set something like this up as soon as we are prepared for branching. My only major concern is how it will handle things like antialiasing and rounding issues (for arithmetic tests). For example, the test suite might expect a given pixel to be any color between pure blue and pure white, while in fact it ended up being one or the other due to minute hardware differences. Likewise, the suite may expect .1 + .1 + .1 to be roughly .3, while in fact the value differs with the phase of the moon. On a happier note, I have high hopes for its performance with string, data structure, and I/O operations, as those tend to have only one right answer (not to imply that .30000000004 is a right answer to .1 + .1 + .1).
That said, if the system seems to do well in these cases, though, I'm fine entrusting it to the complete task. Especially considering one of the worst (and, incidentally, most frequent) regressions is a complete lack of ability to compile with ENIGMA on one platform or another.
It would be particularly useful if we could get cross-compilation working as part of this system, too, as contention between the tastes and preferences of MinGW on Linux vs Windows have led, on a thousand separate occasions, to the dysfunction of one system or the other. Reports are rolling in now that OpenAL doesn't work at all on Windows, and the simple explanation for this is that cheeseboy couldn't get AL working on MinGW for Linux, so he packaged his half-assed SFML system in his installer without paying any attention to AL. Then polygone and Robert decided, "WOW, A WINDOWS INSTALLER THAT ACTUALLY WORKS," buried my zip patch elsewhere on the Wiki, and put his up as the only installation candidate. Also, the bundled SFML doesn't work on Windows. Look where that leaves us.
The point is, as far as making sure the system actually compiles on each platform, this automated testing is invaluable. Pitted against our current system of "commit everything to master and wait for the flood of bug reports," I think the winner is clear.
While this would ideally be done as a complement rather than supplement to manual testing, until the regression testing suite is more complete, I think it's in our best interest to set something like this up as soon as we are prepared for branching. My only major concern is how it will handle things like antialiasing and rounding issues (for arithmetic tests). For example, the test suite might expect a given pixel to be any color between pure blue and pure white, while in fact it ended up being one or the other due to minute hardware differences. Likewise, the suite may expect .1 + .1 + .1 to be roughly .3, while in fact the value differs with the phase of the moon. On a happier note, I have high hopes for its performance with string, data structure, and I/O operations, as those tend to have only one right answer (not to imply that .30000000004 is a right answer to .1 + .1 + .1).
That said, if the system seems to do well in these cases, though, I'm fine entrusting it to the complete task. Especially considering one of the worst (and, incidentally, most frequent) regressions is a complete lack of ability to compile with ENIGMA on one platform or another.
It would be particularly useful if we could get cross-compilation working as part of this system, too, as contention between the tastes and preferences of MinGW on Linux vs Windows have led, on a thousand separate occasions, to the dysfunction of one system or the other. Reports are rolling in now that OpenAL doesn't work at all on Windows, and the simple explanation for this is that cheeseboy couldn't get AL working on MinGW for Linux, so he packaged his half-assed SFML system in his installer without paying any attention to AL. Then polygone and Robert decided, "WOW, A WINDOWS INSTALLER THAT ACTUALLY WORKS," buried my zip patch elsewhere on the Wiki, and put his up as the only installation candidate. Also, the bundled SFML doesn't work on Windows. Look where that leaves us.
The point is, as far as making sure the system actually compiles on each platform, this automated testing is invaluable. Pitted against our current system of "commit everything to master and wait for the flood of bug reports," I think the winner is clear.
619
Off-Topic / Re: YoYoGames Compiler for 300$
« on: July 27, 2013, 06:05:13 am »
I've heard record-breaking reports of how preposterously buggy GM:S is. And they only want $800 for the whole thing?
Amazingly generous. Hard to compete with that bargain.
I'm actually really surprised.
That I didn't see this coming.
I figured they'd just fail out on the LLVM idea when their performance was magically worse than it was when they were interpreting the code.
Amazingly generous. Hard to compete with that bargain.
I'm actually really surprised.
That I didn't see this coming.
I figured they'd just fail out on the LLVM idea when their performance was magically worse than it was when they were interpreting the code.
620
General ENIGMA / Re: Automated integration and regression extension and library
« on: July 25, 2013, 09:30:13 am »
Extra awesome. ENIGMA has needed this for a long time, but I never got around to doing it; instead I ended up joining the others in impatiently pressing forward with whatever we had.
I will give this a look over next I'm free. Whenever that is.
Thanks a ton for the work!
I will give this a look over next I'm free. Whenever that is.
Thanks a ton for the work!
621
General ENIGMA / Re: Graphics Systems Precision
« on: July 25, 2013, 05:53:53 am »
The improvement is that the cast is done by the user as needed. If the user has a float already, no cast is required.
622
General ENIGMA / Re: Porting Project Mario
« on: July 24, 2013, 07:18:36 am »
1) [snip]set_working_directory(filename_path(parameter_string(0)))[/snip]. Deal with it.
2) This isn't far off. If you're in that big a hurry, use this in definitions:
Then in your EDL, eg, in the step event for obj_particle, use [snip]call_inherited(obj_particle, step);[/snip]. That should solve it for now, if you're that impatient.
3) Go ahead and use Spirit's, or you can use e-YAML, for which the parser can be found in [snip]Compiler_Source/settings-parse[/snip], or something.
4) I have no idea how transformations would be "fucked." Especially if they're handled by a shader in the new system. A shader can treat them precisely as GM does, regardless of API.
5) Persistence worked when I wrote it. It's not a difficult mechanism. If there's a bug with it, file a bug report with a test case.
2) This isn't far off. If you're in that big a hurry, use this in definitions:
Code: (cpp) [Select]
#ifndef JUST_DEFINE_IT_RUN
#define call_inherited(object_name, event_name) OBJ_ ## object_name :: myevent_ ## event_name ();
#else
void call_inherited(int object_name, int event_name);
#endif
Then in your EDL, eg, in the step event for obj_particle, use [snip]call_inherited(obj_particle, step);[/snip]. That should solve it for now, if you're that impatient.
3) Go ahead and use Spirit's, or you can use e-YAML, for which the parser can be found in [snip]Compiler_Source/settings-parse[/snip], or something.
4) I have no idea how transformations would be "fucked." Especially if they're handled by a shader in the new system. A shader can treat them precisely as GM does, regardless of API.
5) Persistence worked when I wrote it. It's not a difficult mechanism. If there's a bug with it, file a bug report with a test case.
623
Issues Help Desk / Re: missing surface functions?
« on: July 19, 2013, 04:00:41 pm »
I think someone previously tried to commit a copy of lodePNG. Specifically, "canthelp," under the alias "sssstest." The pull request is here.
I was about to merge it, but he closed it.
I was about to merge it, but he closed it.
624
Issues Help Desk / Re: missing surface functions?
« on: July 19, 2013, 02:22:00 pm »
Go ahead and commit them.
625
Proposals / Re: OpenGL chosen by system (?)
« on: July 19, 2013, 08:19:23 am »
No, I promise that eventually, companies will cease to bundle compatibility drivers with their shit. I don't know when that will be, but when it happens, GL1 and DX9 applications will cease to function.
Regardless, offering the option to build for both is the best we can (or at very least should) do.
Regardless, offering the option to build for both is the best we can (or at very least should) do.
626
Proposals / Re: OpenGL chosen by system (?)
« on: July 19, 2013, 08:02:06 am »
You'd be surprised. The graphics pipeline has changed; GL1 was designed around the FFP. DirectX changes so much as to be impossible to salvage old code, from version to version. OpenGL has remained "compatible", but a lot of what you do is emulated software-side. For example, pr_linelist, pr_linestrip, pr_trianglelist, and pr_trianglestrip are all that's left, hardware side. And the strips are on their way out. It's getting to where your only choice is between lines and triangles.
Anyway, reading over his request again, I think you're right. I don't have any intention of supporting that, presently, as it removes the possibility of link-time optimization. Specifically, inlining graphics calls. Compared to the actual work done processor side, this is small, but it still aggravates me. It also bloats the game from having two of the same thing in it, although the amount of duplication has been improving, lately. In the event I get around to actually making a game in ENIGMA, my inclination will be instead to release two versions. This is assuming that neither (1) I determine that the game doesn't need mind-blowing graphics, and GL1 is fine, or (2) I determine that if your shit doesn't support GL3, it has no business attempting to run my game.
Anyway, reading over his request again, I think you're right. I don't have any intention of supporting that, presently, as it removes the possibility of link-time optimization. Specifically, inlining graphics calls. Compared to the actual work done processor side, this is small, but it still aggravates me. It also bloats the game from having two of the same thing in it, although the amount of duplication has been improving, lately. In the event I get around to actually making a game in ENIGMA, my inclination will be instead to release two versions. This is assuming that neither (1) I determine that the game doesn't need mind-blowing graphics, and GL1 is fine, or (2) I determine that if your shit doesn't support GL3, it has no business attempting to run my game.
627
Proposals / Re: OpenGL chosen by system (?)
« on: July 18, 2013, 02:14:28 pm »
This has already been added to the new parser, in the form of preprocessors.
Code: (EDL) [Select]
{{if ENIGMA_Graphics == "OpenGL1"}}
opengl1_do_stuff();
{{else}}
opengl3_do_stuff();
opengl3_special_stuff();
{{endif}}
628
Issues Help Desk / Re: missing surface functions?
« on: July 18, 2013, 02:12:13 pm »
ENIGMA actually ships with zlib. My concern is that we haven't set up a codec/format system in the extension system to cleanly allow plugins to add import/export formats.
Right now, the sprite_save/load functions only work with bitmaps, and the sound_add functions goes through ALURE. Not very extensible. That needs revisited, but it is at the bottom of my to-do list right now.
Right now, the sprite_save/load functions only work with bitmaps, and the sound_add functions goes through ALURE. Not very extensible. That needs revisited, but it is at the bottom of my to-do list right now.
629
General ENIGMA / Re: Hi There
« on: July 18, 2013, 09:22:38 am »
Right. ENIGMA offers a few things over game maker.
Even if Yoyo's speed matched ours completely, they will find that it's hard to compete with free and open. Lately, our contributor base has been growing past any original projection—while this can mean some degree of chaos, when components are easy to swap out or remove, it really has no drawbacks.
As for LLVM, it doesn't really appeal to me. They will enjoy quicker compile times, maybe. They will also be limited to fewer potential platforms. LLVM itself cannot build for all the platforms ENIGMA will (and has) built for. This is including the very early ports we saw for iPhone, Android, Wii, and the Nintendo DS. While those ports were short-lived in ENIGMA, they did not require excessive modification, and this remodel seeks to ensure it requires zero later on. LLVM's support stops after the first two. Moreover, if they ever did incur benefits from LLVM which were not available to us in GCC, writing an LLVM backend for ENIGMA would be pretty easy, and using Clang for ENIGMA would be trivial (and has been successfully done).
- It's free, as in gratuito. You This means not only that you don't pay a nickel for it if you don't want, but that there is no DRM that replaces your hard work with pictures of skulls and cross bones. It also means no license-oriented spyware, and no hassle to download, install, and use.
- It's free, as in libero. This means that if you want to change something in ENIGMA, you have the freedom, as much as the much more ready ability, to do so. Anyone can contribute, and we strive to make it really easy to do so.
- It's extensible. Yoyo's approach is to hone in on a specific graphics/audio/windowing system to cater to its very specific target platforms. ENIGMA does not have such a dependency on any one system; you can switch out OpenGL versions without modifying any of your code, and the bulk of my current work is to make it so you can switch out the host language just as easily.
Even if Yoyo's speed matched ours completely, they will find that it's hard to compete with free and open. Lately, our contributor base has been growing past any original projection—while this can mean some degree of chaos, when components are easy to swap out or remove, it really has no drawbacks.
As for LLVM, it doesn't really appeal to me. They will enjoy quicker compile times, maybe. They will also be limited to fewer potential platforms. LLVM itself cannot build for all the platforms ENIGMA will (and has) built for. This is including the very early ports we saw for iPhone, Android, Wii, and the Nintendo DS. While those ports were short-lived in ENIGMA, they did not require excessive modification, and this remodel seeks to ensure it requires zero later on. LLVM's support stops after the first two. Moreover, if they ever did incur benefits from LLVM which were not available to us in GCC, writing an LLVM backend for ENIGMA would be pretty easy, and using Clang for ENIGMA would be trivial (and has been successfully done).
630
Proposals / Re: Compile Scripts
« on: July 18, 2013, 07:30:14 am »
> Compile Scripts confused me a little. As I though "Compiled Scripts" and then tried to figure out why you call it like that because we already compile all scripts.
I am open to calling them Compiler Scripts, Preprocessor Scripts... anything that gets the point across.
> While it seems powerful to lets users do this, I still think we should add as much functionality ourselves as we can. Especially sprite_get_name() the like. And I don't think it would bloat the exe, as shouldn't compiler cut unused functions? I am pretty sure it doesn't do it now for some reason (probably the makefile is wrong). You could also make JDI do some size optimizations as you know what functions are used what aren't.
Adding shitloads of functions that weigh down the game and are difficult to prune is a bad idea. I really am not a fan of including any names in the executable by default: I don't know if -flto will remove them. It should remove the functions, but it might leave big, unused lists of resource names lying around.
> So you are basically defining a new language? I guess it will have similar syntax to EDL, but have some additional built in stuff to get information about resources? As you cannot do spr_my_sprite.name in EDL, though actually it is a very good idea. We should make all resource objects actual classes to we can get obj_enemy.bounding_box_width and such. I think we already can do obj_enemy.depth though.
It will probably use the same AST generation functions as EDL. The AST functions have an execute; I will just make it so that AST nodes can have data (such as method calls and classes) attached. That way, the already existing eval() function can run your code.
> What could be other uses for it instead of replicating these _name functions? I suspect this isn't meant to replace extensions or add the capability to code the scripts in pure C++ like Definitions.
Correct; this is only meant to augment them. A lot of what I wanted to discuss here was potential uses for it. Another that I was thinking of is also expressed in that code; it doesn't just compile all names, it inspects them for begins_with("spr_item_").
Depending on how much interest there is in this idea, I was thinking that these scripts could be allowed to access lots of metrics of resources; even do resource manipulation. For instance, they could be used to augment sprite packing assignment for texture atlases. Or they could add an event to all objects such that <user condition here>. Moreover, since their simplest use case is to generate code, the simplest thing to have them do is manage additional properties and grouping mechanisms for resources.
Robert was talking earlier about having the IDE able to edit and assign arbitrary properties to a resource. This system would flourish on that ability, as now the compiler can be extended by the game to handle them.
Granted, this would be something we want to help relieve the user of doing. I already proposed, in the past, a mechanism to allow loading and unloading resources in the tree en mass, by a given tree path. If that were everything all users would ever need, we'd be in good shape.
I am going to tailor the design of the parser → printer → finalizer flow such that it will all be accessible from scripting. We'll see what happens, later on.
I am open to calling them Compiler Scripts, Preprocessor Scripts... anything that gets the point across.
> While it seems powerful to lets users do this, I still think we should add as much functionality ourselves as we can. Especially sprite_get_name() the like. And I don't think it would bloat the exe, as shouldn't compiler cut unused functions? I am pretty sure it doesn't do it now for some reason (probably the makefile is wrong). You could also make JDI do some size optimizations as you know what functions are used what aren't.
Adding shitloads of functions that weigh down the game and are difficult to prune is a bad idea. I really am not a fan of including any names in the executable by default: I don't know if -flto will remove them. It should remove the functions, but it might leave big, unused lists of resource names lying around.
> So you are basically defining a new language? I guess it will have similar syntax to EDL, but have some additional built in stuff to get information about resources? As you cannot do spr_my_sprite.name in EDL, though actually it is a very good idea. We should make all resource objects actual classes to we can get obj_enemy.bounding_box_width and such. I think we already can do obj_enemy.depth though.
It will probably use the same AST generation functions as EDL. The AST functions have an execute; I will just make it so that AST nodes can have data (such as method calls and classes) attached. That way, the already existing eval() function can run your code.
> What could be other uses for it instead of replicating these _name functions? I suspect this isn't meant to replace extensions or add the capability to code the scripts in pure C++ like Definitions.
Correct; this is only meant to augment them. A lot of what I wanted to discuss here was potential uses for it. Another that I was thinking of is also expressed in that code; it doesn't just compile all names, it inspects them for begins_with("spr_item_").
Depending on how much interest there is in this idea, I was thinking that these scripts could be allowed to access lots of metrics of resources; even do resource manipulation. For instance, they could be used to augment sprite packing assignment for texture atlases. Or they could add an event to all objects such that <user condition here>. Moreover, since their simplest use case is to generate code, the simplest thing to have them do is manage additional properties and grouping mechanisms for resources.
Robert was talking earlier about having the IDE able to edit and assign arbitrary properties to a resource. This system would flourish on that ability, as now the compiler can be extended by the game to handle them.
Granted, this would be something we want to help relieve the user of doing. I already proposed, in the past, a mechanism to allow loading and unloading resources in the tree en mass, by a given tree path. If that were everything all users would ever need, we'd be in good shape.
I am going to tailor the design of the parser → printer → finalizer flow such that it will all be accessible from scripting. We'll see what happens, later on.
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 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »