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 »
1546
General ENIGMA / Re: Cross-compiling
« on: December 13, 2010, 12:07:51 am »
No, there is no special form for links. I was indicating that systems like Box2D would be added to the collision system list. Setting custom links is messy; that should only be required when the system can't be integrated elsewhere. But yes, that much is necessary.
As far as changing the compile flags, we have a lot more than that to change, as is becoming more and more evident. Someone signed into the IRC who was having problems getting ENIGMA to coexist peacefully with DevKitPro's Msys. It was a complete clusterfuck. It didn't help that Tortoise SVN was betraying us the whole way, either...
Damn.
As far as changing the compile flags, we have a lot more than that to change, as is becoming more and more evident. Someone signed into the IRC who was having problems getting ENIGMA to coexist peacefully with DevKitPro's Msys. It was a complete clusterfuck. It didn't help that Tortoise SVN was betraying us the whole way, either...
Damn.
1547
General ENIGMA / Re: Cross-compiling
« on: December 11, 2010, 10:17:39 pm »
<..<
Opened ENIGMA settings lately, Retro?
Opened ENIGMA settings lately, Retro?
1548
General ENIGMA / Re: Cross-compiling
« on: December 11, 2010, 11:40:17 am »
Not just Mac. We're sticking to Mac because I've not yet started the Wii port and I don't own any other consoles for which I'd like to see ENIGMA work in the near future. It may happen that I'll end up thinking up a spec tailored to the Wii, and TGMG will make it work for Mac, iPhone, and Android.
Not to be a dick or anything, as TGMG has contributed some ideas to this mix, but it's so far been me who ends up writing the big picture shit that just needs to work, anyway. (I'd never expect anyone to mess with any of the parsers; it was neat enough that TGMG made the necessary modifications to the compiler source to get it working for those platforms at all). It's just that, as far as I can tell, this cross-compiling nonsense isn't going to happen until I have a release ready for Wii (which may in fact be sometime near New Year's).
Not to be a dick or anything, as TGMG has contributed some ideas to this mix, but it's so far been me who ends up writing the big picture shit that just needs to work, anyway. (I'd never expect anyone to mess with any of the parsers; it was neat enough that TGMG made the necessary modifications to the compiler source to get it working for those platforms at all). It's just that, as far as I can tell, this cross-compiling nonsense isn't going to happen until I have a release ready for Wii (which may in fact be sometime near New Year's).
1549
General ENIGMA / Re: Cross-compiling
« on: December 11, 2010, 10:12:30 am »
This isn't something that can be done with the three of us PMing each other. We need to discuss a spec that provides for the needs of all supported platforms.
1550
General ENIGMA / Re: Cross-compiling
« on: December 11, 2010, 01:10:25 am »
Just leave that to me.
It's been a planned part of the iPhone/Android integration. By the same mechanism you chose a compiler for those devices, you will be able to choose a cross-compiler.
Issue is, Ism, TGMG, and myself are never on concurrently.
It's been a planned part of the iPhone/Android integration. By the same mechanism you chose a compiler for those devices, you will be able to choose a cross-compiler.
Issue is, Ism, TGMG, and myself are never on concurrently.
1551
Function Peer Review / Re: NEEDED FUNCTION LIST
« on: December 07, 2010, 08:43:15 pm »
That folder's TBR. But I was considering renaming Platforms... I'm still not positive about that layout.
We do need a new directory called "Widgets"... I've not decided how to link that up with GL/DX....
We do need a new directory called "Widgets"... I've not decided how to link that up with GL/DX....
1552
General ENIGMA / Re: Linux Repositories
« on: December 07, 2010, 06:53:31 pm »
Yeah, I read that but forgot to acknowledge it. I probably won't be adding anything to the downloads page until I can get nothing but from a release.
...Presently, ENIGMA doesn't work out of the box on Mac without acute modification, so I'm withholding release until it works. By the time it does, collisions will probably be in, too. So.
...Presently, ENIGMA doesn't work out of the box on Mac without acute modification, so I'm withholding release until it works. By the time it does, collisions will probably be in, too. So.
1553
Function Peer Review / Re: NEEDED FUNCTION LIST
« on: December 07, 2010, 03:22:17 pm »
Let me reiterate (again) that I have no idea why those damn GM*.h headers are still in there. I wrote most of them when I was fourteen. It's time to remove them.
I deleted them years ago and they have since magically resurfaced (Thank you subversion). And as you can see, they're spawning now, and it's kind of obnoxious.
I deleted them years ago and they have since magically resurfaced (Thank you subversion). And as you can see, they're spawning now, and it's kind of obnoxious.
1555
Proposals / Re: Code Formatting
« on: December 06, 2010, 09:14:13 am »
Wow, I actually had -not- considered that, polygone. I'll add that to my growing list of ways to boost ENIGMA's notoriety.
1556
General ENIGMA / Re: variable_* Functions
« on: December 05, 2010, 10:03:03 pm »
There's no way to implement them... efficiently. Doing so requires two modifications. They're difficult to make, but only because it pains me to do so. Each variant needs a bool to indicate whether it's been assigned, then each operator needs overloaded to a hash table needs constructed in each instance for new variables added, and a table needs constructed for each object to reference hard-compiled variables.
Honestly, I hardly intend on doing it. But I'm sure someone will cry about it at some point and I'll implement it.
Honestly, I hardly intend on doing it. But I'm sure someone will cry about it at some point and I'll implement it.
1557
Function Peer Review / Re: Custom: Curve drawing functions (Bezier and Spline)
« on: December 04, 2010, 09:18:06 pm »
HaRRi, I think if you're going to offer an AA function, it may as well be for all primitives. Let the user make the call to it before and after spline drawing, if they like.
Luis, using a list would increase RAM. It would save push_back for the duration of one frame, then one subtract each frame, but at the cost of another add-dereference from there on. It doesn't really seem worth it...
Luis, using a list would increase RAM. It would save push_back for the duration of one frame, then one subtract each frame, but at the cost of another add-dereference from there on. It doesn't really seem worth it...
1558
Function Peer Review / Re: Custom: Curve drawing functions (Bezier and Spline)
« on: December 04, 2010, 07:53:27 am »
Yes, overwriting vectors. No, vectors are slow at push_back(). push_back is best case O(1), worst case O(N), and I'd wager the worst case happens the most often. Accessing [] with vectors is O(1). [] just looks up a number, push_back allocates more memory, which often means moving the memory it has. Using push_back for every point every step could mean N^2/2 operations (where N is the number of points) (but I doubt it). Only using push_back when necessary means one frame of N^2/2 disaster case, then the rest are N.
And yes, it's exactly one instruction faster not to return zero. Which could be as much as 20% in the case of draw_primitive_begin(). But that's a really small time, anyway; I'm not too worried. Returning void could mean a compile error if someone tried to assign the return value to a function. (Perhaps I should add checking for that...)
And yes, it's exactly one instruction faster not to return zero. Which could be as much as 20% in the case of draw_primitive_begin(). But that's a really small time, anyway; I'm not too worried. Returning void could mean a compile error if someone tried to assign the return value to a function. (Perhaps I should add checking for that...)
1559
Issues Help Desk / Re: Can't draw anything inside _begin _end
« on: December 04, 2010, 04:56:21 am »
Well, since the draw event only clears it every time, you'd still have to keep your own array.
The speed will actually decrease from keeping your own array. It is much more efficient to outsource point management to the GPU. Not to mention the number of function calls doubles by this method. At it's simplest, now we're keeping a nonstatic array, and the GPU is keeping a static one. The difference in the long run, though, is negligible; most of the work here is probably in drawing the primitive.
But yes, I see how drawing a circle around each vertex could be useful, so if you have not, I will probably preprocess the current primitive functions manually and rename them to draw_begin, draw_vertex2d() and draw_end(). Then our Game Maker equivalents can do their craziness.
Issue is, now I have to store texture and color data in the array, too.
The speed will actually decrease from keeping your own array. It is much more efficient to outsource point management to the GPU. Not to mention the number of function calls doubles by this method. At it's simplest, now we're keeping a nonstatic array, and the GPU is keeping a static one. The difference in the long run, though, is negligible; most of the work here is probably in drawing the primitive.
But yes, I see how drawing a circle around each vertex could be useful, so if you have not, I will probably preprocess the current primitive functions manually and rename them to draw_begin, draw_vertex2d() and draw_end(). Then our Game Maker equivalents can do their craziness.
Issue is, now I have to store texture and color data in the array, too.
1560
Function Peer Review / Re: Custom: Curve drawing functions (Bezier and Spline)
« on: December 04, 2010, 04:28:53 am »
The unofficial GM spec says all functions have a return value. I haven't completely decided to stray from that, though I myself tend to use void.
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 »