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 »
1216
General ENIGMA / Re: Makefile is fucked
« on: October 28, 2011, 06:20:45 pm »
So apparently, Rusky's makefile doesn't agree with Mac. I'm not sure what to try; I'd need access to a Mac to try to get them working.
1217
Off-Topic / Re: Compiled Code in GM9
« on: October 25, 2011, 04:40:40 pm »
Heh, this should be good.
1218
Proposals / Re: Overworld Resource
« on: October 19, 2011, 08:37:08 pm »
I was hoping someone else would suggest that. While that was my original idea, I thought it kind of overcontorted the purpose of most RPGs, but I had mostly older ones in mind. (RPGs, and other games with such needs.) For example, I considered LoZ, too. Most of the time, converting coordinates in one room to those in another is all it takes. But I guess even in Zelda, there were stairs that led odd places.
But yes, teleporters would be really nice; the issue is, how do we sync that up with the room system, and how do we put it to functions? At the moment, I'm really tired. My brain hardly works; it's in write-only mode at the moment. But I'm having trouble thinking of a few concise functions to serve those purposes.
I guess, when I think about it, doors like in Kirby's Adventure would be better pulled off with that system than by overlapping rooms in the editor.
Okay, how about this:
In addition to regions, rooms can define entry points and exit points by a given name. The overworld resource then uses those points, allowing users to link them between rooms by drawing arrows between them. We could then offer functions to go to follow the route pointed to by one such node. Or, in the case that there are multiple, offer an overload of that function that uses a different index, for doors and teleporters that go random places.
But yes, teleporters would be really nice; the issue is, how do we sync that up with the room system, and how do we put it to functions? At the moment, I'm really tired. My brain hardly works; it's in write-only mode at the moment. But I'm having trouble thinking of a few concise functions to serve those purposes.
I guess, when I think about it, doors like in Kirby's Adventure would be better pulled off with that system than by overlapping rooms in the editor.
Okay, how about this:
In addition to regions, rooms can define entry points and exit points by a given name. The overworld resource then uses those points, allowing users to link them between rooms by drawing arrows between them. We could then offer functions to go to follow the route pointed to by one such node. Or, in the case that there are multiple, offer an overload of that function that uses a different index, for doors and teleporters that go random places.
1219
General ENIGMA / Re: Compiling game without console.
« on: October 19, 2011, 10:14:14 am »
I was thinking just an integer ID from 0 to number_of_regions. See the proposal I just posted, and argue for name.
1220
Proposals / Overworld Resource
« on: October 19, 2011, 10:13:28 am »
Formal proposal time, now that EGM is finished.
Anyone who has tried to make large, complicated rooms in Game Maker has been either bitterly disappointed or ingeniously crafty with regard to GM's rather limited room editor.
The quintessential example of a game that's fucking hard to make in GM is a Metroid platformer. There are two ways to go about the layout of a Metroid game in GM: There is the traditional method of creating a room for each little passage and cranny and using a complicated network of global variables to determine where you are coming from and where you are going, or there's the perhaps more advanced method of creating a large room of room-editor-lagging proportions and then using instances to denote regions to activate or deactivate as needed.
I have, in my longish and complicatedish game making history, made both a 2D and 3D Metroid Platformer, using a version (albeit a crude one) of the above strategies. It's quite possible that I've missed a strategy more form-fitting of Game Maker's... capabilities, but even in retrospect, I am not seeing a better way of pulling it off.
Enter EGM. Enter Overworld Resource.
Now that the EGM format is complete, we are capable of extending the existing room resource and adding a new resource on top of it.
Extending the room resource, we would allow for users to define their own "regions," as MrGriggs called them when he suggested them. These regions would be simple geometric shapes (possibly just box and circle) which, using a new set of room_region_* functions, the user would be able to test for being inside of. We then could have an instance_(de)activate_region function. Other modifications could be made to associate certain resource groups with regions, but this is part of another proposal I should probably post next.
Now, for the new resource, Overworld. Essentially, the overworld resource would allow users to place rooms into a larger room editor, the overworld editor. Ism would pre-render low-resolution previews of the room (she could fetch larger previews upon zoom) and allow users to place them in correct proportion on the Overworld map. A set of functions would be provided to get the full rectangle coordinates of a given room in the map, and contiguous rooms could be mapped together to allow quick searching for neighbors.
With that in mind, rooms could be easily reused without a complicated network of user-defined globals, such as room_to_left, room_to_right, room_above, room_below, or, worst of all, x_coming_from, y_coming_from.
Using the Overworld function set, a user could convert x-y room coordinates to x-y overworld coordinates by adding overworld_get_room_x(room_in_overworld) and overworld_get_room_y(room_in_overworld). The user could then translate those coordinates in the appropriate direction so as to leave the current room (essentially walking the character over), then make two calls to overworld_ functions to determine which room is actually going to be entered, and convert the overworld x-y pair back to room x-y pair after the room has been reassigned.
This topic is a good place for argument as to the exact functions to be made available, and this wiki page is a good place to put the results: http://enigma-dev.org/docs/Wiki/Overworld
Cheers.
Anyone who has tried to make large, complicated rooms in Game Maker has been either bitterly disappointed or ingeniously crafty with regard to GM's rather limited room editor.
The quintessential example of a game that's fucking hard to make in GM is a Metroid platformer. There are two ways to go about the layout of a Metroid game in GM: There is the traditional method of creating a room for each little passage and cranny and using a complicated network of global variables to determine where you are coming from and where you are going, or there's the perhaps more advanced method of creating a large room of room-editor-lagging proportions and then using instances to denote regions to activate or deactivate as needed.
I have, in my longish and complicatedish game making history, made both a 2D and 3D Metroid Platformer, using a version (albeit a crude one) of the above strategies. It's quite possible that I've missed a strategy more form-fitting of Game Maker's... capabilities, but even in retrospect, I am not seeing a better way of pulling it off.
Enter EGM. Enter Overworld Resource.
Now that the EGM format is complete, we are capable of extending the existing room resource and adding a new resource on top of it.
Extending the room resource, we would allow for users to define their own "regions," as MrGriggs called them when he suggested them. These regions would be simple geometric shapes (possibly just box and circle) which, using a new set of room_region_* functions, the user would be able to test for being inside of. We then could have an instance_(de)activate_region function. Other modifications could be made to associate certain resource groups with regions, but this is part of another proposal I should probably post next.
Now, for the new resource, Overworld. Essentially, the overworld resource would allow users to place rooms into a larger room editor, the overworld editor. Ism would pre-render low-resolution previews of the room (she could fetch larger previews upon zoom) and allow users to place them in correct proportion on the Overworld map. A set of functions would be provided to get the full rectangle coordinates of a given room in the map, and contiguous rooms could be mapped together to allow quick searching for neighbors.
With that in mind, rooms could be easily reused without a complicated network of user-defined globals, such as room_to_left, room_to_right, room_above, room_below, or, worst of all, x_coming_from, y_coming_from.
Using the Overworld function set, a user could convert x-y room coordinates to x-y overworld coordinates by adding overworld_get_room_x(room_in_overworld) and overworld_get_room_y(room_in_overworld). The user could then translate those coordinates in the appropriate direction so as to leave the current room (essentially walking the character over), then make two calls to overworld_ functions to determine which room is actually going to be entered, and convert the overworld x-y pair back to room x-y pair after the room has been reassigned.
This topic is a good place for argument as to the exact functions to be made available, and this wiki page is a good place to put the results: http://enigma-dev.org/docs/Wiki/Overworld
Cheers.
1221
Issues Help Desk / Re: svnkit error
« on: October 19, 2011, 09:43:23 am »
MinGW-get is having problems at the moment, because the MinGW team is understaffed or incapable (I know the former is true; I scream about the latter sometimes when bugs surface).
Other than that, your problem has all the symptoms of someone checking out from the SVN and calling Java on LGM manually. On most platforms, that's an option, but on Windows, we have to assume that the userbase doesn't know how to do that and so distribute install zips.
Edit: Let me clarify. I said "Other than that" because if the MinGW team had fixed their issues in the meantime, without my knowledge, that is the assumption I would have made. However, it seems mingw-get is still very much broke, and so you will either have to run their manual installer (selecting msys and gcc) or just wait for them to fix that. They're not a very responsible team.
Other than that, your problem has all the symptoms of someone checking out from the SVN and calling Java on LGM manually. On most platforms, that's an option, but on Windows, we have to assume that the userbase doesn't know how to do that and so distribute install zips.
Edit: Let me clarify. I said "Other than that" because if the MinGW team had fixed their issues in the meantime, without my knowledge, that is the assumption I would have made. However, it seems mingw-get is still very much broke, and so you will either have to run their manual installer (selecting msys and gcc) or just wait for them to fix that. They're not a very responsible team.
1222
General ENIGMA / Re: Compiling game without console.
« on: October 19, 2011, 09:13:32 am »
ENIGMA uses new for each instance, rather than new[] on several. Normally, you are right; requesting a contiguous plot of memory at once instead of asking 10 times for plots 10% of the size is much faster, but you will only see that overhead, ideally, once per instance on the screen. Destroying an instance and then creating a new one of the same size has less overhead, if I recall correctly.
However, allocation times don't really worry me. If they did, I could come up with a far better way of handling this on systems with large memory and slow allocation (systems with small memory presumably have less applications to serve it to, ergo would be quicker on the draw, I would think).
Basically, what I would do is allocate our own heap up front and keep a journal of available spots. We would then write our own new using new() (by your notation, I guess this would be new()()). Basically, we would take the max size between all objects, then pick a random heap size (Probably of 20-40, but I think it'd be wise to give users a say in this), and allocate a grid that way. The journal would then be populated with available spots on the grid. Allocation would be very fast, and deletion would simply queue up a new slot on the journal. As you can tell, the journal would probably be a queue or stack.
As for room regions, I think I know what you're talking about. In a Metroid game I made once, I needed to deactivate all instances except for those contained in rectangular sections of the room. What I did was create two objects with different sprites, one representing the upper-left corner and the other representing the lower-right. I would place these instances in the room and then use their room creation code to group them. Telling which regions you were in would then be as simple as iterating them and testing a few x > other.x. However, ENIGMA presently doesn't support instance creation codes or instance deactivation, so the point is presently moot.
Anyway, is that what you are talking about by regions? The room editor is about to undergo some rethinking as we add the new ENIGMA resource, "Overworld." Feel free to make suggestions on that. I will post a topic with regard to the new resource on proposals; I invite you to either respond there or to create a new proposal topic on the matter.
However, allocation times don't really worry me. If they did, I could come up with a far better way of handling this on systems with large memory and slow allocation (systems with small memory presumably have less applications to serve it to, ergo would be quicker on the draw, I would think).
Basically, what I would do is allocate our own heap up front and keep a journal of available spots. We would then write our own new using new() (by your notation, I guess this would be new()()). Basically, we would take the max size between all objects, then pick a random heap size (Probably of 20-40, but I think it'd be wise to give users a say in this), and allocate a grid that way. The journal would then be populated with available spots on the grid. Allocation would be very fast, and deletion would simply queue up a new slot on the journal. As you can tell, the journal would probably be a queue or stack.
As for room regions, I think I know what you're talking about. In a Metroid game I made once, I needed to deactivate all instances except for those contained in rectangular sections of the room. What I did was create two objects with different sprites, one representing the upper-left corner and the other representing the lower-right. I would place these instances in the room and then use their room creation code to group them. Telling which regions you were in would then be as simple as iterating them and testing a few x > other.x. However, ENIGMA presently doesn't support instance creation codes or instance deactivation, so the point is presently moot.
Anyway, is that what you are talking about by regions? The room editor is about to undergo some rethinking as we add the new ENIGMA resource, "Overworld." Feel free to make suggestions on that. I will post a topic with regard to the new resource on proposals; I invite you to either respond there or to create a new proposal topic on the matter.
1223
General ENIGMA / Re: Compiling game without console.
« on: October 17, 2011, 01:19:56 pm »
I thought it was January.
1224
General ENIGMA / Re: Compiling game without console.
« on: October 17, 2011, 11:38:33 am »
We're working on it. Should be done by the end of the week.
1225
Tips, Tutorials, Examples / Re: How to properly use OpenGL
« on: October 05, 2011, 10:47:01 am »
I don't know if you've noticed, but the macro already does that.
#define untexture() if(enigma::bound_texture) glBindTexture(GL_TEXTURE_2D,enigma::bound_texture=0);
It's done that since the dawn of time.
While it's possible that VBO, being newer, could be faster than lists, I'm mostly concerned about support. Deprecated, maybe, but still supported to at least the point of working on the shittiest cards with the shittiest drivers. Any card that gives GL lists no boost probably doesn't bother offering the VBO extension. On top of that, I have no benchmark to suggest superior speed either way. Perhaps once I've actually implemented tiles, I can move to Windows and test one list implementation and one VBO implementation. I've got a pretty new graphics card (few months old), so I'm sure it'll be as fair a representative as one card could ever be.
#define untexture() if(enigma::bound_texture) glBindTexture(GL_TEXTURE_2D,enigma::bound_texture=0);
It's done that since the dawn of time.
While it's possible that VBO, being newer, could be faster than lists, I'm mostly concerned about support. Deprecated, maybe, but still supported to at least the point of working on the shittiest cards with the shittiest drivers. Any card that gives GL lists no boost probably doesn't bother offering the VBO extension. On top of that, I have no benchmark to suggest superior speed either way. Perhaps once I've actually implemented tiles, I can move to Windows and test one list implementation and one VBO implementation. I've got a pretty new graphics card (few months old), so I'm sure it'll be as fair a representative as one card could ever be.
1226
Tips, Tutorials, Examples / Re: How to properly use OpenGL
« on: October 04, 2011, 07:15:07 pm »
I was talking to HaRRi, luis.
He was the one that mentioned my name.
It may prove that VBO is more widely available as an extension now that Microsoft has their head out of their ass GL-wise. In the meantime, the deprecated, proven method is the way to go.
I don't believe for a minute that you've found any situation in which VBO would accelerate primitive drawings and lists wouldn't.
He was the one that mentioned my name.
It may prove that VBO is more widely available as an extension now that Microsoft has their head out of their ass GL-wise. In the meantime, the deprecated, proven method is the way to go.
I don't believe for a minute that you've found any situation in which VBO would accelerate primitive drawings and lists wouldn't.
1227
Tips, Tutorials, Examples / Re: How to properly use OpenGL
« on: October 04, 2011, 05:54:40 pm »
I told you that I intend to use lists for tiles. I'll bet you a hand of bananas it's faster than a VBO.
If you find a way to remove the texture flipping at the beginning of each draw function, you let me know.
If you find a way to remove the texture flipping at the beginning of each draw function, you let me know.
1228
Proposals / Re: HTML5 exporter
« on: September 27, 2011, 04:41:42 pm »
Nah, JavaScript already has plenty of wrappers to the C++ map structures.
1229
Proposals / Re: HTML5 exporter
« on: September 27, 2011, 04:02:47 pm »
And the JVM is made of non-C++ metaphysical goo, right?
1230
Announcements / Re: ENIGMA forums are dead again
« on: September 27, 2011, 10:24:49 am »
Game_Boy: ENIGMA works. It just doesn't do all of Game Maker.
Even in its current state it provides everything needed to implement the remaining GM functionality. I just assumed there would be more interest in aiding the project's development than there has actually ever proven to be.
Anyway, I haven't started recoding the parser yet, and may not for a while, as our present system has proven sufficient. It's also a large commitment to switch to Clang. In the meantime I've been correcting some bugs.
Even in its current state it provides everything needed to implement the remaining GM functionality. I just assumed there would be more interest in aiding the project's development than there has actually ever proven to be.
Anyway, I haven't started recoding the parser yet, and may not for a while, as our present system has proven sufficient. It's also a large commitment to switch to Clang. In the meantime I've been correcting some bugs.
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 »