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

Announcements / Re: Happenings
« on: January 28, 2011, 08:15:02 am »
Yeah, I still need to run that, but I'm afraid it'll gripe that it's not privileged. I'll add that now.

Proposals / Re: mask_index
« on: January 28, 2011, 12:54:53 am »
I only bothered to set it when Colligma was hooked up. It wouldn't have gone unnoticed for long if it was needed. And hell, Ism's capable of adding it, now. She's done so in the past.

Function Peer Review / Re: move_towards_point
« on: January 28, 2011, 12:54:16 am »
with (obj) direction=dir, speed=spd; isn't worth porting, considering the corresponding C++ is completely different.

Proposals / Re: Static object variables
« on: January 28, 2011, 12:52:43 am »
As it stands, ENIGMA uses . for all other access. A single dot will represent the correct choice of GM access (integer.variable), instance access (inst.member), or pointer access ((&inst)->member). I was considering having it resolve scopes as well, but it may require a special flag on results from the type resolver or before the call to it, depending on how I have it structured (An actual 'int' keyword should be distinguishable from an int variable).

Proposals / Re: Multiple Theads, are they a possibillity?
« on: January 28, 2011, 12:48:07 am »
What I was thinking about doing is adding threading by the same mechanism that I can add instance deactivation. Basically, I would keep a new tree and shit for each thread (deactivated instances get placed in thread -1, which is never processed).

Threading an object would be as simple as saying instance_thread(inst,thread).
Users would be allowed to figure out for themselves that sometimes life isn't as easy as putting everything in its own thread and hoping depth and shit stay in order.

Proposals / Re: unable to parse (obj.variable) = value;
« on: January 28, 2011, 12:44:45 am »
I was under the impression the syntax was strictly as follows:
Code: [Select]
(obj).variable = value;

If GM is suddenly allowing that sort of thing, I will remove all checks related to assignment operators. That will add compatibility with stream structures like cout, anyway.

Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 28, 2011, 12:41:44 am »
Someone verify that and then bug me or Ism about it.

Proposals / Re: do-until
« on: January 28, 2011, 12:41:01 am »
It should work.
#define until(x...) while(!(x)) is all I do.

I'll look into it all the same.

Edit: I don't see where you got that it doesn't work. If it gets past the syntax check (which it does) there's no reason for it not to work.

Off-Topic / Re: Automatic code formatting
« on: January 28, 2011, 12:36:15 am »
Select the code formatter from the Plugins menu.

Proposals / Re: Div operator on script return value
« on: January 28, 2011, 12:35:15 am »
I've been thinking how I wanted to deal with DIV, and I guess the best option is just to cast both sides, which is messy.

Announcements / Re: Happenings
« on: January 28, 2011, 12:27:04 am »
I'm not sure, Brett. Can you paste Compilers/Windows/gcc.ey? And the whole terminal output, that'd help. I need to know where Make is getting the mingw-g++.exe idea from. It should be able to find it, though, anyway... hmm...

Function Peer Review / Re: move_towards_point
« on: January 25, 2011, 08:41:43 am »
A motion_set that's five lines in GML isn't really worth porting. Those kinds of functions are more like blueprints or suggestions than code. It doesn't help me if you just take advantage of ENIGMA's scoping system to do things that are a pain in the ass in plain, general C++.

Though, with the new instance system, they're now much easier to produce.

Proposals / Re: Uninitialised variables
« on: January 25, 2011, 08:37:43 am »
Yes. I'm still deliberating on how to store object files for multiple settings. You're probably enjoying a two second compile time, yes? That will go up in smoke every time you switch to a GMK with different settings if I don't do something to store objects for each configuration.
It's definitely going to involve some Make and YAML hackery.

I guess, instead, I could do my best to keep setting-dependent code in separate functions or variables in a single source, then have the systems use those.... We'll see. This method would be less efficient, but it shouldn't be that noticeable, and when you went to compile the final product, we could pass the settings in as macros to the sources in question. Thus, we'd have something like this:

Code: (C++) [Select]
// For erroring on undefined vars
struct var
    bool initialized;
  variant &operator* ()
      if (!initialized) show_error("Variable not defined"); // I'll probably use some C++ trickery to resolve the name

// It will be the responsibility of IsmAvatar to ensure !(!OPT_UNIV_SHOW_ERRORS && OPT_UNIV_ERROR_UNDEFINED)
// But I'll probably double check it and not error

void show_error(...)
      if (MessageBox(enigma::hWnd, ...) == ID_ABORT)
      MessageBox(enigma::hWnd, ...);

Ideas and Design / Re: Extension API
« on: January 24, 2011, 09:33:31 pm »
Making it easy for users to distribute compiled extensions on a per-platform basis is easily in our power and will probably be implemented. It will not be compatible with GM. It's also not relevant to this topic. This thread is basically dead; I'm considering closing it in favor of the other topic, but I'm generally opposed to closing things, so.

Ideas and Design / Re: Rooms versus Panes (formerly Windows)
« on: January 24, 2011, 09:31:26 pm »