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

1801
Announcements / Re: ENIGMA R4
« on: August 10, 2010, 12:50:27 AM »
Don't remind me. *sigh*

1802
Announcements / ENIGMA R4
« on: August 09, 2010, 11:39:23 PM »
So I pulled overtime. I Haven't eaten anything today but a bagel. And a handful of spaghetti, which I grabbed out of a bowl as I walked by.
R4 is ready for release, but there's a problem. I was depending on a certain IsmAvatar for an update that would enable LateralGM to download and build ENIGMA. I spent the whole day getting everything perfect. But she's gone. So everybody post "WHY, ISM? WHYYYYY?".

Anyway, here's how the release today (8- 10 -10) works:

WINDOWS:
Download.
Unzip.
Double click ENIGMA.exe
Do what it says.
Wait.

LINUX:
Most Linux users have been using R4 for a month or so. I'll see about putting a .deb and a... whatever that thing is that Retro uses. Hey, Retro, can you assemble those for me tomorrow?

Anyway, I'm really bummed about the release not being 8-9-10, especially that it wasn't even at 11:12 like I thought it would be when the amazing Super Ism showed up to save the day. But hey, life goes on, especially for ENIGMA.

Currently implemented:
  • Sprites
  • Sounds
  • Rooms
    • Views (haven't tested in a while) (view_object may not do anything)
    • Background color
  • objects
    • Code
      • Types
      • Keywords global and local
      • Template types (imported from C++)
    • DND
      • Framework laid (basic flow, but functions are not implemented
    • Heredity
      • Works by nature of the instance system, but code is not yet inherited properly
    • Events
      • Conditional events
      • Extensible system (event conditions and classifications loaded from a file)

And of course, the function lists have grown significantly. I will see about getting those up sooner or later. But I'm feeling very abandoned. I don't really blame anybody; it's just that today was apparently not a good day to say, hey, let's get a zipped distributable out!

So. What will happen tomorrow:
1) I'm implementing sound_loop, sound_pause, sound_isplaying, sound_ispaused, sound_resume
2) I'm making sure users have access to WhiteSpace (the name-pending C++ resource).
3) I'm making sure X.Y works, at least as well as it did in R3.
4) Ism is finishing work on her updater. Or else.
5) I will see if Retro will prepare a deb and archwhatever containing the essentials for LGM and ENIGMA on Linux.
6) The same is basically done for Windows as it stands (just waiting for Ism...)
7) See if a2h can fix some things on the site.

See you all then. Be there, or be *mutter mutter* (and if you happen to be IsmAvatar and are not there, I'll shoot you.)

1803
Announcements / Re: Shortcuts
« on: August 09, 2010, 10:59:20 PM »
That's already implemented. You can see it in abs(). It's fine, because I Just do this:

double abs(variant& x) { return abs(double(x)); }
double abs(var& y) { return abs(double(y)); }

1804
Announcements / Re: Shortcuts
« on: August 07, 2010, 06:23:22 PM »
Haha. Rest assured, I know how crucial it is. Don't worry, it's functional, it's just not as precise as it should be. The performance and ability to use it for most purposes isn't really affected. It will only cause issue if two functions are overloaded with radically different return types.

1805
General ENIGMA / Re: collisions....
« on: August 05, 2010, 10:53:55 PM »
I'm not sure who I trust to work on the collisions other than Luda. So I'm thinking about it.

1806
Actually, I realized depending on all of those libs was problematic in that it was a pain in the ass to get people to install under so many different names, so I included them in with the rest of ENIGMA and set it up to compile them for you.

With the exception of mpeg123, which I will work on next. Installing manually it won't help you anyway, though.

1807
Proposals / Re: Steam
« on: August 03, 2010, 01:44:48 PM »
Only on Windows and Macintosh, it seems. Other than that, intervention by myself or someone else versed in how ENIGMA handles platform differences may be required. I'm looking in to how they separate Mac from Windows. Perhaps it could be used to separate different Linux distributions as well. But yes, you should think of ENIGMA games as you would any other C++ project. No smoke, no mirrors, and no interpreters.

Okay, I've read over their stuff, and it's as if they're being deliberately uninformative until you contact them. Meaning they're wanting people to bite. But I will contact them here in the next week to see what they have to say.

1808
freezway: If they're as new to the OSS world as I imagine they are, have them wait six days.

1809
Proposals / Re: Code Formatting
« on: August 02, 2010, 06:18:09 PM »
A typical formatter can be written without a lex of any sort. I could do this with my style relatively easily. Different settings are plausible as well, without too much hassle, I mean. Currently, ENIGMA's output 'formatter' is a lazy piece of work that outputs it in "sort of legible" format. I keep very few variables, and no stack or anything, so it gets pretty ugly at times. Everything is given a space around it regardless, for example. So we see things like "; i ++ )". But I could pretty easily get the system in general to work for the sole purpose of beautification, if I wrote a new ending segment that simply put everything in a nice format.

Not right now, though. You and I still need to discuss getting that highlighter of yours to recognize my ever-changing function list...

1810
Proposals / Re: Just an appreciation
« on: July 30, 2010, 09:05:41 PM »
I don't believe I'll ever let it. A lot's changed since you've been here. Kinda makes me miss the old days. But, alas, progress is good. We're still in beta, if you want something to laugh about. But we're running out of reasons to be and things to blame on being in beta, so maybe we'll just call it a version after this. *shrug*

...Nah, this has always been the plan. Although that C parser I wrote took a bit longer than anticipated. Along with, well, pretty much all the other well-done components. I'm quite happy with the way things have been turning out... Bit more to organize, but yeah.

Anyway, how've you been?

*considers moving thread to off-topic, but doesn't care enough to*

1811
Proposals / Re: Just an appreciation
« on: July 30, 2010, 07:13:55 PM »
I hadn't realized you were still alive, Dave. I haven't heard from you in 204 days, 9 hours, 19 minutes, and 43 seconds; but who's counting?

1812
Announcements / Re: Shortcuts
« on: July 30, 2010, 07:08:01 PM »
I used foreach for multiple reasons. One was so it didn't conflict with the 0x model. Frankly, C++ has had room for one for a while. If all the 0x model can do is const arrays (with explicit bounds, I mean), fuck it.

1813
Announcements / Re: Shortcuts
« on: July 29, 2010, 03:53:42 PM »
That actually made me laugh. I'm sorry. I'll do something interesting and easily understood when sounds work after revision 310.

1814
Announcements / Re: Shortcuts
« on: July 29, 2010, 12:25:19 PM »
This is not why I write intricate news posts.

1815
Announcements / Shortcuts
« on: July 28, 2010, 10:34:26 PM »
Long, long ago, in a land far-- actually, it was in this chair. Or some chair that looked similar. Be it as it may, a while back, I took a shortcut and thought, "If this ever comes back to bite me, it'll be after the rest of the project is stable and I can fix it without fear." Well, that mostly came true. There are no detrimental effects at this time, simply because the amount of skill required for the malefaction to manifest simply isn't being exhibited by ENIGMA users at this time. For those who wish to be weary, this is the issue:

When I designed the C++ parser, I did not implement a proper overloading system. Overloads were, instead of instantiated as children of a main instance as I considered doing, applied to the current copy by way of modifying the bounds for acceptable parameter numbers. For instance,
Code: (C) [Select]
string func(int a) { return "test"; }
double func(int a, int b) { return  "test2"; }

is stored only as a function returning double that takes either 1 or 2 parameters. Had the second function taken three parameters, the choices would be 1, 2, or 3, even though 3 was actually an invalid option. This makes for a blazingly inaccurate syntax check in rare situations (a GML user would never come close to noticing).

It also means a less pleasant inaccuracy on a more important system.
The following expressions were passed to a new type resolution system of mine:

room_speed
var
*var
room
room + room
room + 1
room - 1
var[5]

The results were, respectively, as follows:
Let's see if I can't waste some space and make a nicer table.

room_speed=>int
var=>var
*var=>double
room=>roomv
room + room=>variant
room + 1=>variant
room - 1=>double
var[5]=>variant

The more curious of you have a few questions. I'll do my best to answer those here:
room_speed and the like are being left integers. I see no point in wasting memory and speed so users can set some random array element in global scalars.
The type resolution system doesn't distinguish between cast and type at the moment (by choice, so I can debug without thinking of a global by that type. :P)
The type "roomv" is a special type with an overloaded operator= that calls room_goto(). It inherits from variant.
Because "roomv" is a special variant, room + room will return variant. This is correct. Room + anything will, in fact, so you can keep adding things such as strings.
However, room - 1 is double because subtraction only works on such. It wasn't worth it to avoid a warning on re-cast. Maybe I'll change my mind later, but in any case, the resolver was accurate.
Calls to [] on var are indeed variants.

So what's the problem? Look at item three, "*var". The parser can't distinguish between binary and unary *. Even though it knew it wanted the unary version, it couldn't get the accurate type, because I only store the type of the last declared overload, and so the parser was given `double`, the type returned by the multiplication operator.

When I need, I will store all overloads with argument counts and types, but that is a job for after the basics are all working. I want one more thing to work before I proceed, and it is indeed a trick; I would like for templated types to work, and if possible (by which I mean, it shall pass), templated casts. This way, if you have map<int,int> amap, you can say amap[whatever].x and have it behave correctly. That has been important to me since square one.




Another nice thing I can implement with the help of this system is the switch() optimization, as well as something brand new.

It befuddles me that neither C++ nor GML have a foreach construct. ENIGMA will be given one. It will work rather uniquely, since neither language was designed for it. Basically, it will have the following syntaxes:

foreach (array as element)
foreach (element in array)
foreach (element : array) //Java-esque

Trouble is getting it to work around this little issue: "in" and "as" are common variable names. So, I'm going to work around that thanks to how carefree my parser is when it operates.

Code: [Select]
foreach in in as
  do_something()

will work fine.

To ease the sadistic and curious, that will look like this in intermediate parse:
foreach(in)in;as;do_something();
sssssss(nn)nn;nn;nnnnnnnnnnnn();

Which makes it very easy to parse out. The first item, in (), is either what I'll be iterating, or the element name. The second, of form "nn;", will determine which; it should be "in" or "as". The third set, denoted easily by regexp /;(^;);/, is the corresponding element of the foreach.

So, how will that work from there? Simple. I determine which is the container to iterate. I then check for the following:
  • Typedef by name "iterator"; iterator container::begin(); iterator container::end(); iterator::operator++() or iterator::operator++(void)
  • container::operator[](int); size_t container::size() or typeof(container::operator[](int))::operator bool()

Depending on which of those I find, the foreach will be replaced with code to iterate each. The real trick is managing to proxy the "as" component in as a method of retrieving the element itself, and not the iterator type. Mind all of you, I'm not afraid to implement a macro if I must. But I imagine I can find a creative way to cram more instructions into the mix using operator, .


Anyway, I'll be busy. Thanks for your patience. I know this is taking a while, but the level of detail Ism and I've put into this goes far beyond the previous releases' quicker development time.

Peace.