ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

Show Posts

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.

Messages - Josh @ Dreamland

Developing ENIGMA / Re: Iji on ENIGMA
« on: July 07, 2014, 07:50:51 PM »
Looking good; the tearing's a little disturbing, but you've made some great progress, it seems.

Could you enumerate the changes you don't want to push to ENIGMA? I'm aware of the "backslashes in paths" hack, but I believe proper macros will nip that issue in the bud down the road. I'm interested in knowing what else you changed, because I want to get macros, metaprogramming, and plugin scripting to be powerful enough for you to be able to enact those changes as part of the game file. I can't make any promises without knowing them, obviously, but having some time to think about them will certainly help.

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:
  • 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 make test to test
  • If the tests don't pass, tweak the code and rerun them.
  • Once all tests pass, drop me a pull request.
That's the contribution model ENIGMA should arguably be on, and it's the contribution model I'll be sticking to. If no one can deal with that, I suppose I'll continue development at my own pace.

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.

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.

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.

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.

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 for (i = 0; i < 10; i += 1;).

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 typedef std::string path_t; 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.

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.

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.

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.

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.

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? :P

I'll polish up the output of whatever poor soul attempts it. :P

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.

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.

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:
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 delete[] array;.

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.

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).

Code: (C++) [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

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.