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 »
766
Announcements / Re: LateralGM 1.8
« on: May 20, 2013, 01:33:53 pm »
IsmAvatar has had LGM in a "feature freeze" for ages. I'm not sure if she still has plans to consider 1.6 for a release, but I personally discourage it; the rest of the Game Maker world has moved on, and LGM is quickly reaching obsolescence, even outside of the ENIGMA world. That said, I understand if she ends up not pulling the changes, or pulling them as a new branch and then sifting the bug fixes into master (this is what I'm expecting she'll do).
That said, based on the results of Robert's beta release, we will probably be switching to his fork until Ism starts work on her own master branch. In the event that the two begin to diverge, we (as in, the ENIGMA organization on GitHub) will maintain our own fork, assuming Ism is willing to help patch any merge conflicts arising from divergent systems. I suspect she will be, considering ENIGMA's userbase constitutes a substantial and increasing fraction of LGM's userbase.
That said, based on the results of Robert's beta release, we will probably be switching to his fork until Ism starts work on her own master branch. In the event that the two begin to diverge, we (as in, the ENIGMA organization on GitHub) will maintain our own fork, assuming Ism is willing to help patch any merge conflicts arising from divergent systems. I suspect she will be, considering ENIGMA's userbase constitutes a substantial and increasing fraction of LGM's userbase.
767
Issues Help Desk / Re: Mac help
« on: May 20, 2013, 02:25:59 am »
All right; good luck, and let us know how it goes. Eventually, another Mac fan with a knack for C++ will come along and pick up the torch. I imagine our original Mac developer is just busy with university.
768
Issues Help Desk / Re: Mac help
« on: May 19, 2013, 07:21:52 pm »
Our Mac maintainer seems to have fled his country, so I really don't know how ENIGMA is doing on Mac. We've tried to coordinate with him, but have just recently begun moving on as interest in the platform is very low. We'd be happy to walk you through trying to get it up and running again, but I can't promise anything at this point.
It's my understanding you'll need Apple's developer tools, along with a copy of ENIGMA's repository. If you're feeling jumpy, you can try to see how it's installed on Linux from the Wiki Git installation page. Otherwise, just check out from git, run install.py, and then run LateralGM's jar file, probably using [snip]java -jar lgm16b4.jar[/snip] in your terminal window.
Let me know how far that gets you.
Cheers
It's my understanding you'll need Apple's developer tools, along with a copy of ENIGMA's repository. If you're feeling jumpy, you can try to see how it's installed on Linux from the Wiki Git installation page. Otherwise, just check out from git, run install.py, and then run LateralGM's jar file, probably using [snip]java -jar lgm16b4.jar[/snip] in your terminal window.
Let me know how far that gets you.
Cheers
769
General ENIGMA / Re: Definitions Modified
« on: May 19, 2013, 07:14:47 pm »
It already does it each time you compile. Ism just doesn't update her keyword lists.
It also does it when you save the definitions file.
All that needs done is putting a call to the word list updater after those two calls.
It also does it when you save the definitions file.
All that needs done is putting a call to the word list updater after those two calls.
770
Proposals / While we (as in forthevin) are moving shit
« on: May 18, 2013, 05:48:14 pm »
Here's a question to think about while we're moving shit.
A lot of functions take specific types of objects as input. This hasn't been a big problem so far, because all objects have been 2D. When users go 3D, the tier [snip]object_planar[/snip] will need swapped out for a hypothetical [snip]object_spatial[/snip], which implements an x, y, and z. We're going to have cast issues out the ass one way or another, but I think it'd benefit us to have some community discussion before anything big happens.
Ideally, we could solve this by moving functions such as motion_add into the object_planar class. But thanks to our friend, [snip=edl]with(){}[/snip], this is, as usual, completely off the table. That said, I think we can still use vtables to help mitigate issues, like so:
If we do this, cast checks can be eliminated for engine code, and errors can be reported for assigning z-motion in a 2D object in debug mode (possibly only when a certain flag is set, like -pedantic or -w-wrong-fucking-dimensionality). Other functions, such as those in extensions, would either have to do cast checking or use the virtual methods from object_positionable to be able to whore the vtable.
By the way, let me make one thing clear: if your code contains [snip]dynamic_cast[/snip], you are doing something wrong. Rule of thumb.
Any thoughts, suggestions, or visions of disastrous issues with the proposed or existing systems are welcomed.
Cheers
A lot of functions take specific types of objects as input. This hasn't been a big problem so far, because all objects have been 2D. When users go 3D, the tier [snip]object_planar[/snip] will need swapped out for a hypothetical [snip]object_spatial[/snip], which implements an x, y, and z. We're going to have cast issues out the ass one way or another, but I think it'd benefit us to have some community discussion before anything big happens.
Ideally, we could solve this by moving functions such as motion_add into the object_planar class. But thanks to our friend, [snip=edl]with(){}[/snip], this is, as usual, completely off the table. That said, I think we can still use vtables to help mitigate issues, like so:
- Class object_spatial and class object_planar extend class object_positionable, which has a virtual $add_motion
- Each child class, object_planar and object_spatial, implement a motion setter for two and three dimensions, but object_planar ignores the given z coordinate.
If we do this, cast checks can be eliminated for engine code, and errors can be reported for assigning z-motion in a 2D object in debug mode (possibly only when a certain flag is set, like -pedantic or -w-wrong-fucking-dimensionality). Other functions, such as those in extensions, would either have to do cast checking or use the virtual methods from object_positionable to be able to whore the vtable.
By the way, let me make one thing clear: if your code contains [snip]dynamic_cast[/snip], you are doing something wrong. Rule of thumb.
Any thoughts, suggestions, or visions of disastrous issues with the proposed or existing systems are welcomed.
Cheers
771
Issues Help Desk / Re: How to prevent a collision to a player for 3 seconds after he has respawned.
« on: May 17, 2013, 01:45:27 pm »
Hi there! Here's a suggestion:
Move the collision from the asteroid object to the player ship object. In that event, instead of changing the object to explosion (which is terrible practice and was going to be removed from the engine), just create an explosion object at its position. Then reset [snip]x[/snip] to [snip]xstart[/snip] and [snip]y[/snip] to [snip]ystart[/snip] instead of creating the new ship.
In the ship's create event, set a variable, such as [snip]invincible[/snip], to 0. Then, wrap the collision with asteroid event you created in [snip=edl]if (invincible <= 0) {}[/snip]. Also in that [snip]if[/snip] block, set [snip=edl]invincible = room_speed * 3;[/snip] to give you three seconds of invincibility. In the step event, decrement it:
That should do it.
Alternatively, you can set an alarm whose job it is to unset [snip]invincible[/snip] instead of decrementing it yourself. Instead of setting [snip]invincible[/snip], you would use [snip=edl]invincible = true; alarm[0] = room_speed * 3;[/snip]. Alarm0 would then reset [snip]invincible[/snip] to false.
Move the collision from the asteroid object to the player ship object. In that event, instead of changing the object to explosion (which is terrible practice and was going to be removed from the engine), just create an explosion object at its position. Then reset [snip]x[/snip] to [snip]xstart[/snip] and [snip]y[/snip] to [snip]ystart[/snip] instead of creating the new ship.
In the ship's create event, set a variable, such as [snip]invincible[/snip], to 0. Then, wrap the collision with asteroid event you created in [snip=edl]if (invincible <= 0) {}[/snip]. Also in that [snip]if[/snip] block, set [snip=edl]invincible = room_speed * 3;[/snip] to give you three seconds of invincibility. In the step event, decrement it:
Code: (edl) [Select]
if (invincible > 0)
invincible -= 1;
That should do it.
Alternatively, you can set an alarm whose job it is to unset [snip]invincible[/snip] instead of decrementing it yourself. Instead of setting [snip]invincible[/snip], you would use [snip=edl]invincible = true; alarm[0] = room_speed * 3;[/snip]. Alarm0 would then reset [snip]invincible[/snip] to false.
772
General ENIGMA / Re: WIP enigma icon set cartoon
« on: May 17, 2013, 09:50:57 am »
You'll need to optimize them to look good at about 18x18, otherwise they won't look right in the editor window (they'll be fuzzy).
773
Announcements / Re: LateralGM 1.8 Beta
« on: May 16, 2013, 11:06:28 am »
He has only recently merged in that branch. Autocomplete worked fine in the JEdit branch.
774
General ENIGMA / Re: Where would you like your objects?
« on: May 16, 2013, 10:57:51 am »
A prompt is not completely necessary. It could just be set to unceremoniously delete any objects that haven't been used in over two weeks when it is launched, or when the IDE is closed. The point of this endeavor is not to make all games build fast every time, but just to make it so when you are actively developing a game (or multiple games at once), you don't need to build all of it every time you want to test something.
My main issue with (2) is, as HaRRi pointed out, novices won't know what the bin/ dir is. My fear is not that they will bundle the objects with the game, but instead that they won't know it's safe to delete them if they delete or stop working on the corresponding games. If they were dumb enough to include the bin/ dir with the game, we'd have serious problems, because they could be including a hundred games' worth of object files.
Another thing I have to work out is getting the objects to build as shared objects/dynamic link libraries, so they can be rebuilt and swapped out on the fly. This will, ideally, allow debug and design mode to make changes to the code and hot-swap it with the existing code.
My main issue with (2) is, as HaRRi pointed out, novices won't know what the bin/ dir is. My fear is not that they will bundle the objects with the game, but instead that they won't know it's safe to delete them if they delete or stop working on the corresponding games. If they were dumb enough to include the bin/ dir with the game, we'd have serious problems, because they could be including a hundred games' worth of object files.
Another thing I have to work out is getting the objects to build as shared objects/dynamic link libraries, so they can be rebuilt and swapped out on the fly. This will, ideally, allow debug and design mode to make changes to the code and hot-swap it with the existing code.
775
General ENIGMA / Where would you like your objects?
« on: May 16, 2013, 07:06:14 am »
The more I review the idea, the clearer it is that I ought to start moving event code into separate source files. I'm thinking the new pretty printer (which I am using as a gloss word for "that thing that exports all the relevant engine code") should implement this change, just while I'm at it.
The point of this is to make it so that objects do not all need rebuilt every time you run the game. Issue with that is, we need somewhere to store the object files generated by the compiler (eg, GCC). The way I see it, we have a few options:
1) Store them in temp files. Your game will need built from scratch once, every time you reboot the machine.
2) Store them in the same folder as the game. So there'll be a ./game.egm, and a ./bin/game.egm/objects. This will leave object files everywhere, because nothing will ever delete them.
3) Store them in the actual game. This will make games extra fat, and could be problematic when using zipped formats (we can't point the linker to a zipped file).
4) Insert better idea here.
My only better idea is to give ENIGMA a specific spot in appdata / ~ that stores object files by game ID/path+filename, along with a timestamp to let ENIGMA know that it's been two weeks since the objects there have been used, and so they should probably be deleted. Game Maker used to prompt to delete old temp files on start, so I guess it wouldn't be unheard of.
Anyway, thoughts welcome.
Cheers
The point of this is to make it so that objects do not all need rebuilt every time you run the game. Issue with that is, we need somewhere to store the object files generated by the compiler (eg, GCC). The way I see it, we have a few options:
1) Store them in temp files. Your game will need built from scratch once, every time you reboot the machine.
2) Store them in the same folder as the game. So there'll be a ./game.egm, and a ./bin/game.egm/objects. This will leave object files everywhere, because nothing will ever delete them.
3) Store them in the actual game. This will make games extra fat, and could be problematic when using zipped formats (we can't point the linker to a zipped file).
4) Insert better idea here.
My only better idea is to give ENIGMA a specific spot in appdata / ~ that stores object files by game ID/path+filename, along with a timestamp to let ENIGMA know that it's been two weeks since the objects there have been used, and so they should probably be deleted. Game Maker used to prompt to delete old temp files on start, so I guess it wouldn't be unheard of.
Anyway, thoughts welcome.
Cheers
776
ALLCAPS BOARD / Re: Should we add a timeout option to account settings?
« on: May 16, 2013, 06:13:43 am »
I've told you that was there seven times now.
777
General ENIGMA / Re: Critical Change, Function Renaming
« on: May 09, 2013, 09:52:56 am »Quote
they already are, all your draw_sprite calls? They draw a 3D floor with 0 for the z coordinates lolololololol, everything in OpenGL is 3D, everything in our engine is 3D, theres no need for disambiguation, except between what you are drawing not how you are drawing
Oh, good, then; let's just lose the polygon functions and call everything model_*, while we're at it.
778
Announcements / Re: https (Browser security)
« on: May 08, 2013, 09:19:29 pm »
I was speaking of an alternative to a self-signed SSL certificate, rather than an end-all, fix-all policy. I'm looking for cheap alternatives that won't make Firefox bitch.
779
General ENIGMA / Re: Critical Change, Function Renaming
« on: May 07, 2013, 10:00:49 pm »
You're only furthering my point. The function is [snip]physics_fixture_shape[/snip], not [snip]polygon_as_fixture_shape[/snip]. And yes, if you wanted a generic polygon function, such as _create, you would think to check polygon_*. But if you were thinking about drawing a polygon, you would use [snip]draw_polygon[/snip], just like every other function in GM that does any drawing (except, of course, the 3d functions, which use the namespace d3d_). None of that "polygon_draw" shit, and none of the "model_draw" shit you're proposing, either.
780
General ENIGMA / Re: Critical Change, Function Renaming
« on: May 07, 2013, 09:01:30 pm »
I had stated my intention to re-think the "D" in "D3d" to stand for "Draw" rather than "Direct." This makes sense, anyway, because you can't name the functions 3d_, and draw3d_/draw_3d_ is too much typing. draw_polygon_ is pretty bad in that department, but at least it's easy to find. No one would think to type polygon_ when looking to draw a polygon. It's great that you believe other systems will be able to use the same polygon objects as the graphics systems. What do you suppose those functions will be called? [snip=edl]polygon_use_with_newton()[/snip]? [snip=edl]polygon_set_as_mask_for_object()[/snip]? No, you're probably thinking along the lines of [snip=edl]physics_mask_from_polygon()[/snip]. Not to imply that any of the names would be that long; those were just examples. Similarly, users would call [snip=edl]draw_polygon()[/snip] if they intended to draw a polygon, just as they call [snip=edl]draw_sprite()[/snip] or [snip=edl]draw_background()[/snip] to draw a sprite or background, respectively. Now, assuming polygons are a resource, I am unopposed to placing manipulation functions in a polygon_ namespace, so long as the documentation for the functions in the other namespaces are clear on the need for those functions. I am talking, of course, of [snip=edl]polygon_create()[/snip], like [snip=edl]sprite_create_from_screen()[/snip], etc.
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 »