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 189 190 191 192 193 194 195 196 197 198 199 »
1006
Programming Help / Re: Where do I find ENIGMA's API?
« on: August 01, 2014, 03:09:23 pm »Quote from: TheExDeus
ENIGMA isn't meant to be used outside ENIGMA.Yes but there is no need to limit its capabilities of doing so.
Anyway, here are some places to get started.
http://enigma-dev.org/docs/Wiki/Module_hierarchy
http://enigma-dev.org/docs/Wiki/ENIGMA:Developing
http://enigma-dev.org/docs/Wiki/Graphics_Systems/
http://enigma-dev.org/docs/Wiki/Compilers/
You really just have to use the search functionality of the Wiki, this stuff is all over the place, I haven't really had time to organize it.
1007
Proposals / Re: Flipping, scaling and rotating instances
« on: August 01, 2014, 03:02:11 pm »
You seem to be missing the entire point Harri, X and Y are passed in the constructor of objects to be made available in the actual create event, so the compiler must pass them that way as well. And yes the creation code order did change in Studio. However the results of my test my be inconclusive because Studio has a bug apparently where it is not saving my instance creation code, but this doesn't change the fact that image_angle must be set before the create event which therefore requires it to be passed in the constructor as X and Y are.
1008
General ENIGMA / Re: New functions available in the rooms editor.
« on: August 01, 2014, 03:49:27 am »Quote from: egofree
As i am not a native English speaker, i don't feel competent to do it, and anyway i was told i write 'horrible sentences' !Alright, don't worry about it then, I will correct any mistakes I see in the English translation, but also, still feel free to consult us on your translations.
Quote
I propose this : let me finish the scaling and flipping functions, and then we will increment the version and make a announcement so people will know that new features have been added in LateralGm.Try to keep a change log of everything like I usually do, and do not worry about the version number I can find time to increment that and package a new Portable ZIP. But first I would like to get all the scalling, flipping, rotation and instance locals added to the room editor since they require the back end to be updated. In fact I am going to be working on some other things like implementing the audio quality settings, which I've yet to do, with some help from Josh. This is nice to do it all at once so that users don't constantly have the plugin becoming inconsistent with the compiler.
1009
General ENIGMA / Re: New functions available in the rooms editor.
« on: August 01, 2014, 01:08:48 am »
Editor documentation belongs at the following pages.
http://enigma-dev.org/docs/Wiki/Working_with_LateralGM
Never had much time to work on the pages, do with them what you people want to do and I'll come back later and clean it up.
http://enigma-dev.org/docs/Wiki/Working_with_LateralGM
Never had much time to work on the pages, do with them what you people want to do and I'll come back later and clean it up.
1010
Issues Help Desk / Re: Now I have no instances! Only background is visible
« on: August 01, 2014, 12:04:23 am »Quote from: edsquare
I'm using the installer script to update, it in turn uses install.py so yes I'm updated on all fronts.Actually, no you are not, I have not updated the packages repository because I can't get the md5 hash right now, download the latest from the Extra Packages page manually because I believe they updated it.
http://enigma-dev.org/docs/Wiki/Install:Extra_Packages
Edit: Scratch that they did not apparently. So this is an existing regression probably in the latest version as well.
Also your error logs you keep uploading are useless, those are just pointer stacks, upload enigma-dev/output_log.txt
1011
Developing ENIGMA / Re: Font Pixel Alignment
« on: August 01, 2014, 12:00:44 am »Quote
Are you talking about the slight blurring only during movement of sprite, fonts etc ?Yes as I said this is specifically to make it both clear and allow it to interpolate properly for scrolling text. Make a scrolling background and make the x and y values round() instead of being floating point or half integer and you'll notice the scrolling is much more abrupt, it goes directly to the next pixels instead of interpolating and blending in between. You want this blurring in certain cases is what I am arguing.
Quote
With or without interpolation I have never had the problems described in your screenshots. Is this another graphic card specific issue?You've never seen because in your local copy before texture handling was made compatible with Studio I was blocking interpolation for fonts which is no longer feasible. And no this is probably directly related to the font anomalies you guys were having before, we duck tapped over it instead of fixing the underlying issue, remember?
1012
Proposals / Re: Flipping, scaling and rotating instances
« on: July 31, 2014, 11:41:34 pm »
I decided to run the tests for you.
I created a new project, 1 object and 1 sprite. I then created a room and placed the object in it.
The following code was placed in the create event.
With the instance angle set to 20, the create event reported 20.
With the instance angle set to 20 and image_angle set to 30 in the instance create code, the create event reported 20.
With the image_angle set to 30 in the instance create code, the create event reported 0.
So my initial hypothesis was correct. Just focus on adding the ability to the room editor and the properties being saved to each format. I will update the back end for you and everything after a discussion with Josh and once you get everything working and commit it.
I created a new project, 1 object and 1 sprite. I then created a room and placed the object in it.
The following code was placed in the create event.
Code: (EDL) [Select]
show_message(string(image_angle));
With the instance angle set to 20, the create event reported 20.
With the instance angle set to 20 and image_angle set to 30 in the instance create code, the create event reported 20.
With the image_angle set to 30 in the instance create code, the create event reported 0.
So my initial hypothesis was correct. Just focus on adding the ability to the room editor and the properties being saved to each format. I will update the back end for you and everything after a discussion with Josh and once you get everything working and commit it.
1013
General ENIGMA / Mipmapping Implemented
« on: July 31, 2014, 11:22:54 pm »
Well after cleaning up all of the latest texture handling to put us back on par with Studio you can now use mipmapping. You can generate mipmaps with the new texture_add or the traditional sprite_add/background_add and then set the filter using the new texture functions. You'll have to pull my changes from GitHub to start using the updated functions, I am waiting to update the ZIP so I can add it into the compiler and let you toggle mipmaps on sprites and backgrounds in LateralGM since it is anticipated that this will also be a feature of Studio. Why you ask? Because I asked Dailly a couple of times in person and he confirmed it, he just for some reason thinks it takes more effort than it really does? He literally told me it's a complex feature that takes time to test and implement on multiple platforms, but for some reason application_surface and other changes are implemented abruptly and brutally, idk, don't ask me because I am not him.
Documentation is available on the Wiki.
http://enigma-dev.org/docs/Wiki/Texture_Functions
The functions work the same for all graphics systems and utilizing mipmapping on high resolution textures should improve your games performance dramatically, for instance my terrain demo goes from 100fps to around 500 as you can see in the screenshot.
The updated version that is watered down for the sake of showing off mipmapping is available for download.
Download: https://www.dropbox.com/s/ls34n8lrb81bbi5/texturefiltering.zip
Size: 1.22mb's
Documentation is available on the Wiki.
http://enigma-dev.org/docs/Wiki/Texture_Functions
The functions work the same for all graphics systems and utilizing mipmapping on high resolution textures should improve your games performance dramatically, for instance my terrain demo goes from 100fps to around 500 as you can see in the screenshot.
The updated version that is watered down for the sake of showing off mipmapping is available for download.
Download: https://www.dropbox.com/s/ls34n8lrb81bbi5/texturefiltering.zip
Size: 1.22mb's
1014
Proposals / Re: Close file without closing LGM/ENIGMA
« on: July 31, 2014, 11:17:40 pm »
Now I understand, I had thought about it before, and I have ideas, but sadly don't have time to work on them.
1015
Programming Help / Re: Creating a HtmlView control on Linux
« on: July 31, 2014, 11:16:10 pm »
Write a widget system extension and you can use whatever widgets you want.
1016
Programming Help / Re: Creating a HtmlView control on Linux
« on: July 31, 2014, 09:53:18 pm »
You could also use wxWidgets, Qt Framework (which is webkit based I think), or possibly some GTK project. Java/Swing is also an option but don't expect it to render too much advanced HTML or HTML5 for that matter.
1017
Developing ENIGMA / Font Pixel Alignment
« on: July 31, 2014, 09:27:02 pm »
Ok so I need to describe a fault in our text drawing functions in detail. Some of you may have noticed the interpolation distorts your fonts, but not in the way you would expect. Examine the following.
Note: It really helps to open these images in Paint or another program with no filtering and zoom down to examine the pixels.
In this first image we see what happens when we draw the text at full integer coordinates with interpolation enabled. Notice interpolation does not effect most of the characters and most have crisp edges, as if interpolation is not even enabled.
In this second image we see what happens when we draw the text at half integer coordinates with interpolation. Notice interpolation is mostly working on most of the characters but a few have crisp edges.
Note: This is the behavior observed in Direct3D9 as well, except the behavior appears to be reversed appearing interpolated with full integer coordinates and not with half integer coordinates.
This is not something which can be fixed purely by disabling interpolation or padding the font textures though they still need to be anyway. This could have also been the cause of other font anomalies for some of you at an earlier time. I have also confirmed this issue to be the result of characters rendering at different locations between OGL and D3D if we round and draw at full integer coordinates the characters appear at the exact same location in all graphics systems. The problem exists in our text rendering functions, they either all need to be at full integer coordinates or all at half. Generally they should always be at half integer coordinates with vector graphics, like half pixel alignment in Inkscape.
However, when scrolling backgrounds or text it helps to allow them to transition between half and full pixel integer coordinates to make them blend smoothly. My proposal is simple, we merely need to align all the characters of a draw_text call to either full or half integer coordinates and no in-between, this is something we can all mutually agree on. Now me and Josh disagree however about when extra spacing should be applied, Josh believes it should be every 3rd or 4th character where as I believe the excess spacing should be applied immediately after it reaches a whole number.
It basically has to do with how we handle xx as you can examine on the following line.
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/General/GSfont.cpp#L374
With the following modification to the drawn text function, the text and all characters are drawn at full integer coordinates and properly and evenly spaced between all graphics systems at the exact same coordinates with or without interpolation enabled.
These are the results with the above changes. The following is drawn starting at full pixel passed to the draw text function and interpolation enabled, this is actually what it should look like with interpolation enabled when the font texture is not padded.
The following is drawn starting at half pixels passed to the draw text function with interpolation enabled, this is how GM avoids interpolation on font textures, it always draws at full integer coordinates like most game engines.
Now as I said GM and most game engines always render fonts at full integer coordinates, but this can cause them to be blocky when you want scrolling text, it makes the transition much more abrupt, you want this blurring that is caused by half integer coordinates when drawing 2D objects, sprites, backgrounds, and text. Therefore, I believe I will temporarily prepare a pull request to be merged immediately that draws our text at full integer coordinates like everyone else until we can come up with an alternative or decide on a solution.
It would help if everyone including Josh could weigh in and offer their opinions.
Note: It really helps to open these images in Paint or another program with no filtering and zoom down to examine the pixels.
In this first image we see what happens when we draw the text at full integer coordinates with interpolation enabled. Notice interpolation does not effect most of the characters and most have crisp edges, as if interpolation is not even enabled.
In this second image we see what happens when we draw the text at half integer coordinates with interpolation. Notice interpolation is mostly working on most of the characters but a few have crisp edges.
Note: This is the behavior observed in Direct3D9 as well, except the behavior appears to be reversed appearing interpolated with full integer coordinates and not with half integer coordinates.
This is not something which can be fixed purely by disabling interpolation or padding the font textures though they still need to be anyway. This could have also been the cause of other font anomalies for some of you at an earlier time. I have also confirmed this issue to be the result of characters rendering at different locations between OGL and D3D if we round and draw at full integer coordinates the characters appear at the exact same location in all graphics systems. The problem exists in our text rendering functions, they either all need to be at full integer coordinates or all at half. Generally they should always be at half integer coordinates with vector graphics, like half pixel alignment in Inkscape.
However, when scrolling backgrounds or text it helps to allow them to transition between half and full pixel integer coordinates to make them blend smoothly. My proposal is simple, we merely need to align all the characters of a draw_text call to either full or half integer coordinates and no in-between, this is something we can all mutually agree on. Now me and Josh disagree however about when extra spacing should be applied, Josh believes it should be every 3rd or 4th character where as I believe the excess spacing should be applied immediately after it reaches a whole number.
It basically has to do with how we handle xx as you can examine on the following line.
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/General/GSfont.cpp#L374
With the following modification to the drawn text function, the text and all characters are drawn at full integer coordinates and properly and evenly spaced between all graphics systems at the exact same coordinates with or without interpolation enabled.
Code: (cpp) [Select]
unsigned xxx = xx;
draw_vertex_texture(x + xxx + g->x, yy + g->y, g->tx, g->ty);
draw_vertex_texture(x + xxx + g->x2, yy + g->y, g->tx2, g->ty);
draw_vertex_texture(x + xxx + g->x, yy + g->y2, g->tx, g->ty2);
draw_vertex_texture(x + xxx + g->x2, yy + g->y2, g->tx2, g->ty2);
draw_primitive_end();
These are the results with the above changes. The following is drawn starting at full pixel passed to the draw text function and interpolation enabled, this is actually what it should look like with interpolation enabled when the font texture is not padded.
The following is drawn starting at half pixels passed to the draw text function with interpolation enabled, this is how GM avoids interpolation on font textures, it always draws at full integer coordinates like most game engines.
Now as I said GM and most game engines always render fonts at full integer coordinates, but this can cause them to be blocky when you want scrolling text, it makes the transition much more abrupt, you want this blurring that is caused by half integer coordinates when drawing 2D objects, sprites, backgrounds, and text. Therefore, I believe I will temporarily prepare a pull request to be merged immediately that draws our text at full integer coordinates like everyone else until we can come up with an alternative or decide on a solution.
It would help if everyone including Josh could weigh in and offer their opinions.
1018
Proposals / Re: Close file without closing LGM/ENIGMA
« on: July 31, 2014, 05:22:29 pm »
Why not just hit the new file button...?
1019
Proposals / Re: Flipping, scaling and rotating instances
« on: July 31, 2014, 05:18:53 pm »Quote
TheExDeus said it would be possible to do this in the creation code of the instanceDo not do it that way, if you want I can add them to the compiler and everything. They need to be in there so I can update the command line interface to accept them as well as. Josh should weigh in.
Quote
So unless someone has an argument why my idea wouldn't work, then I think it's the most practical.Because nobody has tested Studio to see at what point those locals are set, what if they are accessible in the create event? Then having them in instance creation certainly won't work because they won't be available, same as X, Y which are available in the create event. I'd prefer this be tested first to ensure.
If it is necessary I can update the back end and everything for him, he'll only have to change LGM.
1020
Off-Topic / Re: MacOS Counter-intuitive?
« on: July 31, 2014, 05:15:07 pm »Quote from: Rusky
But for many people (IT departments, people without the time to learn how to build a PC, experts in other fields that need to do their real jobs, etc) that's not an option, so they pay for having it put together. That applies whether you get a Mac or not, and when you compare a pre-built Mac to a pre-built PC with the same specs, you'll get the same price. When you compare custom-built PC to pre-built Mac with the same specs you'll still get pretty close. In my experience a lot of the savings of building your own PC is from being able to build exactly what you want rather than having to overshoot.
This I actually agree with. Anyway, most of my complaints are about how shitty the design is, I am not arguing customizability or anything, which I still find a valid argument though. Xcode is shit too, I really hate Xcode for reasons Josh pointed out.
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 189 190 191 192 193 194 195 196 197 198 199 »