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 »
271
Developing ENIGMA / EnigmaFileFunctions repo
« on: July 05, 2014, 02:07:37 pm »
I realize that Robert has been trying to implement a CLI, but this has been on my plate for a while. In fact, when I heard of his intentions, I published a repository I'd started to GitHub for reading files and general file processing groundwork. This includes a UTF8 implementation of std::string (still in progress) and a class for iterating files. Right now, the file iteration class supports zip iteration and filesystem iteration, but it has only been implemented on Linux. The zip iteration should work directly on Windows, provided someone can install libzip in MinGW. Today I coded what should resemble the Windows implementation. I have left it commented since it is not tested.
I meant this procedure to be for Robert, but he seemed generally uninterested in the prospect. I would appreciate it if a Windows developer would do the following:
All tests currently pass on Linux. If any tests other than the directory test you're working on/looking at fail on Windows, please let me know.
I meant this procedure to be for Robert, but he seemed generally uninterested in the prospect. I would appreciate it if a Windows developer would do the following:
- Check out the EnigmaFileFunctions repository
- Open gdir.cpp and seek to the unimplemented functions.
- Uncomment my implementation and fix any issues, or write your own implementation. Just get it to build.
- Run the tests I wrote.
- In Code::Blocks, this is as simple as switching to the "Test" target and running
- If you have GNU make, you can run [snip]make test[/snip] to test
- If the tests don't pass, tweak the code and rerun them.
- Once all tests pass, drop me a pull request.
All tests currently pass on Linux. If any tests other than the directory test you're working on/looking at fail on Windows, please let me know.
272
Issues Help Desk / Re: Enigma's Project and Github
« on: July 05, 2014, 08:43:59 am »
EGM is supposed to support a non-archive mode for version control. You shouldn't have to zip up your git repo. If LGM can't open directories as an EGM, this is probably a simple fix.
273
Tips, Tutorials, Examples / Re: Multitextured Terrain Example
« on: July 04, 2014, 07:43:51 pm »
That's actually looking beautiful, Harri. Sand's a little bright; maybe give it a little more saturation or less value, or perhaps a better transition to the grass is in order. Hard to say.
274
Programming Help / Re: OGL Texture interpolation and transparent textures
« on: July 04, 2014, 09:53:39 am »
Drawing the fence last is really your best course of action. Enabling zwrite for it won't really be an issue, then. Frequently, people queue up semitransparent polygons for draw last, and then sort by distance from camera. That's pretty costly, but fortunately, I don't suspect you'll have a lot of transparent objects that overlap.
Let me add: that function is underpowered. And I remember using it in GM6, Robert, so if it was missing from Studio, it was probably accidentally elided. It was underpowered, then, too. You need to be able to set the z-buffer write and read operators. You should be able to say, "write to the z buffer when depth is less [or equal]", or "read from the z buffer and draw when greater [or equal]", which would cause objects to only be drawn when there's a face occluding them. This is useful for when you want to draw a shadow of a player when that player is behind a rock. Instead, our fearless leader only lets you enable or disable a less-than test on z-write.
Let me add: that function is underpowered. And I remember using it in GM6, Robert, so if it was missing from Studio, it was probably accidentally elided. It was underpowered, then, too. You need to be able to set the z-buffer write and read operators. You should be able to say, "write to the z buffer when depth is less [or equal]", or "read from the z buffer and draw when greater [or equal]", which would cause objects to only be drawn when there's a face occluding them. This is useful for when you want to draw a shadow of a player when that player is behind a rock. Instead, our fearless leader only lets you enable or disable a less-than test on z-write.
275
General ENIGMA / Re: Cross-platform filename mangling
« on: July 03, 2014, 06:55:47 pm »
I'm inclined to disagree. The most I'd be willing to do is offer a regex-like pass over the codebase for path-like strings. Such a pass is already required for things like [snip=edl]for (i = 0; i < 10; i += 1;)[/snip].
I really do not want to incorporate a mechanism to pass over paths for backslashes. Certainly not by default, probably not at all. In addition to the additional efficiency reasons, files on Linux can have backslashes in the name. While I don't personally value this, someone might. The operating system is the only entity that should be parsing paths.
That said, if your solution was simply to make paths a different type, I am generally in favor of adding more metadata to functions. So [snip=cpp]typedef std::string path_t;[/snip] is fine with me. At that point, I won't bitch about an optional class extending string whose constructor parses for backslashes. It's technically even legal to just do this alternative typedef in the user code without recompiling the code. I'm not sure if the behavior is defined, but it will work, anyway.
I really do not want to incorporate a mechanism to pass over paths for backslashes. Certainly not by default, probably not at all. In addition to the additional efficiency reasons, files on Linux can have backslashes in the name. While I don't personally value this, someone might. The operating system is the only entity that should be parsing paths.
That said, if your solution was simply to make paths a different type, I am generally in favor of adding more metadata to functions. So [snip=cpp]typedef std::string path_t;[/snip] is fine with me. At that point, I won't bitch about an optional class extending string whose constructor parses for backslashes. It's technically even legal to just do this alternative typedef in the user code without recompiling the code. I'm not sure if the behavior is defined, but it will work, anyway.
276
Announcements / Re: Licensing, the ultimatum
« on: July 03, 2014, 08:56:28 am »
I've read over the classpath exception. I even forged our own exception based off of it, inspired by another derivative of it someone was using in their library. Classpath itself was a little bare, so we focused on the augmented versions (mine and the one I referenced). People found issue with clauses in the two of them, such as the inability to create libraries using that library. TGMG argued that would be problematic on Android, where all apps are libraries. There was also difficulty defining what a "related program" is. We want to allow this special linking for games, not game engines. Game engines should only be able to preserve our license or switch to GPL. It's hard to write the legalese for these caveats, which is why I'm involving lawyers.
277
Issues Help Desk / Re: script threading does not work
« on: June 30, 2014, 07:27:11 am »
I forgot we maintained a search engine, for a minute, there.
278
Proposals / Re: ENIGMA + LGM = 1 Tracker
« on: June 30, 2014, 07:24:48 am »
That would be completely possible. It's also possible to just have two instances of that tracker on this siteāit's completely modular. I'm not volunteering right now. If someone else would like to install the tracker on their own test site and give it a whack, I welcome you to do so.
279
Issues Help Desk / Re: script threading does not work
« on: June 29, 2014, 12:19:11 pm »
I had to file some paperwork so that I am able to freely contribute code to this project. It's to make sure personal projects don't compete with existing Google products in a way that would cause a conflict of interest. Apparently the review board found that a massive game design platform was far enough from mainstream Google to not warrant concern, but they advise me to contact them again if ENIGMA grows closer into Google territory. I have no idea how this would happen, considering game design is an extremely inclusive field as it is. They probably just say that to everyone.
280
Programming Help / Re: How can I use large arrays more than 30 MB?
« on: June 29, 2014, 10:54:31 am »
Finding the motivation to finish this has proven problematic. Why don't you appoint someone to wrestling their way through my task list?
I'll polish up the output of whatever poor soul attempts it.
Just so everyone knows: This is a joke. I don't really trust any of you for the task. Maybe today I'll muddle through this lexer recode.
I'll polish up the output of whatever poor soul attempts it.
Just so everyone knows: This is a joke. I don't really trust any of you for the task. Maybe today I'll muddle through this lexer recode.
281
Issues Help Desk / Re: script threading does not work
« on: June 28, 2014, 06:01:23 pm »
The newer commits are not in the master branch. There haven't been any in a while for a number of reasons both legal and related to my own indecision, but the newest is much more recent than a year.
JDI is a C++ parser and object definition framework; it powers the new compiler. The new compiler itself is in a branch of ENIGMA's repository.
My current task, which anyone is welcome to pick up, is modifying the lexers used in JDI so that ENIGMA can more easily extend them. I plugged JDI into ENIGMA a little prematurely last time, and the maintainability suffered for it. I'm trying to avoid repeats of this mistake.
JDI is a C++ parser and object definition framework; it powers the new compiler. The new compiler itself is in a branch of ENIGMA's repository.
My current task, which anyone is welcome to pick up, is modifying the lexers used in JDI so that ENIGMA can more easily extend them. I plugged JDI into ENIGMA a little prematurely last time, and the maintainability suffered for it. I'm trying to avoid repeats of this mistake.
282
Programming Help / Re: How can I use large arrays more than 30 MB?
« on: June 28, 2014, 02:23:52 pm »
Interesting. My guess is that you're actually exhausting the 2GB of RAM Windows allows a 32-bit program to use. You aren't allocating 30MB, you are allocating 30 million entries. Even if each entry was only one double, that would actually be 240MB of usage. Issue is, you're not just allocating one double for each entry. You're allocating a double and a string, which is a pointer to a reference count, a length, and a few bytes of string. So now we're at 8+4+4+4+1 bytes, being extremely conservative. This puts you at 840MB. Now, here's the kicker: since your array is dense, and the size is not given up front, I have to resize it every time you overflow the space I allocate you. So by the time you hit the 32 millionth entry or so, I need to keep your array around, and then allocate a new array big enough to hold that array and then arbitrarily more information. There's just no way for this allocation to work inside of a 2GB addressing space.
Try putting this in the create event:
Also, in the destroy event, put [snip=edl]delete[] array;[/snip].
Try putting this in the create event:
Code: (edl) [Select]
local size_t size = 40000000;
local int *array;
array = new int[size];
for (int i = 0; i < size; ++i) {
array[i] = 65;
}
Also, in the destroy event, put [snip=edl]delete[] array;[/snip].
283
General ENIGMA / Re: Compatibility flags.
« on: June 26, 2014, 09:04:22 pm »
I believe there's a mechanism to specify a default. If not, adding such an option is trivial. Re-ordering an enum for the sake of specifying a default seems a bit archaic.
284
Proposals / Re: File operations SHIT slow in ENIGMA!
« on: June 26, 2014, 08:56:51 pm »
You can always just use the C++ functions, you know. Aside from that, the functions are slow because you are only buffering tiny chunks of data at a time, and you're casting it to STL strings. I believe Robert wrote buffer functions; do those not work with files? If not, consider using the C functions or writing wrappers around them (they're extremely simple).
I suppose you'll want the existing convenience functions which do things like read integers for you. In that case, I'd recommend just adding a file_bin_read_buffer() that does what the above does for large chunks.
In the future, we will likely offer memory mapping functions for that.
Code: (cpp) [Select]
FILE *f = fopen("yourfile.bin", "rb");
char buf[512];
while (!feof(f)) { // Until at end of file
size_t read = fread(buf, 1, 512, f); // Read at most 512 bytes
// process bytes here; `read` bytes were read in total
}
fclose(f);
I suppose you'll want the existing convenience functions which do things like read integers for you. In that case, I'd recommend just adding a file_bin_read_buffer() that does what the above does for large chunks.
In the future, we will likely offer memory mapping functions for that.
285
General ENIGMA / Re: Compatibility flags.
« on: June 25, 2014, 11:13:35 pm »
I guess we figured IDs were less ambiguous than strings, where in fact, it's easier to keep track of a string name than an ordering for IDs. I'd prefer assigning separate string IDs to each option, rather than using the label, for i18n reasons at the very least.
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 »