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 »
1561
Function Peer Review / Re: Custom: Curve drawing functions (Bezier and Spline)
« on: December 03, 2010, 07:13:55 pm »
Please make that vector static. You can remove points with vector::clear(). If you don't use a stack, you can't have nested splines (earlier you complained about a lack of nested primitives).
The hope is that the point you declare in the function is never instantiated; that instead, the optimizer makes it so the point is written directly on the space allocated by vector<>.
Instead of clearing it, it would be more efficient (speed wise, not memory wise) to keep your own static index, and only push back if index >= vector::size(). That way, you can just reset the index when begin() is called, and the system doesn't need to waste time on allocation otherwise (especially for repetitive spline drawing).
The hope is that the point you declare in the function is never instantiated; that instead, the optimizer makes it so the point is written directly on the space allocated by vector<>.
Instead of clearing it, it would be more efficient (speed wise, not memory wise) to keep your own static index, and only push back if index >= vector::size(). That way, you can just reset the index when begin() is called, and the system doesn't need to waste time on allocation otherwise (especially for repetitive spline drawing).
1562
Function Peer Review / Re: Custom: Curve drawing functions (Bezier and Spline)
« on: December 02, 2010, 11:26:06 am »
Done. And that's probably a good idea until you get the hang of ENIGMA.
I trust you'll commit your merge_color fix, too?
Also, we do have an IRC for this quick back-and-forth sort of thing.
I trust you'll commit your merge_color fix, too?
Also, we do have an IRC for this quick back-and-forth sort of thing.
1563
Function Peer Review / Re: Custom: Curve drawing functions (Bezier and Spline)
« on: December 02, 2010, 11:09:48 am »
Which is why I added you. You understand the implications of committing code; you'll be careful. Adding a couple files typically won't break anything. Just don't forget to commit any files you include. If you keep posting about them here, we can look over it and either have you make changes or implement them ourselves. Ultimately, collaboration should pay off in the end.
You're not Harold.Z on SourceForge?
You're not Harold.Z on SourceForge?
1564
Function Peer Review / Re: Custom: Curve drawing functions (Bezier and Spline)
« on: December 02, 2010, 10:55:54 am »
They look nice, HaRRi. I'd recommend keeping your own array, though. Here is my suggestion:
Don't implement any PEBKAC checking until ENIGMA has a centralized error system.
When you're done, feel free to commit your code using your SourceForge details.
...Welcome aboard.
Code: (C++) [Select]
#include <stack>
#include <vector>
struct splinePoint { float x,y; };
typedef std::vector<splinePoint> a_spline;
static std::vector<a_spline*> startedSplines;
void draw_spline_begin() { startedSplines.push(new a_spline); }
void draw_spline_vertex(float x, float y) { startedSplines.top()->push_back(splinePoint(x,y)); }
void draw_spline_end() {
a_spline &arr = *startedSplines.top();
for (int i = 0; i < arr.size(); i++)
draw_spline_part( /* I Have no idea of the use case of this function.
Access points with arr[num]. Do bounds checking. It may be frugal
to unroll the first and last four elements; remember, the array can
contain as few as zero points! */ );
delete &arr;
startedSplines.pop();
}
Don't implement any PEBKAC checking until ENIGMA has a centralized error system.
When you're done, feel free to commit your code using your SourceForge details.
...Welcome aboard.
1565
Announcements / Re: Scalability
« on: December 02, 2010, 10:33:17 am »
I started adding some of the file functions to one of those pages, so I don't see why not.
1566
Issues Help Desk / Re: Can't draw anything inside _begin _end
« on: December 01, 2010, 01:57:19 pm »
Essentially. It would require a less-than check every primitive, which is what I consider to be a waste of time. I may offer a second set of primitive functions that have no such time consumers (and smaller names. I'm thinking just draw_begin(), draw_end()).
1567
Issues Help Desk / Re: Can't draw anything inside _begin _end
« on: November 30, 2010, 05:37:12 pm »
Indeed, I chose not to use a custom vertex buffer to render primitives, and nested glBegin()s are invalid. I am unsure why you would be drawing a circle inside your primitive calls in the first place, but if you can make a case for it I'd be happy to use a dynamic array for a custom VBO (another 1980 GL spec that Intel refuses to support).
merge_color worked at one point, but serp found a more efficient way. He just never tests his efficient ways thoroughly. Notice the tabs everywhere. Not my trademark...
merge_color worked at one point, but serp found a more efficient way. He just never tests his efficient ways thoroughly. Notice the tabs everywhere. Not my trademark...
1568
Announcements / Re: Scalability
« on: November 28, 2010, 11:27:06 pm »
Well, no, it isn't. It's a valid page name, but not a valid user name.
Yes, it says "login," but that's from the "Create Account" dialog.
Anyway, even if it were a valid username, I'd still need a unix page if I intended to use any username-based upload services ever to be offered on this forum (which, as I hinted, will only happen when ENIGMA's on dedicated hosting, which itself will only happen when ENIGMA has the traffic required to generate ad revenue to pay for such or a good chunk of such).
Oh, and fede, let me reclarify: the difference between a bug and a missing figure is not well-conveyed by your post. The edit buttons are just there for show; they were never actually implemented at all.
Quote
Login error
You have not specified a valid user name.
Yes, it says "login," but that's from the "Create Account" dialog.
Anyway, even if it were a valid username, I'd still need a unix page if I intended to use any username-based upload services ever to be offered on this forum (which, as I hinted, will only happen when ENIGMA's on dedicated hosting, which itself will only happen when ENIGMA has the traffic required to generate ad revenue to pay for such or a good chunk of such).
Oh, and fede, let me reclarify: the difference between a bug and a missing figure is not well-conveyed by your post. The edit buttons are just there for show; they were never actually implemented at all.
1569
Announcements / Re: Scalability
« on: November 25, 2010, 02:55:43 pm »
First come, first served.
...But no.
...But no.
1570
Announcements / Re: Scalability
« on: November 25, 2010, 09:30:57 am »
a2h:
That'd work, but it'd make URLs comparatively difficult to remember if it can be avoided.
fede:
The tracker isn't complete. There's a difference between a bug and a missing feature.
That'd work, but it'd make URLs comparatively difficult to remember if it can be avoided.
fede:
The tracker isn't complete. There's a difference between a bug and a missing feature.
1571
Issues Help Desk / Re: extern double returns 0
« on: November 25, 2010, 09:26:50 am »
Restarting LGM shouldn't really have fixed that. Your current_time actually doesn't behave like GM's at all; GM's (as you said) returns milliseconds since boot, but it is also an accessor. What I mean is, you can use current_time to time operations in a script.
I'll see about implementing that one... it won't be as easy to mimic in C++ as extern double current_time;.
I'll see about implementing that one... it won't be as easy to mimic in C++ as extern double current_time;.
1572
Announcements / Re: Scalability
« on: November 24, 2010, 09:13:27 pm »
The forum and tracker share a login. That's the idea. The only change in your name for option one would be the spaces. If we pull off option two, you would not notice a change, and any commits you make in the Wiki and any files you upload (should we add such a system) would be stored under The11thplagueofEgypt. But, in the event we have to go with the first one, I guess we could hold an opinion poll before we make the change. But eventually, I believe this change will need implemented, and so it may be frugal to do so ahead of time. As in, now; the first time it's needed.
1573
Announcements / Re: Scalability
« on: November 24, 2010, 02:50:47 pm »
They may need to be able to edit their unix names. People like serp tend to deal with the unavailability of a name ("s" in serp's case) by prefixing underscores. Those are technically unix compliant, but Wikis evidently don't like them. That said, the user needs some sort of say in their unix name.
For now, if for any reason the letters-digits forms of any two names in our database collide, we will simply add a "2". The user needs the ability to do that as well (But the opportunity to be original; their name will be visible in their URL).
For now, if for any reason the letters-digits forms of any two names in our database collide, we will simply add a "2". The user needs the ability to do that as well (But the opportunity to be original; their name will be visible in their URL).
1574
Announcements / Scalability
« on: November 24, 2010, 12:10:21 pm »
This r/coderaid business has made me realize that ENIGMA's site is not ready for the same kind of jumps that ENIGMA itself is ready to make. While the engine is scalable in the sense that most of the systems are completely modular now, the site is based off of SMF, which has a very sad excuse for a user name system.
We now have a bug tracker -and- a Wiki to contend with as far as users are concerned. Since a2h wrote the tracker himself, we haven't had issue with it. But the new Wiki requires an entirely new user base, and it just isn't compatible with SMF. The crossover that was written for it does not comply with SMF 2.0; from what I can tell, the database system between 1.2 and 2.0 is -very- different. They are similar enough that I think a port is possible, but then we have a new issue: user name content. "Josh @ Dreamland" isn't exactly a Unix name. However, Wikis don't agree with underscores or dashes, either. That's difficult to work around with our current layout.
We have two options.
1) Change everyone's login name, leaving the display name.
This means I will have to log in as JoshDreamland from now on, but you will still see me as Josh @ Dreamland on the forums. Score_Under will have to log in as ScoreUnder. I don't have figures on the matter, but from what I can tell, the number of people affected will be approximately a lot.
2) Add another field to the SMF SQL table for Unix names. This puts less strain on the users, but more on the web developers trying to port bridge modules such as SMF-Wiki. What I mean is, a2h or myself will have to custom-tailor bridge code such as the code that enables MediaWiki to use SMF user names. Also, we have to modify SMF's account creation process, and run a script on our current SQL tables to generate Unix names for the 350 existing members and check for conflicts (this is the easy part). I don't personally have the web experience to make the former change to SMF, and I'm not going to volunteer a2h to do this.
This is here as an FYI for what might happen. If a2h doesn't appraise as simple modifying the user creation query to generate a unix name and store it with the rest of the information, we may go with option one and change at least a tenth of everyone's logins. We can probably post a notice about that to help members remember (most of them will just enter it once and tell FireFox to change it).
So, yes. Just a heads up. If you have a better idea, let us know, of course.
And if you're outraged about all this work over a Wiki, this is =not= the last time we'll be seeing this issue. Look at 64Digits. I am confident in saying that if we have an influx of users, we can start a 64Digits-like hosting system. When we do that, a behind-the-scenes Unix naming convention will be very handy, otherwise some download URLs may be invalid or difficult to escape (think of all the %20s!).
-Josh
We now have a bug tracker -and- a Wiki to contend with as far as users are concerned. Since a2h wrote the tracker himself, we haven't had issue with it. But the new Wiki requires an entirely new user base, and it just isn't compatible with SMF. The crossover that was written for it does not comply with SMF 2.0; from what I can tell, the database system between 1.2 and 2.0 is -very- different. They are similar enough that I think a port is possible, but then we have a new issue: user name content. "Josh @ Dreamland" isn't exactly a Unix name. However, Wikis don't agree with underscores or dashes, either. That's difficult to work around with our current layout.
We have two options.
1) Change everyone's login name, leaving the display name.
This means I will have to log in as JoshDreamland from now on, but you will still see me as Josh @ Dreamland on the forums. Score_Under will have to log in as ScoreUnder. I don't have figures on the matter, but from what I can tell, the number of people affected will be approximately a lot.
2) Add another field to the SMF SQL table for Unix names. This puts less strain on the users, but more on the web developers trying to port bridge modules such as SMF-Wiki. What I mean is, a2h or myself will have to custom-tailor bridge code such as the code that enables MediaWiki to use SMF user names. Also, we have to modify SMF's account creation process, and run a script on our current SQL tables to generate Unix names for the 350 existing members and check for conflicts (this is the easy part). I don't personally have the web experience to make the former change to SMF, and I'm not going to volunteer a2h to do this.
This is here as an FYI for what might happen. If a2h doesn't appraise as simple modifying the user creation query to generate a unix name and store it with the rest of the information, we may go with option one and change at least a tenth of everyone's logins. We can probably post a notice about that to help members remember (most of them will just enter it once and tell FireFox to change it).
So, yes. Just a heads up. If you have a better idea, let us know, of course.
And if you're outraged about all this work over a Wiki, this is =not= the last time we'll be seeing this issue. Look at 64Digits. I am confident in saying that if we have an influx of users, we can start a 64Digits-like hosting system. When we do that, a behind-the-scenes Unix naming convention will be very handy, otherwise some download URLs may be invalid or difficult to escape (think of all the %20s!).
-Josh
1575
Announcements / Re: r/coderaid
« on: November 23, 2010, 10:48:53 am »
I'm pretty much sick of working on the Wiki. Someone else do it, damn it.
I have better things to waste time and talent on.
I have better things to waste time and talent on.
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 »