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 »
1501
General ENIGMA / Re: String Physics
« on: January 10, 2011, 06:39:32 am »
HaRRi:
I didn't mean to imply that including a GL extensions library was all you had to do. You actually have to declare the function yourself and fetch a pointer to it.
Or something like that.
I didn't mean to imply that including a GL extensions library was all you had to do. You actually have to declare the function yourself and fetch a pointer to it.
Code: (C++) [Select]
void glGenFramebuffersEXT(GLsizei n, GLuint* ids) { show_error("Surfaces not supported by card."); }
void (*glGenFramebuffersEXT)(GLsizei n, GLuint* ids) = &error_function_glsize_gluint;
//...
if (WHATEVER_YOURE_USING_SUPPORTS("GL_FRAMEBUFFER_EXT"))
glGenFramebuffersEXT = WHATEVER_YOURE_USING_LOAD("GL_FRAMEBUFFER_EXT", "GL_GEN_FRAMEBUFFERS_EXT");
Or something like that.
1502
Proposals / Re: Object member functons
« on: January 09, 2011, 01:12:24 pm »
The stack is pushed twice at the beginning of the expression in my example, then popped twice right after.
pop_with(K) was what I was considering. But it wasn't until you posted it again that I realized I was thinking about it incorrectly. My first instinct was that there'd be no way to instantiate a template because the return type of func() can't be gathered from &func. But now I see that a simple template function would have done it.
So thank you, Luis; the simplicity of the matter escaped me.
pop_with(K) was what I was considering. But it wasn't until you posted it again that I realized I was thinking about it incorrectly. My first instinct was that there'd be no way to instantiate a template because the return type of func() can't be gathered from &func. But now I see that a simple template function would have done it.
Code: (C++) [Select]
inline template<typename any> any& pop_with(any &r) { return r; }
So thank you, Luis; the simplicity of the matter escaped me.
1503
Proposals / Re: Object member functons
« on: January 09, 2011, 12:41:29 am »
That's how with_iter works, luis. Issue is, you just passed func() the return value of enigma::pop_with().
1504
Proposals / Re: Object member functons
« on: January 08, 2011, 11:22:38 am »
Unfortunately, r9k, it's not that simple. It's not as simple as polygone's suggestion, either.
The only way to implement this cleanly is too flawed to implement:
I haven't yet found a way around this.
The only way to implement this cleanly is too flawed to implement:
Code: (GML) [Select]
obj1.func()
becomesCode: (C++) [Select]
(enigma::with_iter(obj1), func())
When the expression starts, it will be as though it was executed for obj1. When the expression ends, the with_iter will destruct, and the code will be back in its original scope. However, this will fail catastrophically:Code: (GML) [Select]
obj1.func(obj2.func())
Both will be executed for obj2. This is because at the beginning of the expression, obj1 is pushed as the current instance, then obj2 is as well.I haven't yet found a way around this.
1505
Proposals / Re: switch and mp_step functions.
« on: January 07, 2011, 02:38:48 pm »
Go for it. Feel free to do the A* shit, because I don't really want to.
1506
Proposals / Re: switch and mp_step functions.
« on: January 06, 2011, 10:57:49 pm »
I hate implementing functions, anymore. I much prefer just working on parser candy.
The worst part about this is that I had a discussion about mp_linear_step with a buddy not long ago, and I showed how an implementation of the function that performed -better- than Game Maker's could be written without an A* implementation (if only because Mark's A* implementation is a world-class failure).
Someone made a path plotting example in GM that used four different implementations; I think it would be neat if ENIGMA offered each of them to choose from.
The example I'm thinking of colored in all the tiles to show how it calculated the optimal path with the selected algorithm. If anyone knows which one I'm talking about, I'd appreciate if they indicated it to me once more (having a GM-friendly implemetation of these for at least reference would be a good thing).
As for switch, I guess it's about time I implemented that. I might just check if all of the case labels are literals to choose between C switch and GML switch, and screw the hash implementation.
The worst part about this is that I had a discussion about mp_linear_step with a buddy not long ago, and I showed how an implementation of the function that performed -better- than Game Maker's could be written without an A* implementation (if only because Mark's A* implementation is a world-class failure).
Someone made a path plotting example in GM that used four different implementations; I think it would be neat if ENIGMA offered each of them to choose from.
The example I'm thinking of colored in all the tiles to show how it calculated the optimal path with the selected algorithm. If anyone knows which one I'm talking about, I'd appreciate if they indicated it to me once more (having a GM-friendly implemetation of these for at least reference would be a good thing).
As for switch, I guess it's about time I implemented that. I might just check if all of the case labels are literals to choose between C switch and GML switch, and screw the hash implementation.
1507
Announcements / Re: Happenings
« on: January 05, 2011, 11:44:22 am »
yum install cook
cd /usr/ports/sysutils/cook && make && make install
Don't forget the sudo.
cd /usr/ports/sysutils/cook && make && make install
Don't forget the sudo.
1508
Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 05, 2011, 09:37:34 am »
Assuming you calculated the normal and took (distance-used_distance)*sin(dirdif(normal,dir)), then performed the second iteration perpendicular to that normal, it' work fine. Until, of course, you want us to check a third corner and so on. Then our algorithm becomes O(ND) as we have to keep iterating so long as there is yet any distance left to be iterated, not to mention it wouldn't look quite how the user would envision it in his ideal dream world. To get it to keep navigating around objects nicely, we would have to make our recursive calls to the function use no more of our remaining distance than it takes to move, in your drawing, inst1->bbox_left past inst2->bbox_right. Fortunately, with bboxes, all of this is insanely easy to calculate. Polygons and 3D meshes will not make this task quite so easy, and though it's well within the realm of possibility, my fear is, as always, efficiency.
The method may require a different subroutine to call that behaves like move_contact() but returns the distance it was able to travel before collision. That returned distance would then be subtracted from our remaining distance (we'd min() the distance required against the distance remaining before we ever invoked the subroutine to ensure this value will keep our remainder >= 0), and then the current function would be re-invoked.
It'd probably be useful and save memory to just return the distance traveled in the original move_contact. It's not like it won't already be in a register; returning it would probably just tell the compiler to keep it in eax.
The method may require a different subroutine to call that behaves like move_contact() but returns the distance it was able to travel before collision. That returned distance would then be subtracted from our remaining distance (we'd min() the distance required against the distance remaining before we ever invoked the subroutine to ensure this value will keep our remainder >= 0), and then the current function would be re-invoked.
It'd probably be useful and save memory to just return the distance traveled in the original move_contact. It's not like it won't already be in a register; returning it would probably just tell the compiler to keep it in eax.
1510
Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 04, 2011, 08:01:45 pm »
Oh, does it do so in GM? That would mean a change in algorithm (this one stops as soon as it hits a wall).
1511
Announcements / Re: Happenings
« on: January 04, 2011, 02:46:56 pm »
Yeah, that should never happen.
Yes, but the makefile needs updated. Ism updated it for you last time by running automake_all.sh from SHELL/.
You can update it manually, if you wish, or find a competent shell to update it for you. (Or commit and ask Ism to do so again, or I can).
I forget why I couldn't do fonts, be it compression or otherwise. We'll see about those...
Yes, but the makefile needs updated. Ism updated it for you last time by running automake_all.sh from SHELL/.
You can update it manually, if you wish, or find a competent shell to update it for you. (Or commit and ask Ism to do so again, or I can).
I forget why I couldn't do fonts, be it compression or otherwise. We'll see about those...
1512
Announcements / Happenings
« on: January 03, 2011, 07:42:06 pm »
So after four people in less than a month struggled to install ENIGMA, I've finally begun redoing ENIGMA.exe. It will automatically call mingw-get to install necessary files; the user needs only to specify a drive letter (if he or she is dissatisfied with the default, being the current drive). I was actually looking for a function to prompt for drive letter, but couldn't find one and so abandoned the notion.
In other news, Gary has added unix names to all user accounts. As new users sign up, they will be given a unix name (or can edit it themselves). This name will be used in the Wiki shortly enough, and for user upload directories and whatnot later on.
In what may be old news, ENIGMA is only three functionalities away from being able to run the official GM platform example perfectly. The three include instance_deactivate() and co, dialog functions (for showing and logging high scores), and tiles. We'll see about those three ASAP. (But after the Windows installer).
With any luck, the provisions I am implementing in the Windows installer (new organization system for compilers and makefiles) will mean, once and for all, simplicity of adding devices for which ENIGMA can officially compile. Also with this addition will come the ability to use ENIGMA portably if configured on a USB drive.
Wish us luck.
In other news, Gary has added unix names to all user accounts. As new users sign up, they will be given a unix name (or can edit it themselves). This name will be used in the Wiki shortly enough, and for user upload directories and whatnot later on.
In what may be old news, ENIGMA is only three functionalities away from being able to run the official GM platform example perfectly. The three include instance_deactivate() and co, dialog functions (for showing and logging high scores), and tiles. We'll see about those three ASAP. (But after the Windows installer).
With any luck, the provisions I am implementing in the Windows installer (new organization system for compilers and makefiles) will mean, once and for all, simplicity of adding devices for which ENIGMA can officially compile. Also with this addition will come the ability to use ENIGMA portably if configured on a USB drive.
Wish us luck.
1513
Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 03, 2011, 12:22:31 pm »
>You can't easily check for 'solid objects that collide with box from the two furthest points' when only using one reference point on the bbox.
Yes, you can. That's why I broke it into quadrants. I didn't have time to sketch up my idea yesterday (or even to draft it fully), but today, I do.
http://dl.dropbox.com/u/1052740/MoveBboxSolid.png
Yes, you can. That's why I broke it into quadrants. I didn't have time to sketch up my idea yesterday (or even to draft it fully), but today, I do.
http://dl.dropbox.com/u/1052740/MoveBboxSolid.png
Code: (C++) [Select]
case 0: // Quadrant 0; horizontal up to nearly vertical
const int dx = inst2->bbox_left - inst->bbox_right, dy = inst2->bbox_bottom - inst->bbox_top; // Get horizontal distance
const int tdt = (dx > dy)? dx/cos(dir) : dy*sin(dir);
if (tdt < td and /*a rectangle that is our translated rectangle with a 1px border collides with our inst2->bbox*/ true)
td = tdt;
1514
Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 02, 2011, 11:59:33 pm »
A for loop is unnecessary with bboxes.
1) Calculate furthest bbox point when translated from the untranslated position.
i. If your bottom-left corner is at (0,0) and you are 32x32 pixels, and you are checking 10px at 45 degrees, the coordinate you want is 10*cos(45 deg) + 32, 10*sin(45 deg) + 32
2) Loop, looking for solid objects that collide with box from the two furthest points ((0,0) and (10*cos(45 deg) + 32, 10*sin(45 deg) + 32) in our example)
3) Check untranslated rectangle for collisions; if you're colliding with it initially, we obviously can't move any closer, so break.ass
4) Switch the quadrant of our angle (wrap(angle,360) / 90). This code assumes inst is the current instance and inst1 is the instance we're looping through. Neither are translated from their original position. It assumes a variable representing total displacement, dt. distSquared is parameter dist * parameter dist.
I lack time to do the other three quadrants. You can do them and debug, or I will later. Peace.
1) Calculate furthest bbox point when translated from the untranslated position.
i. If your bottom-left corner is at (0,0) and you are 32x32 pixels, and you are checking 10px at 45 degrees, the coordinate you want is 10*cos(45 deg) + 32, 10*sin(45 deg) + 32
2) Loop, looking for solid objects that collide with box from the two furthest points ((0,0) and (10*cos(45 deg) + 32, 10*sin(45 deg) + 32) in our example)
3) Check untranslated rectangle for collisions; if you're colliding with it initially, we obviously can't move any closer, so break.ass
4) Switch the quadrant of our angle (wrap(angle,360) / 90). This code assumes inst is the current instance and inst1 is the instance we're looping through. Neither are translated from their original position. It assumes a variable representing total displacement, dt. distSquared is parameter dist * parameter dist.
Code: (C++) [Select]
case 0: // Quadrant 0; horizontal up to nearly vertical
const int dx = inst2->bbox_left - inst->bbox_right; // Get horizontal distance
const int tdt = (dx >= 0)?dx/cos(45) : (inst2->bbox_bottom - inst->bbox_top)*sin(45);
if (tdt < td)
td = tdt;
I lack time to do the other three quadrants. You can do them and debug, or I will later. Peace.
1515
Function Peer Review / Re: file_delete
« on: December 30, 2010, 09:11:10 pm »
It's implemented somewhere. It probably hasn't been included because its set isn't complete.
Most GM functions are easy to implement.
Most GM functions are easy to implement.
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 »