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 »
211
Developing ENIGMA / Re: Font Pixel Alignment
« on: August 03, 2014, 04:43:46 pm »
No; believe it or not, that was for srs. I used to get complaints about that when I'd leave coordinates as integers, because graphics would hop around as if snapped to a grid (namely, integers ).
212
Programming Help / Re: image_angle & view_angle : problem !
« on: August 03, 2014, 04:41:52 pm »
Thanks, Harri.
213
Developing ENIGMA / Re: Font Pixel Alignment
« on: August 03, 2014, 11:43:55 am »
...Interpolation occurs when scaling or when drawing across pixel boundaries. If you aren't scaling the text, then the only reason you will have "blurred" fonts is if you are not keeping the vertices on half-pixel bounds.
For our purpose, the projection should always be offset by a half pixel in either direction.
And at this point, I think that all the problems we've had in the past with projection have been less to do with people's cards not working and more to do that no one could ever stop fucking panicking and changing stupid shit long enough to just see if something was working. Has there ever been a point in any of ENIGMA's history wherein we had half-pixel projection offsets, and were making sure to draw font glyphs on whole-integer bounds? I seriously fucking doubt it, at this point.
if you're going to ask "what about the people who want <x>," you should start considering the people who want a 128×96 views blown up to 480p or 600p.
For our purpose, the projection should always be offset by a half pixel in either direction.
And at this point, I think that all the problems we've had in the past with projection have been less to do with people's cards not working and more to do that no one could ever stop fucking panicking and changing stupid shit long enough to just see if something was working. Has there ever been a point in any of ENIGMA's history wherein we had half-pixel projection offsets, and were making sure to draw font glyphs on whole-integer bounds? I seriously fucking doubt it, at this point.
if you're going to ask "what about the people who want <x>," you should start considering the people who want a 128×96 views blown up to 480p or 600p.
214
Proposals / Re: Modifying the way we select objects
« on: August 03, 2014, 11:36:08 am »
I'd make that when you double-click it in the list; could be annoying, otherwise (side-by-side instances can be far apart in the room, and you're more likely to care while editing instances).
215
Proposals / Re: Threading
« on: August 03, 2014, 11:25:12 am »
Worry about them all you like. I doubt you would have much luck implementing either of those right now.
216
Programming Help / Re: image_angle & view_angle : problem !
« on: August 03, 2014, 10:55:21 am »
Robert, the room view code uses d3d_set_projection_ortho itself. The skewing is a function of the aspect ratio. If the room were, say, 560×560 instead of 640×480, there wouldn't be a problem with the aspect. We could ostensibly fix this by applying the rotation to the projection width and height, but that shouldn't be necessary. If I had to guess, this is solved by applying the rotation after the scaling and before the translation when creating the matrix. Right now it seems to be specified first of all, so it's not surprising we're getting skewing issues. I'll need to sit down and think about it to get the right order for the transformations. My intuitive best guess did not cut it.
217
Proposals / Re: Threading
« on: August 02, 2014, 08:05:11 pm »
I don't like the idea of a new syntax for threads. The new parser supports anonymous functions. If it doesn't, it will briefly.
Basically, leave the syntax modifications to supporting dynamic functions in general. A thread_start, thread_join, and thread_signal will follow from there.
Code: (edl) [Select]
function my_thread() {
for (int i = 0; i < 10; ++i) {
show_message("Thread Running");
sleep(1000);
}
show_message("Thread Done");
}
var thread = thread_function(my_thread);
Basically, leave the syntax modifications to supporting dynamic functions in general. A thread_start, thread_join, and thread_signal will follow from there.
218
Developing ENIGMA / Re: Font Pixel Alignment
« on: August 02, 2014, 10:55:38 am »
The text is faint where pixels from a 1px-wide vertical portion are drawn horizontally across two pixels, and likewise where pixels from 1px-thick horizontal portion are drawn across two pixels vertically. This happens when the pixels are not contained in integer bounds—i.e, when the center of the pixel is drawn anywhere but a half-pixel boundary. From what I'm seeing, this happens every other glyph, meaning that at some point, they *are* aligned, and at some point, they aren't. Considering it alternates, the only logical conclusion is that someone is adding floating point numbers to the font spacing accumulator, which I told Robert would require rounding before drawing at those coordinates. It seems he's figured that much out.
Setting the projection to half-pixel coordinates should be the default behavior for draw_/d3d_set_projection_ortho. This isn't just for fonts; it's for every single sprite-based resource. With interpolated lines, it'll also be clear really quick that the projection is not half-pixel aligned.
Again, fonts should be drawn at whole-integer bounds. The projection should be set with a half-integer shift. That's just how 2D game projections work.
Setting the projection to half-pixel coordinates should be the default behavior for draw_/d3d_set_projection_ortho. This isn't just for fonts; it's for every single sprite-based resource. With interpolated lines, it'll also be clear really quick that the projection is not half-pixel aligned.
Again, fonts should be drawn at whole-integer bounds. The projection should be set with a half-integer shift. That's just how 2D game projections work.
219
Issues Help Desk / Re: Now I have no instances! Only background is visible
« on: August 02, 2014, 10:46:35 am »
Hm. It's possible there's some default code in events.res that is creating problems. I might ask Sorlok; he's the one who implemented timelines for us, so he'll recognize that code.
Could you tell me what happens if you disable the Timelines extension? If it's disabled, enable it, and the problem should go away.
Could you tell me what happens if you disable the Timelines extension? If it's disabled, enable it, and the problem should go away.
220
Programming Help / Re: image_angle & view_angle : problem !
« on: August 02, 2014, 10:44:56 am »
It seems ENIGMA is mishandling the view_angle transformation. I'm merging something in from Robert now, and I have a small laundry list of other things to check in with it. I'll see if I can't reproduce your problem and fix it.
221
Proposals / Re: Flipping, scaling and rotating instances
« on: August 02, 2014, 10:35:45 am »
That is exactly what I was going to have him do, Harri. There's no point in adding arbitrary numbers of variables to our list format when 99% of objects won't use all of them, and more than half of objects won't use any of them. Just prefix it to the creation code. This allows injecting arbitrary variable assignments. Plus, the code is executed inside the frame of the instance in question. There's no reason not to do it this way.
222
Programming Help / Re: image_angle & view_angle : problem !
« on: August 02, 2014, 10:18:41 am »
The grid you are seeing is caused by gaps in the tiled background. The graphics card should not be doing that; those polygons share coordinates, so even if the pixels didn't belong to one tile, they should belong to the next...
The skewing you see instead of rotation, however, is entirely our fault. I'll look into why that's happening.
Does the third screenshot show us what happens in GM8 when you press left? I.e, does the sprite rotate to remain upright while the world rotates around it?
The skewing you see instead of rotation, however, is entirely our fault. I'll look into why that's happening.
Does the third screenshot show us what happens in GM8 when you press left? I.e, does the sprite rotate to remain upright while the world rotates around it?
223
Off-Topic / Re: NakedPaulToast
« on: August 02, 2014, 09:46:07 am »
I hope you'll point out if I ever do that.
224
Developing ENIGMA / Re: Font Pixel Alignment
« on: August 01, 2014, 07:02:48 am »
No. The purpose of padding is to prevent noise around glyph bounding rectangle edges from nearby glyphs being interpolated across those boundaries. This is due to the fact that every time someone tries to half-pixel align ENIGMA's orthographic projections, as they should be, there's a 16-week debate about how this actually makes some cards rendering worse. Of course, in this case, it doesn't seem to matter. Every other glyph is drawn correctly, which means to me that someone is adding half-pixels to the font coordinates and not rounding them before drawing.
225
Proposals / Re: Close file without closing LGM/ENIGMA
« on: August 01, 2014, 06:58:38 am »
If a second project opens in LateralGM without closing the first, that's a bug. A bad bug. If you hit save, you WILL save the contents of both games to the newly opened project if that really happened. And you will have duplicate IDs, and your game will be very hard to salvage.
The new button is the only way we have of "closing" a project, because it does not support loading two projects. Are you able to get it to load one project over another? Could you screencap it and/or file a bug?
The new button is the only way we have of "closing" a project, because it does not support loading two projects. Are you able to get it to load one project over another? Could you screencap it and/or file a bug?
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 »