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 »
1636
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: October 31, 2010, 10:21:14 am »
> Even then thou, I think it was faster than GM.
It probably was. Or, at least, just as fast.
> Also, what would be the best way to load fonts on the fly?
If I knew that, I'd have done it years ago.
It probably was. Or, at least, just as fast.
> Also, what would be the best way to load fonts on the fly?
If I knew that, I'd have done it years ago.
1637
Function Peer Review / Re: GML: All draw_text functions (WIP)
« on: October 30, 2010, 09:53:19 am »
Oh, perhaps you took a different approach than I would have. ...Actually, looking at your code, your approach is exactly what I was about to suggest, only your precalculations are fewer than they could be. Also, I don't understand something...
ulcx = xx + g.tx * xscale * cvp + g.ty * yscale * cv2;
ulcy = yy - g.tx * xscale * svp - g.ty * yscale * sv2;
Why are you subtracting the texture coordinate from it? the texture coordinate is between 1 and 0...
From what I can tell. ulcx should just be xx...
Also, you do a lot of xscale * cx... this is the sort of thing that I was going to precalculate, and here's why:
Your method is very close to what I think is the fastest. When you draw text, even rotated, the text is still following a linear pattern: You can trace a line across the tops of the glyphs. So all we really need is a sort of slope calculation based on trig.
This is about as efficient as I can see making the function:
Also, don't sweat string manipulation. The only way the user could tell the difference between escaping # at compile time or treating it special at run time is to use chr(whatever) and concatenate. Other than that, if they try += "#", they'll just be saying += "\r\n", etc, etc.
ulcx = xx + g.tx * xscale * cvp + g.ty * yscale * cv2;
ulcy = yy - g.tx * xscale * svp - g.ty * yscale * sv2;
Why are you subtracting the texture coordinate from it? the texture coordinate is between 1 and 0...
From what I can tell. ulcx should just be xx...
Also, you do a lot of xscale * cx... this is the sort of thing that I was going to precalculate, and here's why:
Your method is very close to what I think is the fastest. When you draw text, even rotated, the text is still following a linear pattern: You can trace a line across the tops of the glyphs. So all we really need is a sort of slope calculation based on trig.
This is about as efficient as I can see making the function:
Code: (C++) [Select]
void draw_text_transformed(double x,double y,string str,double xscale,double yscale,double rot)
{
if (currentfont == -1)
return;
font *fnt = fontstructarray[currentfont];
if (cur_bou_tha_noo_sho_eve_cha_eve != fnt->texture)
glBindTexture(GL_TEXTURE_2D, cur_bou_tha_noo_sho_eve_cha_eve = fnt->texture);
float xx = (float)x, yy = (float)y;
float w, h = fnt->height*yscale;
rot *= M_PI/180;
const float sv = sin(rot), cv = cos(rot),
svx = sv*xscale, cvx = cv*xscale, hi = h * -sv,
sw = fnt->height/3 * cvx, sh = fnt->height/3 * svx;
glBegin(GL_QUADS);
for (unsigned i = 0; i < str.length(); i++)
{
if (str[i] == '\r')
xx = x, yy += hi, i += str[i+1] == '\n';
else if (str[i] == '\n')
xx = x, yy += hi;
else if (str[i] == ' ')
xx += sw,
yy -= sh;
else
{
fontglyph &g = fnt->glyphs[(unsigned char)(str[i] - fnt->glyphstart) % fnt->glyphcount];
w = (g.x2-g.x), h = (g.y2-g.y);
glTexCoord2f(g.tx, g.ty);
glVertex2f(xx, yy);
glTexCoord2f(g.tx2, g.ty);
glVertex2f(xx + w * cvx, yy - w * svx);
const float lx = xx + h * svx;
const float ly = yy + h * cvx;
glTexCoord2f(g.tx2, g.ty2);
glVertex2f(lx + w * cvx, ly - w * svx);
glTexCoord2f(g.tx, g.ty2);
glVertex2f(lx, ly);
xx += g.xs * cvx;
yy -= g.xs * svx;
}
}
glEnd();
}
Also, don't sweat string manipulation. The only way the user could tell the difference between escaping # at compile time or treating it special at run time is to use chr(whatever) and concatenate. Other than that, if they try += "#", they'll just be saying += "\r\n", etc, etc.
1638
Function Peer Review / Re: GML: All draw_text functions (WIP)
« on: October 29, 2010, 07:20:32 pm »
1) It is \r\n
2) The \r is optional in everything not strictly Microsoft (IE, not Notepad).
2) The \r is optional in everything not strictly Microsoft (IE, not Notepad).
1639
Function Peer Review / Re: GML: All draw_text functions (WIP)
« on: October 29, 2010, 06:32:09 pm »
Please don't do that.
ENIGMA lets you choose how to escape string literals. There are two settings, though you can't yet switch between them:
1) GML. "Quote inside quote looks like " + '"this."' + " Newlines are escaped from '#' automatically."
2) C++. "Quote inside quote looks like \"this.\" Newlines must use \\r\\n, like this: \r\n ^ line ^ \r\n # does nothing."
ENIGMA lets you choose how to escape string literals. There are two settings, though you can't yet switch between them:
1) GML. "Quote inside quote looks like " + '"this."' + " Newlines are escaped from '#' automatically."
2) C++. "Quote inside quote looks like \"this.\" Newlines must use \\r\\n, like this: \r\n ^ line ^ \r\n # does nothing."
1640
Function Peer Review / Re: GML: All draw_text functions (WIP)
« on: October 29, 2010, 06:18:36 pm »
First off, I'm quite impressed at how quickly you got on this; I haven't even announced that fonts were in.
More importantly, I have to express some concerns before I adopt these:
1) Trig functions and multiple multiplication operations are performed in each loop iteration for the transformed font functions. That is a costly move compared to what could be accomplished with a simple precalculation (considering none of them are dynamic, as far as I know).
2) I was not quite done with linear fonts at the time of commit. For example, look what happens to the "I" in this screen shot. It's not the spacing that concerns me as much as the fact that "I" is only one pixel wide. I fear the worst.
Your work is, of course, appreciated greatly nonetheless. Neither of those are a serious detriment; I will just need to go over them when I have a few more answers.
Good work.
Also, I was looking into regex for ENIGMA, but the best interpreter out there for C++ is apparently Boost, and they totally fucking overkill everything. I just want a damn preg_match and preg_replace for ENIGMA; it shouldn't be 65 source files and it shouldn't have a fucking config file. Damn it.
And one more thing: in case you're wondering where that screenshot came from, it started out as an example someone posted on the GMC, which I stumbled upon looking for an explanation of the parameters to font_add_sprite().
More importantly, I have to express some concerns before I adopt these:
1) Trig functions and multiple multiplication operations are performed in each loop iteration for the transformed font functions. That is a costly move compared to what could be accomplished with a simple precalculation (considering none of them are dynamic, as far as I know).
2) I was not quite done with linear fonts at the time of commit. For example, look what happens to the "I" in this screen shot. It's not the spacing that concerns me as much as the fact that "I" is only one pixel wide. I fear the worst.
Your work is, of course, appreciated greatly nonetheless. Neither of those are a serious detriment; I will just need to go over them when I have a few more answers.
Good work.
Also, I was looking into regex for ENIGMA, but the best interpreter out there for C++ is apparently Boost, and they totally fucking overkill everything. I just want a damn preg_match and preg_replace for ENIGMA; it shouldn't be 65 source files and it shouldn't have a fucking config file. Damn it.
And one more thing: in case you're wondering where that screenshot came from, it started out as an example someone posted on the GMC, which I stumbled upon looking for an explanation of the parameters to font_add_sprite().
1641
Function Peer Review / Re: move_towards_point + move_snap
« on: October 25, 2010, 08:40:20 pm »
#define motion_set(newdirection,newspeed) (direction=(newdirection), speed=(newspeed))
Is the STRICT EQUIVALENT to inline double motion_set(double newdirection,double newspeed) { return (direction=(newdirection), speed=(newspeed)); }. There is NO context under which the inline would work, and the macro I specified would not.
Furthermore, if ENIGMA's source is full of more complicated inline functions than this one, compile time will be a disaster.
Again, the reason to write a function for this instead of a macro is to save some trig in assigning hspeed and vspeed.
Is the STRICT EQUIVALENT to inline double motion_set(double newdirection,double newspeed) { return (direction=(newdirection), speed=(newspeed)); }. There is NO context under which the inline would work, and the macro I specified would not.
Furthermore, if ENIGMA's source is full of more complicated inline functions than this one, compile time will be a disaster.
Again, the reason to write a function for this instead of a macro is to save some trig in assigning hspeed and vspeed.
1642
Function Peer Review / Re: move_towards_point + move_snap
« on: October 25, 2010, 06:22:45 pm »
Because with macros, you can seamlessly manipulate locals such as direction and speed.
...An inline function would be more efficient, though, as hspeed and vspeed would only need to be edited once.
...An inline function would be more efficient, though, as hspeed and vspeed would only need to be edited once.
1643
Function Peer Review / Re: move_towards_point + move_snap
« on: October 25, 2010, 11:44:41 am »
In fact, I must be smoking something.
#define motion_set(newdirection,newspeed) (direction=(newdirection), speed=(newspeed))
#define motion_set(newdirection,newspeed) (direction=(newdirection), speed=(newspeed))
1644
Function Peer Review / Re: move_towards_point + move_snap
« on: October 25, 2010, 08:01:42 am »
Ouch, TGMG.
Never do this:
#define motion_set(newdirection,newspeed) direction=(newdirection); speed=newspeed;
Use this:
#define motion_set(newdirection,newspeed) direction=(newdirection), speed=newspeed;
or this:
#define motion_set(newdirection,newspeed) { direction=(newdirection); speed=newspeed; }
Otherwise...
with (all) motion_set(...)...
Never do this:
#define motion_set(newdirection,newspeed) direction=(newdirection); speed=newspeed;
Use this:
#define motion_set(newdirection,newspeed) direction=(newdirection), speed=newspeed;
or this:
#define motion_set(newdirection,newspeed) { direction=(newdirection); speed=newspeed; }
Otherwise...
with (all) motion_set(...)...
1645
Issues Help Desk / Re: Can't compile anymore? Whats up with that?
« on: October 24, 2010, 09:21:08 pm »
Wonder how I overlooked that.
1646
Issues Help Desk / Re: Can't compile anymore? Whats up with that?
« on: October 24, 2010, 04:52:01 pm »
How did you install it? Did you use mingw-get?
1647
Issues Help Desk / Re: Can't compile anymore? Whats up with that?
« on: October 24, 2010, 08:59:44 am »
I have never had luck using the MinGW that comes with Code::Blocks. I have no idea why. It doesn't seem much older than the one that comes with ENIGMA... I was thinking they specialized it just for use with their IDE.
Can you do me a favor, though? I need to modify ENIGMA.exe to make calls to MinGW's latest installer application, mingw-get. It's like apt-get, but for MinGW (Implying for Windows). Using mingw-get, I believe we can install all of GCC via calls to better_system() (already in the ENIGMA.exe source). I will get to this soon enough, but if you would like to give it a shot, be my guest. It should be as simple as calling better_system("C:\\mingw-get","install gcc"); (after actually copying mingw-get.exe to C:\MinGW, of course).
We'd then do the same for "install g++", "install make", "install gdb"... at which point, ENIGMA would have a full-fledged development suite at its disposal.
Also, thank you for that info page. I'll look it over and make any necessary changes.
Can you do me a favor, though? I need to modify ENIGMA.exe to make calls to MinGW's latest installer application, mingw-get. It's like apt-get, but for MinGW (Implying for Windows). Using mingw-get, I believe we can install all of GCC via calls to better_system() (already in the ENIGMA.exe source). I will get to this soon enough, but if you would like to give it a shot, be my guest. It should be as simple as calling better_system("C:\\mingw-get","install gcc"); (after actually copying mingw-get.exe to C:\MinGW, of course).
We'd then do the same for "install g++", "install make", "install gdb"... at which point, ENIGMA would have a full-fledged development suite at its disposal.
Also, thank you for that info page. I'll look it over and make any necessary changes.
1649
Proposals / Re: Decrease Code Size?
« on: October 23, 2010, 05:49:48 pm »
A five megabyte game is one megabyte too big. Until ENIGMA outputs smaller exes. Then it'll be like, 1.5 too big.
1650
Proposals / Re: Decrease Code Size?
« on: October 21, 2010, 05:22:09 pm »
Like I said, I won't personally be fucking with it. But if Ism has nothing to do one day...
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 »