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 »
241
Developing ENIGMA / Re: Accessing with types and passing by strong reference
« on: July 25, 2014, 09:45:16 pm »
Yes and no.
For things you create arbitrarily, you are right—these could be greatly benefited by classes. I would probably have it that var would not be allowed to represent these classes, except possibly through the C# approach. There's no denying how extremely useful it would be to have object-oriented file, UI, and data structure code.
Instances, you are beginning to push the limit. It is useful to be able to say, at very least for the purpose of static analysis, that other is an obj_wall, or that [snip=edl]instance_nearest(x, y, obj_missile)[/snip] is an obj_missile. But do we really want to have you check [snip=java]inst instanceOf obj_missile[/snip], then cast? I'd hear an argument either way.
Resources, you have hit the limit. There is little reason to ever have spr_some_guy be anything but an integer. Let's choose a raw, gaping sore in GML as an example: sounds. Users have always been plagued by how large their audio resources end up being in GM. In the golden days, large audio files corrupted game files left and right, and even when they did not, insane save times kicked in. Pissed-off users would eventually be driven to store their sounds externally. We just recently got bitten in the ass by Round II of this issue as it became clear that optimizing sound storage for insert instead of access was the better move. This is wrong on so many levels.
The beauty of the resource tree is that your resources are managed for you—you don't need to know anything about where, when, or how sound0 was loaded. You just play it and it works. On your side, it's an integer; you can't get any simpler an opaque pointer than that. Behind the scenes, that sound may or may not be loaded, or actually even exist. We can replace this mechanism with some sort of weak reference class, but why would we? An integer serves the purpose fine.
I wouldn't argue against the use of, eg, [snip=cpp]typedef size_t sprite_t;[/snip] to allow us to offer object-oriented features for these resources. But then, does [snip=edl]spr.exists()[/snip] really make any sense?
Just some considerations. I would be fine with a statically typed var of some sort, honestly.
For things you create arbitrarily, you are right—these could be greatly benefited by classes. I would probably have it that var would not be allowed to represent these classes, except possibly through the C# approach. There's no denying how extremely useful it would be to have object-oriented file, UI, and data structure code.
Instances, you are beginning to push the limit. It is useful to be able to say, at very least for the purpose of static analysis, that other is an obj_wall, or that [snip=edl]instance_nearest(x, y, obj_missile)[/snip] is an obj_missile. But do we really want to have you check [snip=java]inst instanceOf obj_missile[/snip], then cast? I'd hear an argument either way.
Resources, you have hit the limit. There is little reason to ever have spr_some_guy be anything but an integer. Let's choose a raw, gaping sore in GML as an example: sounds. Users have always been plagued by how large their audio resources end up being in GM. In the golden days, large audio files corrupted game files left and right, and even when they did not, insane save times kicked in. Pissed-off users would eventually be driven to store their sounds externally. We just recently got bitten in the ass by Round II of this issue as it became clear that optimizing sound storage for insert instead of access was the better move. This is wrong on so many levels.
The beauty of the resource tree is that your resources are managed for you—you don't need to know anything about where, when, or how sound0 was loaded. You just play it and it works. On your side, it's an integer; you can't get any simpler an opaque pointer than that. Behind the scenes, that sound may or may not be loaded, or actually even exist. We can replace this mechanism with some sort of weak reference class, but why would we? An integer serves the purpose fine.
I wouldn't argue against the use of, eg, [snip=cpp]typedef size_t sprite_t;[/snip] to allow us to offer object-oriented features for these resources. But then, does [snip=edl]spr.exists()[/snip] really make any sense?
Just some considerations. I would be fine with a statically typed var of some sort, honestly.
242
General ENIGMA / Re: Fun with imge_single
« on: July 25, 2014, 08:36:29 pm »
As I said, accessing the caller's image_index is already an ugly operation. When it happens, usually the access is one add+dereference (which we're replacing with two and a conditional) followed by shitloads of additional data moves or comparisons that actually work with the image data. The loss from this overhead is negligible compared to what is done with the image data. I'd probably use an inline function to handle it (as opposed to an accessor).
The code you gave works in the current system; I'm going to assume that what you meant was this:
In this case, you're right; the obvious solution is to give image_single a special accessor, but then, you're also right that I have no interest in pulling this into upstream ENIGMA.
The code you gave works in the current system; I'm going to assume that what you meant was this:
Code: (edl) [Select]
image_index = 2;
image_single = 4;
show_message(stsring(image_index)); // Prints "4"
image_single = -1;
show_message(stsring(image_index)); // Prints "2"
In this case, you're right; the obvious solution is to give image_single a special accessor, but then, you're also right that I have no interest in pulling this into upstream ENIGMA.
243
Programming Help / Re: C++ short delay when using CIN
« on: July 23, 2014, 10:13:19 pm »
Write a custom terminal emulator that, upon printing a character, deletes the entire content of the terminal by filling it with spaces, then re-prints everything, including the new character. That might get it to be as slow. Probably not worth the effort, though.
Disclaimer: Not implying that's what Windows does. I can't conceive of why the Windows command prompt is that damn slow. Especially since it takes so many disgusting shortcuts.
Disclaimer: Not implying that's what Windows does. I can't conceive of why the Windows command prompt is that damn slow. Especially since it takes so many disgusting shortcuts.
244
Developing ENIGMA / Re: Android
« on: July 23, 2014, 10:11:42 pm »
So, the point of ENIGMA's multiple makefiles is just to let systems specify the source files they include and the libraries they depend on. They operate under two assumptions:
1. You will be compiling some C++ sources into object files in order to build the C++ engine.
2. You will be linking the objects you have compiled into a standalone executable when finished.
Presently, (2) also assumes that the binary you use for linking is the same one you use for compiling. That can be changed. You can also inject additional dependencies and provide targets for them in Android-specific makefiles.
The big issue is, from what we discussed, that Android seems to compile sources into object files, but then there's some nebulous form of magic used to link those objects into a shared object to be loaded by the operating system (namely, through JNI). Unfortunately, I can't make you any recommendations until I can figure out (or someone tells me) what the hell that operation is.
1. You will be compiling some C++ sources into object files in order to build the C++ engine.
2. You will be linking the objects you have compiled into a standalone executable when finished.
Presently, (2) also assumes that the binary you use for linking is the same one you use for compiling. That can be changed. You can also inject additional dependencies and provide targets for them in Android-specific makefiles.
The big issue is, from what we discussed, that Android seems to compile sources into object files, but then there's some nebulous form of magic used to link those objects into a shared object to be loaded by the operating system (namely, through JNI). Unfortunately, I can't make you any recommendations until I can figure out (or someone tells me) what the hell that operation is.
245
Programming Help / Re: C++ short delay when using CIN
« on: July 23, 2014, 10:00:50 pm »
He's on Windows. The console is GOING to be terribly slow.
246
General ENIGMA / Re: Fun with imge_single
« on: July 23, 2014, 09:53:59 pm »
The behavior you describe is much simpler than you appear to be modeling it. It's a symptom of having two variables. Instead of using caller->image_index, and having image_single influence image_index directly, the following are happening:
Instead of [snip=edl]if (image_single != -1) image_index = image_single; else { /* image_speed logic... */ }[/snip], you would simply put [snip=edl]if (image_single == -1) { /* image_speed logic... */ }[/snip], doing nothing otherwise.
Then in place of [snip=edl]caller->image_index[/snip], you use [snip=edl]caller->image_single == -1? caller->image_index : caller->image_single[/snip].
This method is a little slower, yes, but not by enough for anyone to ever really notice. Having functions use the caller's state is dirty, anyway. I wouldn't mind pulling such a patch.
Instead of [snip=edl]if (image_single != -1) image_index = image_single; else { /* image_speed logic... */ }[/snip], you would simply put [snip=edl]if (image_single == -1) { /* image_speed logic... */ }[/snip], doing nothing otherwise.
Then in place of [snip=edl]caller->image_index[/snip], you use [snip=edl]caller->image_single == -1? caller->image_index : caller->image_single[/snip].
This method is a little slower, yes, but not by enough for anyone to ever really notice. Having functions use the caller's state is dirty, anyway. I wouldn't mind pulling such a patch.
247
General ENIGMA / Re: Indentation Styles
« on: July 20, 2014, 09:44:22 pm »
My aversion to tabs is that they have not been assigned a logical width. People individually choose how big they want their tabs. While that's great for personalization, it's bad for consistency. You can't align variables easily, or use half-indentations or double-indentations without explosion (my double is 4 spaces; some are 16). The biggest offender is when people try to line up variables after "int" or "var." It's not really my style, but it happens; exactly four spaces of indent are required to pad the next line so that all the identifiers line up. You can use spaces to do exclusively the non-indentation alignment, of course, assuming your editor lets you, but I've never seen anyone pull that off.
The lack of size agreement leads to more solid problems, in my case. GNU style seems to be two-space indent, but any leading eight spaces of indent are replaced with a single tab character. This means for me to correctly view anything GNU, I have to set my tab width to eight. My preferred tab width is two. When you send me a file and every fucking line is indented eight tabs, I flip shit. I find lately that I leave my tab widths both at two and manually replace "\t" with " " in GNU sources.
So yes, in a perfect world, everyone agrees, and we all use tabs. In this world, tabs are any multiple of 1 in size (even that's not playing it safe—some people don't use fixed-width editors, but no one cares what they think). Spaces, however, I have never noticed to be rendered as anything other than a single space of width, with or without special coloring or symbolage to denote that there's actually a character there. So I use two spaces, and my code looks the same whether it's loaded in emacs, in vim, in MS fucking Notepad, or in an actual code editor.
inb4 gr8 b8 m8
The lack of size agreement leads to more solid problems, in my case. GNU style seems to be two-space indent, but any leading eight spaces of indent are replaced with a single tab character. This means for me to correctly view anything GNU, I have to set my tab width to eight. My preferred tab width is two. When you send me a file and every fucking line is indented eight tabs, I flip shit. I find lately that I leave my tab widths both at two and manually replace "\t" with " " in GNU sources.
So yes, in a perfect world, everyone agrees, and we all use tabs. In this world, tabs are any multiple of 1 in size (even that's not playing it safe—some people don't use fixed-width editors, but no one cares what they think). Spaces, however, I have never noticed to be rendered as anything other than a single space of width, with or without special coloring or symbolage to denote that there's actually a character there. So I use two spaces, and my code looks the same whether it's loaded in emacs, in vim, in MS fucking Notepad, or in an actual code editor.
inb4 gr8 b8 m8
248
Off-Topic / Re: Religious wars in the programming community
« on: July 20, 2014, 01:14:28 pm »
This whole topic is really TL;DR; am I supposed to be doing something about it? I don't see any 72-point type, so it's looking tame enough.
249
Off-Topic / Re: On a distant future
« on: July 20, 2014, 01:12:02 pm »
I was mostly teasing. But no, I don't particularly like Facebook.
250
Off-Topic / Re: On a distant future
« on: July 19, 2014, 05:13:34 pm »
Fuck no; Facebook bought Oculus. VR is poisoned forever. AR is the new VR.
251
Works in Progress / Re: Norse Adventures planing stage
« on: July 19, 2014, 11:41:23 am »
I find the ability to draw assets for video games by hand breaks down at about the point you need small, animated sprites.
252
Issues Help Desk / Re: Issues on WinXP
« on: July 17, 2014, 10:50:47 pm »
Perhaps Oracle has managed to get the JVM to ignore segmentation faults in library code. Are your repository and copy of LateralGM both up to date?
253
Programming Help / Re: Make sprite run through a loop (like sonic)
« on: July 17, 2014, 10:36:25 pm »
If you are looking to calculate the speed you must be going, you can do that by comparing the centripetal acceleration to your gravitational constant. The centripetal acceleration is given by [snip]sqr(speed) / loop.radius[/snip]. So assuming you're using a gravity constant of one pixel per frame per frame, all you want is [snip=edl]if (sqr(speed) / loop.radius < 1) path_end(loop.path);[/snip], or whatever logic you need to stop following the loop.
You'll probably find that this calculation is too realistic for your actual game to be able to use it, (it turns out you have to be moving pretty damn fast to stay on a loop by your own force), so feel free to tone down the gravitational constant for that equation.
You'll probably find that this calculation is too realistic for your actual game to be able to use it, (it turns out you have to be moving pretty damn fast to stay on a loop by your own force), so feel free to tone down the gravitational constant for that equation.
254
Issues Help Desk / Re: Issues on WinXP
« on: July 17, 2014, 10:26:53 pm »
You get that error every time LGM starts? It sounds as though something that was supposed to be loaded was not, but you should have received a report much earlier in that case. Does the program crash? That's usually a sign that the invalid memory access was actually in the native code (ENIGMA).
255
Off-Topic / Re: Religious wars in the programming community
« on: July 17, 2014, 10:23:47 pm »
I myself am a JavaScript evangelist, and make regular sacrifices to C++. I also hold the belief that Windows users are headed for hell, and Mac users are already there.
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 »