Show Posts

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.


Messages - Josh @ Dreamland

391
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.
Quote
The 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.
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.

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.

392
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.

393
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.
Code: (C++) [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;
}

394
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?

395
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.

396
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.

397
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.

398
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.

399
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.

400
Programming Help / Re: Access instance variables stored in ds_list
« on: March 28, 2014, 10:18:48 AM »
I just noticed; you're calling ds_list_create(t0_list);, and I have no idea how. That shouldn't build. It should say t0_list = ds_list_create();.

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.

401
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:
Code: (C++) [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.

402
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.

403
Issues Help Desk / Re: Windows 7 x64 and ENIGMA?
« on: March 27, 2014, 09:46:03 AM »
I'm going to assume that by /temp you mean %TEMP%, or whatever. That should be in the user folder on Windows; if they don't have r/w permission to it, something is terribly wrong with their installation (aside from the obvious problem, being that it runs Windows). Both of these folders should be configurable, though; especially in the case of Linux, wherein users might want the objects path under ~/.cache/enigma or even /tmp instead of ~/.enigma.

Or did you actually mean /temp? This signifies, on new Windows distributions and ALL POSIX-compliant operating systems including BSD (Mac) and Linux, the root of the filesystem. So probably C:\ or D:\ on most Windows installations. For future reference to any interested party, ~ signifies the home directory of the current user, so for me, it translates directly to /home/josh/, and in general, ~you/ translates to /home/you/. The more you know ♪

Anyway, the ability to customize those directories is a must. If there isn't already a way, don't bother; I'll add one.

404
Programming Help / Re: libGME
« on: March 27, 2014, 09:36:39 AM »
You need to install libGME on your computer. If you're on Ubuntu, this is as simple as sudo apt-get install libgme-dev. If you are on Windows, you will need to find a distribution of it and add it to your MinGW installation manually.

Aside from that, the extension should work fine. We could add a function to ENIGMA (and so to the IDE) to give a list of functions, globals, and locals provided by a given extension. In fact, the compiler already does this internally; I can modularize that segment of it so that the IDE will have access to it in the future.

405
Works in Progress / Re: Attack of the Naked Blockheads 3D
« on: March 26, 2014, 08:27:54 PM »
The board only shrinks images; it doesn't generate thumbnails. :P