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

Pages: 1 [2] 3 4 ... 187
Issues Help Desk / Re: Extension .egm does not match EGM?
« on: November 15, 2015, 06:41:28 PM »
If you're interested in XML, you may as well use it for everything. And for that price, you may as well use GMX. My understanding is that the two aren't very disparate.
Of course, LateralGM still (and presumably always) sucks at working with both of those formats, so it's not as though binary room data is our only fish to fry.

General ENIGMA / Re: Splashscreens
« on: November 07, 2015, 10:41:00 PM »
My favorites are your first and thirteenth, Harri's, and your very latest.

Personally, I get enough of Material at work. It's not that it's a bad design concept—it just gets old, and it's pretty much Google's thing. That said, if construction paper's just your thing, here's a quick version with that:

So Robert's first remark was that the version I linked isn't saturated enough. So I doctored the construction paper scans:

I believe it's time to invest in replacing LGM. LateralGM follows the three-tier architecture, which is different from what Robert has linked but which does mean that there should, theoretically, never be a reason to replace it. As code from any layer becomes obsolete, it can be replaced as needed to keep current. However, due to some neglect, and some happenstance, all three tiers are obsolete.
  • The presentation tier is obsolete. Swing is a lousy framework with long-lived problems that developers refuse to correct. The inability to support mouse horizontal scroll is an example. Not to mention, people prefer native widgets. This isn't entirely out of the question in Java. Either way, this tier should be scrapped.
  • The logic tier is mostly solid, but makes fundamental assumptions of how the data tier interacts with data. Specifically, it assumes that passing all resources to the data tier will accomplish the task of writing out a game file. It offers no way of detecting whether a resource has actually been modified, and changing this is a TON of work. I think Robert once tried to invest this work, but I'm not sure if he ever got anywhere. By a "ton of work," I mean enough that recoding this tier correctly, from scratch, is not out of the question, even if we stuck with LGM. Game load times are similarly affected; the load mechanism requests that all resources are loaded up front, which includes massive MP3 files and long animations. If meshes were to be supported, they would also have to be loaded up front. This is a huge problem for LGM's progress into serious game development.
  • The data tier makes, of course, the same assumption. It serializes all data at once, doing no change detection, which means that saving a GMX/EGM document takes the same amount of time as saving the equivalent GMD/GM6/GMK/GM81. Actually, it takes longer on Windows due to filesystem overhead. Saving a document with only one changed resource should take virtually no time for GMX/EGM, and the entire game time for GMD/6/K/8/81. The same problem applies to game load. For later, I'll mention that five different people, Robert included, have already ported all relevant pieces of this tier to other languages.
  • All three tiers are written in Java. A lot of users have issue with Java, and 75% of our incoming tracker tickets are from people using the wrong JVM architecture on Windows.
With respect, I believe that people who choose the second option do so from a usability standpoint, unaware that their few problems with the IDE require an entire recode, in Java or in any language.

I forward that since a huge recode, even if not a complete recode, is required for the further progress of the LGM project, this recode should be done in a framework that does not tow the JVM behind it, and preferably one which uses native widgets. Sound (cogent) logic—and there's a lot of it; I know because I wrote some of it—should be preserved or ported, and the rest is being scrapped, anyway.

Works in Progress / Re: Flappy Wheels
« on: September 27, 2015, 08:30:27 AM »
Sounds like a board permissions issue. I've scrubbed board settings.

Developing ENIGMA / Re: Migrate Releases
« on: September 05, 2015, 07:44:36 PM »
There's hardly a more descriptive change title than "Hacks in a fix for multidimensional array subscripts. Fixes #904." The Git spirit is small commits with simple change descriptions. Coming from Subversion initially, I prefer larger commits with more detailed messages, to which git is also conducive. The list you gave essentially embodies the spirit of source control.

Google does not use git itself. Google3 is a completely linear, monolitchic codebase. It is not possible to commit code to Google3 that does not build, unless you issue commands to bypass the mechanisms in place. If you do that, you had better know what you are doing.

Anyway, it's clear to me that you know what these commit messages should look like. You may find tags or merge commits helpful. That is, do your work in your own branches with lax commit messages, and then either flatten them for commit to enigma-dev/master, or merge them and specify a useful commit message. You might consider annotating these with some kind of searchable token so that you can create changelogs between versions automatically. Following this, even if you were not careful to annotate all merges to master, you could still crawl all commits for useful changelog points. This could be as simple as putting Changelog point: before each line in a commit description that actually contains noteworthy text.

Just some ideas.

Developing ENIGMA / Re: Migrate Releases
« on: September 04, 2015, 10:38:09 PM »
It's true that I never tagged a release as r4. Things kept changing—more than anything, my expectations. You could number from there, or you could just call it V1. Or V1 RC1 and have fifty of those before you just call it V1. It's up to you. I prefer rolling releases. The way version control is supposed to work is that master is supposed to be stable at all times; ready for a nightly build whenever. You then have multiple work branches that might not build, or might not work. This never really came to be in ENIGMA... my attempts to introduce it ended badly.

GitHub can tag releases for you, yes.

For a long time, the "Developer" tag was just a repaint of "Administrator," but I eventually fixed that (they're regular SMF membergroups, now, and I hard-coded tags for them). I wasn't very diligent with updating assignments, though. Of course, Harri is a privileged member—just not an administrator. This is mostly because the admin panel is duct-taped together, and it's very easy to break something in it, so I tend to stay out of it myself and don't see a reason to give anyone else access. But yes, I only fixed his "Developer" badge a few months ago. In my defense, there were political reasons that had nothing to do with my own feelings which prevented this change in the earlier stages of the board.

General ENIGMA / Re: Joshedit
« on: August 26, 2015, 09:24:55 PM »
They are the only things I need. But I think I would try implementing all of that differently. Was there a reason you didn't want to do all of that with classes? Like one class per object. Then object.somevar would literally be correct C++ syntax to getting and setting a variable. The only reason it wouldn't work now is because you can assign a variable at any point (even inside a with(){} statement which cannot be determined at compile time). So what I suggest is making "local somevar" declaration mandatory. This would allow creating a list of variable in the class. Actually you could still use a map inside the class for variables that are undeterminable at compile time (like it is done now). Int to instance conversion could also still be possible.
GM's overall design is not conducive to that. It's similar to something that would be conducive to that, but it's not immediately conducive to that. Take instance_nearest, for example. The correct GM syntax is instance_nearest(x, y, obj_target), where obj_target is the integer ID of your target object, or any other identifying integer in GM (namely the any constant, but it's technically valid to pass noone or an instance ID, which guarantees that the given ID is returned). The return type is also integer.

What you would want in a better language is something more like instance_nearest<obj_target>(x, y). To contrast,
Code: (C++) [Select]
// Current prototype; gives no useful information
int instance_nearest(double x, double y, int object);

// New prototype to support the above proposal
template<typename object> object& instance_nearest(double x, double y);
any& instance_nearest(double x, double y);

This code assumes the existence of a type called any which represents the highest object tier (object_locals). Using instance_nearest<any>(x,y), you can still implement RTTI (probably in the form of just accessing object_index) to ascertain the type of the returned object and correctly cast to it, but otherwise, no casting is necessary. Without totally redoing all of ENIGMA's instance functions in this manner, however, your code would have to look up the object and cast it every time before you can access nearest.somevar at all. This will bloat your code, look hideous, and be a general pain in the ass to write and maintain.

Quote from: TheExDeus
I can be less dirty, but I don't think it needs a billion features. Just make it load and compile egm. Compilation is done trough makefile flags anyway. The only thing CLI actually does is it parses EDL and then adds resources to the compiled exe.
Not so much about it being dirty as it is about making it long lasting, etc. Josh's library has something to do with parsing command line flags, you should ask him about it.
I would hope the CLI has more options than that, but yes; at its most basic, the point of the CLI is just to build a GMK/GMX/EGM, and that can probably be accomplished by verifying argc==2 and taking argv[1]. Odds are, though, you want to support things like --syntax-check myfile.edl or --attach-resources resource_directory ouput.exe. The library I wrote that Robert is talking about is called DeepFlags, not GFlags. You might be interested in either project, though.

A few other things to address.

(1) Robert also wanted me to mention the language I'm designing in my spare time. I haven't put any code down that is specific to it, and even if I had, I'm not sure that it immediately offers a solution to this problem, but I'll go so far as to say that providing a means by which you can address the instance_nearest problem described here and the choose problem described elsewhere (and elegantly address the problems we've already solved, such as script_execute) is a lot of the motivation behind the language's design—not out of regard for Game Maker/ENIGMA, but in response to places where C++ has limited our ability to do this naturally. I'm happy to talk about features of this language; I occasionally do on IRC.

(2) I'm still and always very interested in IDE development, though I'm not, as I've told Robert a couple times over the last two weeks, presently "in the mood" to write an IDE. I believe that the IDE is ENIGMA/Game Maker's number-one asset. It's far more valuable than the language to the success of these two projects. I don't think a CLI is a replacement for a proper IDE. The room editor is indescribably important, and the Overworld resource I described would make a huge difference, as well. I'm also interested in numerous other editors. I'd like to try my hand at a FSA editor, for instance. Happy to talk more about this, as well.

(3) According to Robert, you're under the impression that I want some graph bullshit instead of coding. No; that would be insane. There is no "instead of coding." Coding is what makes things happen. But coding is everywhere: Every toolkit has coding. What makes Game Maker cool? You don't have to write code to place objects in a room. You just place objects in a room, visually. That's what made GM stand out. More editors have surfaced that do that, of course, so it seems less unique; less important. I'm arguing that it's still the most important part. Offering a way to construct a FSM to handle, say, animation or AI for an NPC, is another way to remove some boilerplate and code complexity. Like, how much of your code is if (current_state == running) { sprite_index = spr_player_running; do_run_behavior(); }? Wouldn't your life be improved if you just had a "running" behavior you could edit, and a FSM entity that governs transitions sprites and the trivial bits of the transition logic for you? The Overworld resource I mention from time to time is another critical asset. Another great asset would be a way to visually account for game unlockables. Think of stars and star coins in the Mario series. Wouldn't it be nice to see a list of which levels contain those? Where they're placed? Wouldn't it be nice if the code to organize that was all generated for you transparently? This is what I'm talking about.

Anyway, I think that's what needs said, for now.

General ENIGMA / Re: Joshedit
« on: August 25, 2015, 08:04:47 PM »
Even in its current state, ditching the parser would probably be an unpopular opinion. I'd recommend adding a tag for the beginning of code you don't want formatted. You'd probably miss it yourself unless you never use object.somevar or with().

I'll point out that a lot of the reason I don't want to work on it is that the project is perpetually broken on Linux. It's been two years since I've been able to do a git pull and compile a game on Linux. That's why all our other Linux users either maintained their own forks (as DarkAceZ did, and he was 14 fucking years old at the time), or left (as most others did). Not to mention that a lot of things I did had side-effects that people would address by effectively undoing the thing that I did. It's no fun fighting an uphill battle.

General ENIGMA / Re: ENIGMA progress
« on: August 01, 2015, 10:58:21 AM »
I'm impressed, Harri. I don't have much else to say.

Issues Help Desk / Re: Some Fervi's Question
« on: July 11, 2015, 08:41:14 PM »
Sorry, Harri; I thought I hit reply, but apparently my response is victim to the ages. Apparently the question of what a FSM editor would look like has been answered by Unreal3D. I would prefer the ability to group nodes (or ideally, to have nested state machines in nodes, for different systems to use) in my implementation, but otherwise, the U3D editor looks sound.

I don't know what you mean by every variable being a switch statement. I worked hard to make sure that isn't the case, even in var. Lookups between objects are switch statements when the type of the object is ambiguous (which, for ENIGMA, I think is every dot-access for custom locals).

I think our best option for providing GM "support" in the future is to make sure that the warnings and errors the compiler emits are easy to operate on. For example, GCC will warn when you say if (someVar = 10), suggesting that you wrap the assignment in parentheses. If ENIGMA emitted this warning, a compatibility layer (read: trainspiler) could replace = with ==.

I already had proposals to deal with Game Maker's lack of type system (and ENIGMA's failure to strongly introduce one). In Game Maker, choose(c_red, obj_sunflower, 10.5, "hamster") is completely valid. ENIGMA retains this; the return type is var. In a better language, this would be disallowed, while choose(c_red, c_green, c_blue) would be allowed, and even choose(obj_sunflower, obj_ladybug, obj_cloud) would be permitted. This is the easy part. The hard part is knowing that instance_nearest(x, y, obj_sunflower) is not just instance_t, but an instance of obj_sunflower. I am still thinking about elegant ways of addressing this, from a language design standpoint.

I won't labor over what else to include in this post, because if I do, it might end up not being posted, again. So yeah, just some initial thoughts.

Issues Help Desk / Re: Linker crash
« on: July 04, 2015, 09:09:40 AM »
If I had to guess, this is because Bash is capable of parsing any number of characters into an array of strings, while Windows is a worthless pile of slag. I don't know of a different way of conveying files to be linked to the linker, and those ways would be pretty barbaric, anyway.

There might be a way to switch Make's shell interpreter to Bash. Does running make from MSys-bash still give the problem, or only running it from cmd? The printout you gave looks like cmd.

There are ways to tell if you're in a bash environment from within the makefile, if you'd like to print errors.

Another solution would be to build static libs for each system before linking them. A third solution might be switching to cmake.

Issues Help Desk / Re: Some Fervi's Question
« on: June 30, 2015, 07:29:24 PM »
You've been missing out on a lot of conversation on that topic, Harri. The short of it is, I think Game Maker (and ENIGMA by extension) would be more greatly benefited by, eg, a finite state machine editor than by the "perfect language" I was trying to design. I still want a highly cross-compilable language, but I think that everything that made Game Maker and ENIGMA any good was in the editor, not in the compiler. The compiler's just the thing that makes it finally work, and ENIGMA wasn't even really good at that.

I haven't finished planning something elaborate enough to rekindle my interest in developing it, but we keep tossing ideas back and forth. PHP isn't a consideration; it might actually be the worst language in existence.

Issues Help Desk / Re: Cant open ENIGMA because of LGM
« on: June 02, 2015, 09:07:38 PM »
According to that exception, one of your extensions is missing an ID. This shouldn't really happen, which is why we've never seen (and therefore added handling for) that particular exception in the past. Have you tweaked any of ENIGMA's extension files?

A NullPointerException during save can mean any number of things. Do you still have the file that failed to save open? You can attempt to save such a file in different formats to avoid losing work (assuming that the problem occurs every time you save in the same format). If not, did you save the exception it threw? It would be useful to have so we can fix whatever went wrong (or at least make it so LGM recovers from it more cleanly).

If you closed LGM as soon as it failed, and it didn't save the resources you changed before the exception, and the exception caused the save to abort, then no, there's no way to recover those changes.

If you were asked to save because you tried to close LGM, and then the NPE occurred during save, but LGM nonetheless closed, let us know. That's a pretty nasty bug.

Pages: 1 [2] 3 4 ... 187