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 »
391
Announcements / Re: Project Mario
« on: April 04, 2014, 04:19:34 pm »
The things you are suggesting should be high-level would remove the "programming a game" aspect of programming a game. We could go the stencyl route and include be_a_green_koopa(), be_a_red_koopa(), be_a_block(), be_mario(), be_link(), and fly_around_in_circles(), and then, of course, include a UI to pick which of those you want to call as tiles. But I have this crawling feeling you'd quickly notice a shift in the sorts of games made in ENIGMA. Yes, they'd all behave well; yes, it'd be easy to develop games; and yes, we could easily predict all behavior for purposes of, eg, rewinding time. But somehow, I think interest in the project as a development platform would actually dwindle.
392
Developing ENIGMA / Re: Changes in the new compiler
« on: April 04, 2014, 04:13:05 pm »
I was hoping to use GitHub to generate a basic zip file for release building. I want to eventually automate package generation on this server or another. I can, of course, have git check out all that stuff locally, then zip it manually, but then I have to delete the .git directories. Please tell me there's only one of those.
393
Announcements / Re: Project Mario
« on: April 04, 2014, 04:07:04 pm »
Data structures are important, but Game Maker does offer a C-Like interface to them. Yes, it uglies up the code, but what HaRRi is arguing is that it isn't a limitation in the strictest sense.
I consider the missing structures to be GML's greatest downfall. With those, a user could work around GM's other major flaws, including my personal pet peeves:
1) The inability to name script parameters. This encourages documentation in the ugliest way possible, but otherwise damages code readability.
2) The unavailability of virtual methods in classes. Game Maker offers user events, but these also cannot be named, and there is a strict limit of 16. Emphasis: limit.
3) The lack of proper encapsulation. This only really aggravates me when creating a data structure gives you a sequential integer that must be freed when you are done. We can't do anything to make your life easier; we have all the same problems as C for new users. Close your files, or you'll run out of file handles. Delete your data structures, or you'll run out of memory. If we had data structures as objects, they'd be freed when they left scope.
4) The lack of a well-defined passing convention. Want to pass an array? Create a list structure, pass the ID. See problem list in (3).
5) The inability to hold non-integer objects, thereby constraining the number of object types you can offer–creating them is a pain in the ass.
If you don't miss structs, Harri, then my guess is that A* is the most complicated algorithm you've ever written in GML. Because if you had to store more than three values for any given node or grid cell, you'd quickly go insane. Three values in a grid requires three grids. N values in a grid requires N grids. Each value requires a call to ds_grid_*, which is bulky and ugly. Enter map. Now it's also slow.
If we wanted an iterator for them, we could have ds_map_iterator_*, so that you could construct iterators and work with them by integer. But now we need an array of iterators. What a joke. This puts burden on developers, so it doesn't happen, which puts burden on users, because now their code is slow because it's doing N log M operations for N variables in M objects. This is on top of the already obnoxious overhead for accessing a variable.
This also further exacerbates problem (3). Your iterators wouldn't have an owner, and so you'd need to explicitly denote you are finished with an iterator so the system can destruct it. Now your code is illegibly hideous; ISO C++ is officially prettier than your "high-level" GML.
The rate at which your code blows up is a good metric for whether there are limitations. A rope ladder leading to the moon does not, in itself, remove a limitation. Yes, you could climb to the moon, but the resources required would be insurmountable. Yes, you COULD write a compiler in GML. But I'd advise you to instead do something more fun and productive, like cutting off your limbs in one-inch increments. Even if you managed, it'd run like shit. Even if you compiled it with ENIGMA. Why? Because your code is bad. Even if you can't see it. Being low-level in nature (ie, being a pain in the ass to use), does not imply you will have faster code. Allocating and freeing iterators yourself through those functions would make the code slower, anyway, because now we need to dereference more than just the current frame to figure out where your iterator is to dereference it and figure out where your data is.
And that concludes my rant, for now.
I consider the missing structures to be GML's greatest downfall. With those, a user could work around GM's other major flaws, including my personal pet peeves:
1) The inability to name script parameters. This encourages documentation in the ugliest way possible, but otherwise damages code readability.
2) The unavailability of virtual methods in classes. Game Maker offers user events, but these also cannot be named, and there is a strict limit of 16. Emphasis: limit.
3) The lack of proper encapsulation. This only really aggravates me when creating a data structure gives you a sequential integer that must be freed when you are done. We can't do anything to make your life easier; we have all the same problems as C for new users. Close your files, or you'll run out of file handles. Delete your data structures, or you'll run out of memory. If we had data structures as objects, they'd be freed when they left scope.
4) The lack of a well-defined passing convention. Want to pass an array? Create a list structure, pass the ID. See problem list in (3).
5) The inability to hold non-integer objects, thereby constraining the number of object types you can offer–creating them is a pain in the ass.
If you don't miss structs, Harri, then my guess is that A* is the most complicated algorithm you've ever written in GML. Because if you had to store more than three values for any given node or grid cell, you'd quickly go insane. Three values in a grid requires three grids. N values in a grid requires N grids. Each value requires a call to ds_grid_*, which is bulky and ugly. Enter map. Now it's also slow.
If we wanted an iterator for them, we could have ds_map_iterator_*, so that you could construct iterators and work with them by integer. But now we need an array of iterators. What a joke. This puts burden on developers, so it doesn't happen, which puts burden on users, because now their code is slow because it's doing N log M operations for N variables in M objects. This is on top of the already obnoxious overhead for accessing a variable.
This also further exacerbates problem (3). Your iterators wouldn't have an owner, and so you'd need to explicitly denote you are finished with an iterator so the system can destruct it. Now your code is illegibly hideous; ISO C++ is officially prettier than your "high-level" GML.
The rate at which your code blows up is a good metric for whether there are limitations. A rope ladder leading to the moon does not, in itself, remove a limitation. Yes, you could climb to the moon, but the resources required would be insurmountable. Yes, you COULD write a compiler in GML. But I'd advise you to instead do something more fun and productive, like cutting off your limbs in one-inch increments. Even if you managed, it'd run like shit. Even if you compiled it with ENIGMA. Why? Because your code is bad. Even if you can't see it. Being low-level in nature (ie, being a pain in the ass to use), does not imply you will have faster code. Allocating and freeing iterators yourself through those functions would make the code slower, anyway, because now we need to dereference more than just the current frame to figure out where your iterator is to dereference it and figure out where your data is.
And that concludes my rant, for now.
394
Programming Help / Re: Find the Memory Leak
« on: April 04, 2014, 03:34:13 pm »Quote
The question now is why this occurs with parenting and not without parenting.Make sure instantiating the parent enemy *does not* cause this problem, and instantiating an *empty* child enemy does.
Quote
It could be related to the object index which is passed up to the parent in the constructor which is further passed to the object_locals base class.It absolutely does. That feature is older than your event inheritance fix. If that is no longer the case, then my guess is that you broke it when you recoded the constructors for your event inheritance.QuoteThe only way that this could be at all relevant is if an iterator isn't getting destroyed properly. But the iterator system I set up relies on RAII principles, so that shouldn't be the case.The current system does not allow iterating children of a parent object using the parent object index, I do not know if that is possible in GM or not.
I don't see the problem from the code you've posted. I'd like the exact EDL for both events, ideally. From what I can see here, there's no difference between the two objects at all, since it's the parent's own function that is called, exactly. Valgrind could tell me the exact allocation position of the leaked objects, but I am away from my ENIGMA machine, at work. Valgrind would be infinitely more useful if we had a Graphics_Systems/None to avoid OpenGL errors from displaying in the backlog.
395
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: April 04, 2014, 11:43:00 am »
Rusky: That's exactly how I want to prevent it. If you clone ENIGMA, everything you sew in to user games must be under GPL + Exception or plain GPL. Preferably the former so we and our users can all use the code, but plain GPL is just fine. Proprietary is not. If you want to sell users libraries, you do so in a way that users rely on free software first, and then your shit second. The best way I can think to take care of it is by voiding out the exception if you're distributing your own ENIGMA. But that's not really what I want... I only want to make sure that everyone has the same access to our engine that you have. That includes shit you patch. No license secures that except unabridged GPL.
onpon: I don't care if you want to write your own proprietary ENIGMA from scratch. Just don't leech off of us.
onpon: I don't care if you want to write your own proprietary ENIGMA from scratch. Just don't leech off of us.
396
Programming Help / Re: Find the Memory Leak
« on: April 04, 2014, 11:31:48 am »
Robert, just remove blocks from the GML until the leak no longer occurs, then post the GML that can't be removed without fixing the leak. The leak will be in the code for those GML function(s).
My guess would be that in the best case, someone used new for no reason. In the worst case, it's creating some kind of resource that ENIGMA can never garbage collect/preempt.
polygone: Don't use an if-else ladder for event_perform, and don't call the parent's event first. If needed, the child event should either be the parent event, or should call it explicitly.
My guess would be that in the best case, someone used new for no reason. In the worst case, it's creating some kind of resource that ENIGMA can never garbage collect/preempt.
polygone: Don't use an if-else ladder for event_perform, and don't call the parent's event first. If needed, the child event should either be the parent event, or should call it explicitly.
Code: (cpp) [Select]
switch (type | numb << 8) { // Assumes type ≤ 255
case (0 | 0 << 8): return myevent_create();
case (1 | 0 << 8): return myevent_destroy();
default: return 0;
}
397
Developing ENIGMA / Re: Changes in the new compiler
« on: April 04, 2014, 11:23:10 am »
Bleh. As long as it gets *all* the submodules with that one call, that's fine. There's just no room for expansion otherwise.
Here's my secondary concern: When I go to GitHub and press "Download zip," what do I find in the submodule/subtree folders?
Here's my secondary concern: When I go to GitHub and press "Download zip," what do I find in the submodule/subtree folders?
398
Developing ENIGMA / Re: Changes in the new compiler
« on: April 03, 2014, 09:30:59 pm »
Last I investigated Git submodules, they sucked. I'll give them another look, because we could desperately use that functionality. The ability to have users check out one repository URL to receive code from both is a must.
399
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: April 01, 2014, 10:13:29 pm »
Not if we can separate ENIGMA clones from games. I don't care if a user creates a different version of the same function; I can't have an ENIGMA clone that does so. The dividing line is pretty narrow, as has been discussed.
400
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: March 30, 2014, 11:01:20 pm »
It is my attempt to fit the exception to ENIGMA that is in dispute. I'll freely admit I was overzealous in my attempt to do so.
I accept that our use of a custom exception might make ENIGMA less attractive than permissively licensed engines. And I maintain that it will have to be customized to some extent—the GCC linking exception is not only not tailored to ENIGMA, but designed specifically for GCC. These are arguments for people preferring other open-source game engines. This is NOT an argument for people preferring Yoyo's engine. They, too, use a custom license that leaves you completely at their mercy. I'm not sure what people perceive to be the difference. Their EULA has been the subject of scorn since its inception.
But anyway, if you believe an unmodified (on only renamed) GCC linking exception would cover ENIGMA, then I'd lean toward it—that exception takes special care to ensure the freedom of the compiler, which is more than MPL does. My major concern with it was that it doesn't prevent you from creating new versions of the same functions on your side to work around problems in the free version without having to share, but I guess that's just me being picky. The difference between needing a customized version of a free function and hoarding a fixed version of a free function is too thin to define well, I believe.
I accept that our use of a custom exception might make ENIGMA less attractive than permissively licensed engines. And I maintain that it will have to be customized to some extent—the GCC linking exception is not only not tailored to ENIGMA, but designed specifically for GCC. These are arguments for people preferring other open-source game engines. This is NOT an argument for people preferring Yoyo's engine. They, too, use a custom license that leaves you completely at their mercy. I'm not sure what people perceive to be the difference. Their EULA has been the subject of scorn since its inception.
But anyway, if you believe an unmodified (on only renamed) GCC linking exception would cover ENIGMA, then I'd lean toward it—that exception takes special care to ensure the freedom of the compiler, which is more than MPL does. My major concern with it was that it doesn't prevent you from creating new versions of the same functions on your side to work around problems in the free version without having to share, but I guess that's just me being picky. The difference between needing a customized version of a free function and hoarding a fixed version of a free function is too thin to define well, I believe.
401
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: March 29, 2014, 12:24:03 am »
That's exactly what we're trying to accomplish, Frogg. I was trying to do it with a custom license, because there is no existing open-source license that separates the product and creations made with it.
402
Programming Help / Re: Access instance variables stored in ds_list
« on: March 28, 2014, 12:14:01 pm »
For now, don't worry about it. We'll have better error reporting at some point in the discrete future, so you'll know which variable you're using undeclared. The 0, 0, 640, 480 thing is probably my fault, from when I was editing the view code. Don't worry about it, either.
403
Programming Help / Re: Access instance variables stored in ds_list
« on: March 28, 2014, 10:18:48 am »
I just noticed; you're calling [snip=edl]ds_list_create(t0_list);[/snip], and I have no idea how. That shouldn't build. It should say [snip=edl]t0_list = ds_list_create();[/snip].
Was that just some copy-paste error, or did someone change how lists work? Possibly, it's accepting an initial size, but it seems to not be documented.
Was that just some copy-paste error, or did someone change how lists work? Possibly, it's accepting an initial size, but it seems to not be documented.
404
Developing ENIGMA / Stateful Functions
« on: March 28, 2014, 09:49:23 am »
ENIGMA (Specifically EDL) is full of stateful functions: functions which operate based on a global state. Obvious examples include file_find_first/file_find_next. It also contains functions which operate on resources not owned by ENIGMA. Examples of these include file_bin_open, surface_create, and the list goes on. Still more functions change the overall game state in ways that are conducive to leaks, such as ds_list_create, ds_map_create, ds_grid_create, sprite_add, sound_add, background_add...
You might have figured it out by now, but these functions all have one thing in common: they don't agree with game_save. In Game Maker, game_save and game_load can dump all state information and re-load it in a matter of milliseconds. But this excludes work done by the functions above (or at least the majority of them). I can have ENIGMA generate state dumps for objects, but I can't have it generate them for all functions. Least of all surface_create.
This is problematic because game_save is a fantastic placeholder for custom save mechanisms, and its emulator-like dumping is great for debugging. In fact, that's the major reason I am interested in it right now. Rusky and I were discussing a crackpot lunatic's great idea for game debugging, and for some reason, I'm dumb enough to want to give integrating it into ENIGMA a try. But I can't do that (despite Rusky's insistence otherwise) without a working game_save/game_load.
The easiest way I can devise to handle the situation is to create a namespace for state restoration functions. So in the header that declares file_find_first, you'd see something like this:
The compiler would then include a call to everything in enigma::dump_state in game_save, and a call to everything in enigma::load_state in game_load.
The call to dump_state::*() returns a vector of bytes to write to the save file. The call to load_state::*() accepts a pointer to file content (ideally memory-mapped), reads in the state information in its own dump format, and then returns the number of bytes read. Thus, it's critical that each function write only what it will read and reads everything it might have written. Otherwise, it will ruin all the other state loads.
Now, in the case of file_find_*, it's pretty easy to dump the current filename and just iterate back to it. But in the case of surface_create, dumping all the surfaces to a file might be a large, cumbersome task that a user would want to disable. And in the case of sprite_add, keeping track of all added sprites is more code than some users will want in their game. That said, I think it would be frugal to make sure this logging code can also be toggled off, with a preprocessor. Later on, I'm not opposed to a Game Load event.
With a little luck, game_save will be powerful enough to do what I am planning. If not, we may need to use some more preprocessors and include code to keep track of state changes in a more minimal fashion. I'll worry about that later. For now, game_save is something isolated enough to be concerned with.
You might have figured it out by now, but these functions all have one thing in common: they don't agree with game_save. In Game Maker, game_save and game_load can dump all state information and re-load it in a matter of milliseconds. But this excludes work done by the functions above (or at least the majority of them). I can have ENIGMA generate state dumps for objects, but I can't have it generate them for all functions. Least of all surface_create.
This is problematic because game_save is a fantastic placeholder for custom save mechanisms, and its emulator-like dumping is great for debugging. In fact, that's the major reason I am interested in it right now. Rusky and I were discussing a crackpot lunatic's great idea for game debugging, and for some reason, I'm dumb enough to want to give integrating it into ENIGMA a try. But I can't do that (despite Rusky's insistence otherwise) without a working game_save/game_load.
The easiest way I can devise to handle the situation is to create a namespace for state restoration functions. So in the header that declares file_find_first, you'd see something like this:
Code: (cpp) [Select]
string file_find_first(string pattern, int attr);
namespace enigma {
namespace dump_state { vector<char> file_find(); }
namespace load_state { size_t file_find(char*); }
}
The compiler would then include a call to everything in enigma::dump_state in game_save, and a call to everything in enigma::load_state in game_load.
The call to dump_state::*() returns a vector of bytes to write to the save file. The call to load_state::*() accepts a pointer to file content (ideally memory-mapped), reads in the state information in its own dump format, and then returns the number of bytes read. Thus, it's critical that each function write only what it will read and reads everything it might have written. Otherwise, it will ruin all the other state loads.
Now, in the case of file_find_*, it's pretty easy to dump the current filename and just iterate back to it. But in the case of surface_create, dumping all the surfaces to a file might be a large, cumbersome task that a user would want to disable. And in the case of sprite_add, keeping track of all added sprites is more code than some users will want in their game. That said, I think it would be frugal to make sure this logging code can also be toggled off, with a preprocessor. Later on, I'm not opposed to a Game Load event.
With a little luck, game_save will be powerful enough to do what I am planning. If not, we may need to use some more preprocessors and include code to keep track of state changes in a more minimal fashion. I'll worry about that later. For now, game_save is something isolated enough to be concerned with.
405
Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 27, 2014, 02:47:45 pm »
Is the file marked as read-only? It's conceivable (though doubtful) that Windows is somehow treating the executable flag as a read-only flag, but it seems the more obvious cause is that the file was marked read-only by GCC.
Executable files become read-only on Windows when they are in use. Was LGM running when you tried to compile the DLL, or something? I'm not sure what would be running arbitrary executables written to TEMP on his machine, so that probably isn't the case on his, but if you could find a way to reproduce that problem on your machine, we might have better luck.
Executable files become read-only on Windows when they are in use. Was LGM running when you tried to compile the DLL, or something? I'm not sure what would be running arbitrary executables written to TEMP on his machine, so that probably isn't the case on his, but if you could find a way to reproduce that problem on your machine, we might have better luck.
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 »