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

1456
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.

1457
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.

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

1459
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.

1460
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...

1461
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.

1462
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
{
...
  #if !defined OPT_UNIV_ERROR_UNDEFINED || OPT_UNIV_ERROR_UNDEFINED
    bool initialized;
  #endif
...
  variant &operator* ()
  ...
    #if !defined OPT_UNIV_ERROR_UNDEFINED || OPT_UNIV_ERROR_UNDEFINED
      if (!initialized) show_error("Variable not defined"); // I'll probably use some C++ trickery to resolve the name
    #endif
...
  var():
  #if !defined OPT_UNIV_ERROR_UNDEFINED || OPT_UNIV_ERROR_UNDEFINED
   initialized(false),
  #endif
...

// 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 !defined OPT_UNIV_SHOW_ERRORS || OPT_UNIV_SHOW_ERRORS
    #if !defined OPT_UNIV_ERROR_FATAL || !OPT_UNIV_ERROR_FATAL
      if (MessageBox(enigma::hWnd, ...) == ID_ABORT)
        exit(0);
    #else
      MessageBox(enigma::hWnd, ...);
      exit(0);
    #endif
  #endif
}

1463
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.

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

1465
Proposals / Re: Applications
« on: January 24, 2011, 09:30:28 PM »
ENIGMA will offer a widget library. I've already developed it in GTK, But it's not done in WinAPI yet. It'll make the simplest of current widget libraries look like nuclear engineering.

1466
Announcements / Re: Happenings
« on: January 24, 2011, 08:14:23 PM »
Yeah, mostly CPU. Memory's cheap, they say, and the GCC uses a shitload compared to the sleekest around (Clang, however incomplete). But yes, I notice a huge jump from single core to even just dual core. I don't notice much difference between dual and quad, though, so. I think there's an option for number of CPUs to use in the GCC, but I don't make use of it.

1467
Announcements / Re: Happenings
« on: January 24, 2011, 05:34:15 PM »
http://dl.dropbox.com/u/1052740/ENIGMA-R4-r617.zip
http://dl.dropbox.com/u/1052740/ENIGMA-R4-r618.zip

Use the trunk until official release. Though we are pushing to stable now.

1468
Announcements / Re: Happenings
« on: January 24, 2011, 04:39:19 PM »
Game_boy: Running from ENIGMA.exe? It's an installer.

1469
Ideas and Design / Re: Rooms versus Panes (formerly Windows)
« on: January 24, 2011, 03:59:01 PM »
Okay. I think the best solution to this is to give added resources a render() method for addition into the room editor and a get_selector() family of methods to create and handle a combo box chooser. (And an is_instantiable() method for if it can be placed in the room at all).

By this method, Panes could have their own editor with some pane-specific functionality, and rooms could just instantiate them.

1470
Announcements / Re: Happenings
« on: January 24, 2011, 03:45:16 PM »
As soon as people verify that this works for them:
http://dl.dropbox.com/u/1052740/ENIGMA-R4-r615.zip

If that works, I will add a call to the AL installer to ENIGMA.exe and link to the front page. Positive reviews there will lead to a formal release.