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

General ENIGMA / Re: Where to put the commit feed?
« on: April 28, 2013, 07:35:06 PM »
I like it where it is.

The only thing you should watch out for is some of the existing hacks. Most of them are local to the math header. I define the bessel functions to be declared with a bessel_ prefix to avoid conflicts with variable names like y1. There are other, similar hacks. Removing those will break some games. When the move is finished, the macros that do that will need to be removed, and the bessel functions simply declared in namespace enigma_user to call the corresponding stdc functions in ::.

Make sure, also, that somewhere in the code, namespace enigma_user { using ::var; using ::variant; } appears.

When you guys are ready, tell me, and I'll make the very few changes necessary to change from :: to ::enigma_user.

Issues Help Desk / Re: Mark the Penguin [Weird Glitch]
« on: April 28, 2013, 01:38:58 PM »
That is for return values to check between two instances involved in a specific collision. It does not imply that passing object1|object2 to collision_point will make the function know to check against instances of both objects.

Issues Help Desk / Re: Mark the Penguin [Weird Glitch]
« on: April 28, 2013, 02:04:28 AM »
Hate to rain on anyone's parade, but collision_point(x,y,object38|object39|object40,1,1) is equivalent to collision_point(x,y,object47,1,1) (assuming object47 exists) unless GM does special parsing for ORs inside collision functions, which I am all but completely certain it does not. Any resemblance to intended behavior is coincidental. To achieve that more efficiently, those objects should be given a parent, and the function should check for collisions with that parent object.

That's the only reason I haven't split this topic. I figure this "discussion" (read: contributor flame-war) might give burnbout an idea of what development here looks like.

General ENIGMA / Re: Abstract Object Types
« on: April 19, 2013, 05:19:57 PM »
I do plan to graduate shortly, but not this semester. I might be able to graduate by summer's end. But all my hard courses are officially out of the way, now. So, I will likely indeed be giving less of a fuck about school.

General ENIGMA / Re: Abstract Object Types
« on: April 19, 2013, 09:19:02 AM »
The mechanism you're describing would bog everything down. I've designed the extension system to ameliorate that effect, but it's presently out of commission due to virtual cast issues. When the new compiler is in, those should be fixed, and you will be able to use the extension system for that. Though, it will need extended; right now, it is an all-or-nothing system. There's no mechanism to allow objects to specify which extensions they use, but I must say, I like the idea of allowing for one, and I could implement a much better system in ENIGMA than std::bad_cast.

General ENIGMA / Re: Abstract Object Types
« on: April 19, 2013, 08:31:33 AM »
Get started what? I like the "uses physics" idea. It lets physics systems (such as Box2D) know whether or not to generate bodies for each instance.

Unfortunately, most of those have died during my class-related absence from the project.
Here's the state of them, as I understand it:

Run: The point of Run is to build quickly, but run basically the same as it will run when ultimately built. It gives you the best idea of what your game will be like when released. It's also the only option you can count on working, because most of this project's developers don't understand that their changes might work in one mode, and not in another.

Debug: Debug mode has mostly survived due to its utility. The purpose of debug mode is to create an executable with full debugging symbols to allow attaching programs such as valgrind or GDB. Debug mode also does checking for issues in your game, such as attempting to draw a sprite that doesn't exist. In C++, those kinds of issues usually result in the death of the game.

Design: This mode was in our third demo release, but fell into disrepair during the branching of the project to work on more platforms. It relies heavily on widgets, which are only recently fixed upstream (and we're still having issues with the installer that uses the new MinGW with the bug fix—see BinUtils #13297. Barring more issues with the installer, the only issue is that IsmAvatar (LateralGM's maintainer) and I don't have enough free time to collaborate on its re-introduction.

Compile: This one's all IsmAvatar. When you build on Windows, you must use the extension ".exe" or MinGW GCC will add it for you, which in turn makes it so ENIGMA can't find the executable to add resource data to. To fix this, we were going to add extension information to the compiler configuration files in, eg, Compilers/<platform>/gcc.ey, along with a plethora of other changes to account for huge differences on MacOS vs Windows vs sane operating systems (On Mac, applications are special directories instead of single binary files). The specification was never fully laid due to a lack of collaboration between developers from all three platforms (OS X being the one we were always missing).  As a consequence, Ism never added a fix for the file extension, despite nagging from fifty people. I think TGMG hacked together the entire Mac port, anyway, to be honest. I don't even know if it works, because no one ever tries to use ENIGMA on it except TGMG and ugriffin, neither of whom I've seen for two years.

Rebuild all: This option just deletes all the object files and binaries, forcing ENIGMA to rebuild them. It's helpful if something breaks in the build process (which is very rare, and not to do with ENIGMA).

So now you know.

Proposals / We need our own flag for ignoring return values
« on: April 18, 2013, 03:00:51 PM »
With some functions, it's less obvious you really need to use the return value. Like string_replace_all(). When I was young, I spent ten minutes figuring out why string_replace_all wasn't doing anything. I was livid. It's a good case of RTFM, yes, but it's also a great case where we can save users a lot of frustration by using flags like need_result, or something.

This is basically a note for me to add the function into JDI, possibly with more compiler hints. If you have ideas for more compiler hints, post them here, so I can best think up a system for handling them.

Issues Help Desk / Re: Error compiling the Sample Catch the clown
« on: April 17, 2013, 10:39:34 AM »
Hey polyfuck, just noticed you changed my Winpatch zip. Why?

Issues Help Desk / Re: Error compiling the Sample Catch the clown
« on: April 16, 2013, 11:18:05 PM »
Interesting. I didn't create that installer; another developer did. I'll wait for him to try to explain what went wrong with it. The issue is certainly to do with windres.exe, but since his installer contains a version he's tested to work, I am not sure what the issue is.

Issues Help Desk / Re: Error compiling the Sample Catch the clown
« on: April 16, 2013, 08:32:10 PM »
ENIGMA attempts to bundle a version of OpenAL in with user programs for supporting systems that do not have it already installed. Your compiler thinks there's a syntax error in the resource file that instructs it to do so. There isn't one. How did you install MinGW?

Issues Help Desk / Re: Compiling Option
« on: April 12, 2013, 11:29:45 AM »
I... don't remember, either. I think if you run %TEMP% it'll take you there. I think it's under ~/AppData.

Issues Help Desk / Re: Compiling Option
« on: April 12, 2013, 11:24:25 AM »
If that's all you need, go for it.