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

616
Teamwork / Re: Looking for well rounded programmer
« on: July 27, 2013, 02:20:31 PM »
Hi there,

I'm not sure why you're looking for a C++ programmer. EDL (the codename for ENIGMA's language) can be remarkably similar to GML. While it offers strong typing and explicit declaration, both mechanisms are unnecessary. Barring missing functions, and a couple syntactical elements which appeared to be bugs in Game Maker and have therefore been deliberately omitted, EDL is supposed to be 100% backward-compatible with GML. In practice, of course, your mileage may vary, but that's why we have a bug tracker.

Either way, good luck with your search.

617
Off-Topic / Re: YoYoGames Compiler for 300$
« on: July 27, 2013, 01:13:30 PM »
A measly $300 for shaders? I should stop developing ENIGMA and use GM:S.

618
General ENIGMA / Re: Scalar Types
« on: July 27, 2013, 06:33:24 AM »
The coordinate space uses the collision system/physics system scalar.

This seems to universally be float.

619
Agreed.

While this would ideally be done as a complement rather than supplement to manual testing, until the regression testing suite is more complete, I think it's in our best interest to set something like this up as soon as we are prepared for branching. My only major concern is how it will handle things like antialiasing and rounding issues (for arithmetic tests). For example, the test suite might expect a given pixel to be any color between pure blue and pure white, while in fact it ended up being one or the other due to minute hardware differences. Likewise, the suite may expect .1 + .1 + .1 to be roughly .3, while in fact the value differs with the phase of the moon. On a happier note, I have high hopes for its performance with string, data structure, and I/O operations, as those tend to have only one right answer (not to imply that .30000000004 is a right answer to .1 + .1 + .1).

That said, if the system seems to do well in these cases, though, I'm fine entrusting it to the complete task. Especially considering one of the worst (and, incidentally, most frequent) regressions is a complete lack of ability to compile with ENIGMA on one platform or another.

It would be particularly useful if we could get cross-compilation working as part of this system, too, as contention between the tastes and preferences of MinGW on Linux vs Windows have led, on a thousand separate occasions, to the dysfunction of one system or the other. Reports are rolling in now that OpenAL doesn't work at all on Windows, and the simple explanation for this is that cheeseboy couldn't get AL working on MinGW for Linux, so he packaged his half-assed SFML system in his installer without paying any attention to AL. Then polygone and Robert decided, "WOW, A WINDOWS INSTALLER THAT ACTUALLY WORKS," buried my zip patch elsewhere on the Wiki, and put his up as the only installation candidate. Also, the bundled SFML doesn't work on Windows. Look where that leaves us.

The point is, as far as making sure the system actually compiles on each platform, this automated testing is invaluable. Pitted against our current system of "commit everything to master and wait for the flood of bug reports," I think the winner is clear.

620
Off-Topic / Re: YoYoGames Compiler for 300$
« on: July 27, 2013, 06:05:13 AM »
I've heard record-breaking reports of how preposterously buggy GM:S is. And they only want $800 for the whole thing?

Amazingly generous. Hard to compete with that bargain.



I'm actually really surprised.

That I didn't see this coming.

I figured they'd just fail out on the LLVM idea when their performance was magically worse than it was when they were interpreting the code. :P

621
Extra awesome. ENIGMA has needed this for a long time, but I never got around to doing it; instead I ended up joining the others in impatiently pressing forward with whatever we had.

I will give this a look over next I'm free. Whenever that is.

Thanks a ton for the work!

622
General ENIGMA / Re: Graphics Systems Precision
« on: July 25, 2013, 05:53:53 AM »
The improvement is that the cast is done by the user as needed. If the user has a float already, no cast is required.

623
General ENIGMA / Re: Porting Project Mario
« on: July 24, 2013, 07:18:36 AM »
1) set_working_directory(filename_path(parameter_string(0))). Deal with it.

2)  This isn't far off. If you're in that big a hurry, use this in definitions:
Code: (C++) [Select]
#ifndef JUST_DEFINE_IT_RUN
  #define call_inherited(object_name, event_name) OBJ_ ## object_name :: myevent_ ## event_name ();
#else
  void call_inherited(int object_name, int event_name);
#endif

Then in your EDL, eg, in the step event for obj_particle, use call_inherited(obj_particle, step);. That should solve it for now, if you're that impatient.

3) Go ahead and use Spirit's, or you can use e-YAML, for which the parser can be found in Compiler_Source/settings-parse, or something.

4) I have no idea how transformations would be "fucked." Especially if they're handled by a shader in the new system. A shader can treat them precisely as GM does, regardless of API.

5) Persistence worked when I wrote it. It's not a difficult mechanism. If there's a bug with it, file a bug report with a test case.

624
Issues Help Desk / Re: missing surface functions?
« on: July 19, 2013, 04:00:41 PM »
I think someone previously tried to commit a copy of lodePNG. Specifically, "canthelp," under the alias "sssstest." The pull request is here.

I was about to merge it, but he closed it.

625
Issues Help Desk / Re: missing surface functions?
« on: July 19, 2013, 02:22:00 PM »
Go ahead and commit them.

626
Proposals / Re: OpenGL chosen by system (?)
« on: July 19, 2013, 08:19:23 AM »
No, I promise that eventually, companies will cease to bundle compatibility drivers with their shit. I don't know when that will be, but when it happens, GL1 and DX9 applications will cease to function.

Regardless, offering the option to build for both is the best we can (or at very least should) do.

627
Proposals / Re: OpenGL chosen by system (?)
« on: July 19, 2013, 08:02:06 AM »
You'd be surprised. The graphics pipeline has changed; GL1 was designed around the FFP. DirectX changes so much as to be impossible to salvage old code, from version to version. OpenGL has remained "compatible", but a lot of what you do is emulated software-side. For example, pr_linelist, pr_linestrip, pr_trianglelist, and pr_trianglestrip are all that's left, hardware side. And the strips are on their way out. It's getting to where your only choice is between lines and triangles.

Anyway, reading over his request again, I think you're right. I don't have any intention of supporting that, presently, as it removes the possibility of link-time optimization. Specifically, inlining graphics calls. Compared to the actual work done processor side, this is small, but it still aggravates me. It also bloats the game from having two of the same thing in it, although the amount of duplication has been improving, lately. In the event I get around to actually making a game in ENIGMA, my inclination will be instead to release two versions. This is assuming that neither (1) I determine that the game doesn't need mind-blowing graphics, and GL1 is fine, or (2) I determine that if your shit doesn't support GL3, it has no business attempting to run my game.

628
Proposals / Re: OpenGL chosen by system (?)
« on: July 18, 2013, 02:14:28 PM »
This has already been added to the new parser, in the form of preprocessors.

Code: (EDL) [Select]
{{if ENIGMA_Graphics == "OpenGL1"}}
  opengl1_do_stuff();
{{else}}
  opengl3_do_stuff();
  opengl3_special_stuff();
{{endif}}

629
Issues Help Desk / Re: missing surface functions?
« on: July 18, 2013, 02:12:13 PM »
ENIGMA actually ships with zlib. My concern is that we haven't set up a codec/format system in the extension system to cleanly allow plugins to add import/export formats.
Right now, the sprite_save/load functions only work with bitmaps, and the sound_add functions goes through ALURE. Not very extensible. That needs revisited, but it is at the bottom of my to-do list right now.

630
General ENIGMA / Re: Hi There
« on: July 18, 2013, 09:22:38 AM »
Right. ENIGMA offers a few things over game maker.

  • It's free, as in gratuito. You This means not only that you don't pay a nickel for it if you don't want, but that there is no DRM that replaces your hard work with pictures of skulls and cross bones. It also means no license-oriented spyware, and no hassle to download, install, and use.
  • It's free, as in libero. This means that if you want to change something in ENIGMA, you have the freedom, as much as the much more ready ability, to do so. Anyone can contribute, and we strive to make it really easy to do so.
  • It's extensible. Yoyo's approach is to hone in on a specific graphics/audio/windowing system to cater to its very specific target platforms. ENIGMA does not have such a dependency on any one system; you can switch out OpenGL versions without modifying any of your code, and the bulk of my current work is to make it so you can switch out the host language just as easily.
ill also be limited to fewer potential platforms. LLVM itself cannot build for all the platforms ENIGMA will (and has) built for. This is including the very early ports we saw for iPhone, Android, Wii, and the Nintendo DS.

Even if Yoyo's speed matched ours completely, they will find that it's hard to compete with free and open. Lately, our contributor base has been growing past any original projection—while this can mean some degree of chaos, when components are easy to swap out or remove, it really has no drawbacks.

As for LLVM, it doesn't really appeal to me. They will enjoy quicker compile times, maybe. They will also be limited to fewer potential platforms. LLVM itself cannot build for all the platforms ENIGMA will (and has) built for. This is including the very early ports we saw for iPhone, Android, Wii, and the Nintendo DS. While those ports were short-lived in ENIGMA, they did not require excessive modification, and this remodel seeks to ensure it requires zero later on. LLVM's support stops after the first two. Moreover, if they ever did incur benefits from LLVM which were not available to us in GCC, writing an LLVM backend for ENIGMA would be pretty easy, and using Clang for ENIGMA would be trivial (and has been successfully done).