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 »
1681
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: May 12, 2011, 05:58:07 am »
Yeah, but I need the highest offset from the baseline. I will illustrate:
Here is the code:
edit: Also on the side note. Which file is used: GAME_GLOBALS.h or key_game_globals.h? Or both? Or none? Because when I include GAME_GLOBALS.h it shows that "string does not name a type" which makes me think that it is not actually included anywhere (and my search didn't return anything either). key_game_globals.h is included in roomsystem.cpp but it even has this besides it:
"//TODO: Remove all instances of this line. It's just sloppy. Figure out the dependencies manually.". So how exactly I add globals? I want to make keyboard_string (or at least very limited version). The basics is just adding this line:
Here is the code:
Code: [Select]
str="This is text. p and q";
draw_set_font(font_0);
draw_text(10,10,str);
draw_circle_color(10,10,2,c_red,c_red,0);
draw_line(10,10+string_height(str),10+string_width(str),10+string_height(str));
I added explanation in paint.net. So I need to get the highest y2 value to subtract from the baseline. The red dot is the drawing origin position.edit: Also on the side note. Which file is used: GAME_GLOBALS.h or key_game_globals.h? Or both? Or none? Because when I include GAME_GLOBALS.h it shows that "string does not name a type" which makes me think that it is not actually included anywhere (and my search didn't return anything either). key_game_globals.h is included in roomsystem.cpp but it even has this besides it:
"//TODO: Remove all instances of this line. It's just sloppy. Figure out the dependencies manually.". So how exactly I add globals? I want to make keyboard_string (or at least very limited version). The basics is just adding this line:
Code: [Select]
if (last_keybdstatus[i] != keybdstatus[i]) keyboard_string+=chr(i);
To void input_push() functions "for" cycle inside WINDOWScallback.cpp. You can clearly see lots of problems (like adding every button on the keyboard to a string), but what I need is just basics for a little test so I don't mind about this.
1682
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: May 11, 2011, 03:22:00 pm »Code: [Select]
int botoff = (fnt->glyphs[(unsigned char)(103 - fnt->glyphstart) % fnt->glyphcount]).y2
xx = x, yy = y+fnt->height-botoff;
The question now remains do I change all the functions to accommodate this, or we add a new variable to the font struct. Like fnt->yoffset which has the needed value? Post here (or in the wiki, or somewhere else where I can read it) to tell me how this should be done.
1683
Proposals / Re: EGM format: Allow resources in other folders?
« on: May 02, 2011, 09:27:32 am »
I voted for Forced Segregation, but I would actually want to see something in between. Maybe allowing users to create their own types where they could add whatever they like. Or make this optional, so newbies wouldn't mess something up. Like allowing this only in Advanced mode (like GM's).
The reason why I don't want this is because objects don't really fit into sprites folder, while sprites do, in theory, fit in objects folder (as objects define the sprite, not the other way around).
Anyway, I probably just wouldn't use this, but it could come in handy for others.
The reason why I don't want this is because objects don't really fit into sprites folder, while sprites do, in theory, fit in objects folder (as objects define the sprite, not the other way around).
Anyway, I probably just wouldn't use this, but it could come in handy for others.
1684
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: April 29, 2011, 04:24:43 pm »
Ok, so I updated all the functions. They all work correctly as far as I have tested them. They are not so pretty thou, as fixing the positioning required some additional math to be added. I did try to precompute everything as much as possible, but some things are still character based. If anyone has any optimizations in mind then please share. The .cpp and .h is at the first page. I have two comparison pictures here:
http://img854.imageshack.us/i/textinenigma.png/
http://img852.imageshack.us/i/textingamemaker80.png/
One is in GM and the other in ENIGMA. Also side by side picture here:
http://img26.imageshack.us/i/textcompare.jpg/
As you can see there isn't much of a change. Its better if you can overlay one on the other, but it is possible to see slight size and color differences. I think colors are interpolated more properly in ENIGMA thou as in GM you can't actually get a black corner when a color is set to black. The biggest difference is in draw_text_ext_transformed as in GM it splits into 4 lines while in ENIGMA it splits into 3. Don't know why GM does that, as it clearly isn't out of bounds. If I increase the width to 301 instead of 300, then GM doesn't split. So its probably some rounding bug.
Also, in Enigma screen you can see arrows pointing in the draw_text_ext_color example. This is done to show off some new functions I added. In GM doing that would be quite a pain, but now in Enigma you can draw them just with this simple code:
The full source can be downloaded from the attachment bellow.
If no one finds any bugs or does some optimization then I think this could be committed. I will do this myself if no one else will. I will also write wiki entry just like I did for curves and shapes.
http://img854.imageshack.us/i/textinenigma.png/
http://img852.imageshack.us/i/textingamemaker80.png/
One is in GM and the other in ENIGMA. Also side by side picture here:
http://img26.imageshack.us/i/textcompare.jpg/
As you can see there isn't much of a change. Its better if you can overlay one on the other, but it is possible to see slight size and color differences. I think colors are interpolated more properly in ENIGMA thou as in GM you can't actually get a black corner when a color is set to black. The biggest difference is in draw_text_ext_transformed as in GM it splits into 4 lines while in ENIGMA it splits into 3. Don't know why GM does that, as it clearly isn't out of bounds. If I increase the width to 301 instead of 300, then GM doesn't split. So its probably some rounding bug.
Also, in Enigma screen you can see arrows pointing in the draw_text_ext_color example. This is done to show off some new functions I added. In GM doing that would be quite a pain, but now in Enigma you can draw them just with this simple code:
Code: [Select]
for (int i=0; i<string_width_ext_line_count(str,w); i+=1){
twi = string_width_ext_line(str, w, i);
draw_arrow(430+w, 75+string_height("M")*(i+0.5),430+twi, 75+string_height("M")*(i+0.5), 10, 3, 1);
}
So basically you can get width of a specific line inside a multiline string.The full source can be downloaded from the attachment bellow.
If no one finds any bugs or does some optimization then I think this could be committed. I will do this myself if no one else will. I will also write wiki entry just like I did for curves and shapes.
1685
Off-Topic / Re: Introductions
« on: April 28, 2011, 02:32:24 pm »
Hi Jbolte. I think there was a special forum for this before, but I think its deleted now.
Anyway, I am glad (and others are too I suppose) that there is one more person interested in development. If you have any programming experience then you probably could end up helping. For example, I use C++ very rarely and actually only when I am helping here. Still, I am able to create functions and share with them. You could maybe also write something in the wiki. I usually document the functions I make myself, but there probably are things you can add.
Anyway, I am glad (and others are too I suppose) that there is one more person interested in development. If you have any programming experience then you probably could end up helping. For example, I use C++ very rarely and actually only when I am helping here. Still, I am able to create functions and share with them. You could maybe also write something in the wiki. I usually document the functions I make myself, but there probably are things you can add.
1686
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: April 24, 2011, 11:29:07 am »
That would be just a linear interpolation. In GM every line is colored separately, and so linear interpolation shouldn't be hard. Especially when that is needed only horizontally, as vertical interpolation is not needed (just color top and bottom vertexes separately).
edit: That _ext function seems more like a pain in ass. If everybody agrees that my code is ok and +- optimized then I will stop thinking about it.
edit: That _ext function seems more like a pain in ass. If everybody agrees that my code is ok and +- optimized then I will stop thinking about it.
1687
Function Peer Review / Re: GML: All draw_text functions +(string_width, _height, _width_ext, _height_ext)
« on: April 24, 2011, 08:37:04 am »
As Enigma finally supports fonts, then this topic could get a new life. All of the functions worked, but that was with the sprite fonts and they also didn't follow some rules.
1. The origin of the text wasn't at the top left, but the bottom left. I fixed that by doing this: yy = y+fnt->height. It looks almost exactly like the GM's, but this makes it draw a few pixels lower than GM. Dunno how GM does it then.
2. _ext functions cut the text when it was already out of the boundary defined by "width" argument. The only way I thought I could fix this is by doing a loop inside a loop, which is quite painful. This is the code:
Anyway, I am still reworking the rest of the functions and in time, this could be committed.
1. The origin of the text wasn't at the top left, but the bottom left. I fixed that by doing this: yy = y+fnt->height. It looks almost exactly like the GM's, but this makes it draw a few pixels lower than GM. Dunno how GM does it then.
2. _ext functions cut the text when it was already out of the boundary defined by "width" argument. The only way I thought I could fix this is by doing a loop inside a loop, which is quite painful. This is the code:
Code: [Select]
//The following is certainly not pretty, but this is the best way I thought of to replicate GM's function
void draw_text_ext(int x,int y,string str, int sep, int w)
{
font *fnt = fontstructarray[currentfont];
if (bound_texture != fnt->texture)
glBindTexture(GL_TEXTURE_2D, bound_texture = fnt->texture);
int xx = x, yy = y+fnt->height, width = 0, tw = 0;
glBegin(GL_QUADS);
for (unsigned i = 0; i < str.length(); i++)
{
if (str[i] == '\r')
xx = x, yy += (sep+2 ? fnt->height : sep), i += str[i+1] == '\n';
else if (str[i] == '\n')
xx = x, yy += (sep+2 ? fnt->height : sep);
else if (str[i] == ' ')
xx += fnt->height/3, width = xx-x;
tw = 0;
for (unsigned c = i+1; c < str.length(); c++) //This is getting messy
{
if (str[c] == ' ')
break;
fontglyph &g = fnt->glyphs[(unsigned char)(str[c] - fnt->glyphstart) % fnt->glyphcount];
tw += g.xs;
}
if (width+tw >= w && w != -1)
xx = x, yy += (sep==-1 ? fnt->height : sep), width = 0, tw = 0;
else
{
fontglyph &g = fnt->glyphs[(unsigned char)(str[i] - fnt->glyphstart) % fnt->glyphcount];
glTexCoord2f(g.tx, g.ty);
glVertex2i(xx + g.x, yy + g.y);
glTexCoord2f(g.tx2, g.ty);
glVertex2i(xx + g.x2, yy + g.y);
glTexCoord2f(g.tx2, g.ty2);
glVertex2i(xx + g.x2, yy + g.y2);
glTexCoord2f(g.tx, g.ty2);
glVertex2i(xx + g.x, yy + g.y2);
xx += g.xs;
width = xx-x;
}
}
glEnd();
}
Question is if anyone can think of a better way. This works exactly like GM's, but this cuts words in the middle if the "width" is too small. I don't actually see why it does that, as cutting should occur only in spaces.Anyway, I am still reworking the rest of the functions and in time, this could be committed.
1688
Proposals / Re: ENIGMA Project Icons
« on: April 23, 2011, 11:57:14 am »
It would also kick arse if compiled Enigma projects used icons as well. Maybe change the default LGM icon into the Enigma logo.. and make the exe's actually show it.
1689
Announcements / Re: Quick Update
« on: April 19, 2011, 01:19:30 pm »Quote
You may want to use double for trig-based ones, though the regular draw_text uses integers... Depending on how it looks, I may need to go back and write the metrics as float instead of int.Well, but then we have the same problem as before that this doesn't work:
Code: [Select]
draw_text(mouse_x,mouse_y,"This is some text")
I think it should, but if we use int as position parameters then it won't. Thou maybe its more of a problem with the mouse_x/mouse_y variables than draw_text.
1690
Announcements / Re: Quick Update
« on: April 19, 2011, 10:37:01 am »Quote
And you moved in the new ENIGMA.exe from CompilerSource?Yes I did. Anyway, the template is just how it should be. I will work on the text functions. But what about the position variable type? Do we use double everywhere or what?
1691
Announcements / Re: Quick Update
« on: April 19, 2011, 08:11:33 am »
I don't think it generates the right ey as it doesn't know where to write the resources on windows. I updated everything, deleted both the dll and ey and everything was recompiled and regenerated. Now when I run a project it shows this:
When I add "resources: $exe" manually then it compiles, but it outputs a .tmp file which he can't run. When I rename it to .exe or add this to ey:
All in all, great to see fonts finally implemented.
I did notice that I can't draw text at mouse position, because mouse position is a double and the text position is an int. When I cast it to int then it works, but we should make it work just like in GM so newbies wouldn't get confused. One way to do that is to standardize position variable types. For example, if we all agree that all positions could be and should be double, then we should change every draw function's position arguments into a double. Because now text drawing has an int, curve drawing has a float, draw_vertex is a double, but draw_vertex_color is a float etc. We should standardize that. Maybe create some standard rules in the wiki so it would be easier to follow.
Also, did you look at the ticket I posted about dll's? I did use ExtremePhysics.dll if that makes any difference. It is open source so it would be cool to make it as a native extension to Enigma, but I just wanted to compare speeds (also between accessing dlls).
I also see that only the regular draw_text is implemented. This could be committed as well, but they need some modification. I will probably commit it myself if I still have the privilege to do so. They also line the text up to the top not the bottom as they should, and x and y argument takes the bottom left corner instead of top. So now when I have a proper font support I can finally fix all this.
Quote
+++++Make completed successfully.++++++++++++++++++++++++++++++++++++So it has an empty path.
Failed to write resources to compiler-specified file, ``. Write permissions to valid path?
Built to C:/Users/Daedalus/AppData/Local/Temp/egm6573447818029041735.tmp
When I add "resources: $exe" manually then it compiles, but it outputs a .tmp file which he can't run. When I rename it to .exe or add this to ey:
Quote
Build-Extension:Then everything works. So a little change is needed to the generated windows ey.
Run-output: [Temp files]
Run-Program: $game
Run-Params:
All in all, great to see fonts finally implemented.
I did notice that I can't draw text at mouse position, because mouse position is a double and the text position is an int. When I cast it to int then it works, but we should make it work just like in GM so newbies wouldn't get confused. One way to do that is to standardize position variable types. For example, if we all agree that all positions could be and should be double, then we should change every draw function's position arguments into a double. Because now text drawing has an int, curve drawing has a float, draw_vertex is a double, but draw_vertex_color is a float etc. We should standardize that. Maybe create some standard rules in the wiki so it would be easier to follow.
Also, did you look at the ticket I posted about dll's? I did use ExtremePhysics.dll if that makes any difference. It is open source so it would be cool to make it as a native extension to Enigma, but I just wanted to compare speeds (also between accessing dlls).
I also see that only the regular draw_text is implemented. This could be committed as well, but they need some modification. I will probably commit it myself if I still have the privilege to do so. They also line the text up to the top not the bottom as they should, and x and y argument takes the bottom left corner instead of top. So now when I have a proper font support I can finally fix all this.
1692
Announcements / Re: Recent Events
« on: April 12, 2011, 05:37:31 pm »Quote
Thanks for fixing the vsynch issueHe has?
1693
Proposals / Re: Forums - Users country info
« on: April 10, 2011, 11:04:41 am »Quote
I know this can sounds very silly.... but would be interesting if inside the posts, in the user information also shows the user's country. So we can have an idea that where in the world people are contributing.Doubt there is that much of a point. We can guess thou.. Josh is from USA (his last name is Ventura, how cool is that). Ism is from Russia.. yes.. the cold world of vodka. I am from Latvia. Others are from hell (just guessing).
For example... I am from Brazil.
=)
P.s. I am not sure where Ism and Josh is from, I am just guessing or recalling something about something.
1695
Issues Help Desk / Re: Function pointers
« on: March 28, 2011, 02:42:44 pm »Quote
Currently, ENIGMA defines scripts as the actual functions inside each object scope. To correct this, the compiler must export the following:Then why doesn't it? If this works and surfaces are implemented (I know, you are probably sick of people asking for surfaces) then I could actually run the program in Enigma. I would develop the rest of the missing functions myself.
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 »