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

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

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

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

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

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

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

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

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

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

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

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

1468
Ideas and Design / Re: Extension API
« on: January 23, 2011, 06:22:24 PM »
He's proposing a solution to an issue from another thread, being allowing adding resources to LGM. Simple extensions or static parts of extensions could potentially be released as object files on a per-platform basis. That said, this system would be for users who are wise enough to stay open source. Hence, I doubt that this will be requested, but I don't mind allowing for it.

I can see how this would allow adding resources, but not how it would allow modifying existing ones. I'd like Ism's opinion on it.

1469
Ideas and Design / Re: Rooms versus Windows
« on: January 22, 2011, 12:25:33 PM »
I began development on an extension system a while back, with the intention of making paths, alarms, and local groups such as lives/health/score, extensions. Windows sound too fundamental to make into an extension; they're better suited to being part of the room editor.

Maybe if Ism could get the room editor to iterate a list of objects containing methods to manage and draw each component of the room... But then, how would the extension describe that it is a separate context into which instances can be placed? The room editor would have to have some understanding of a context anyway, which it would not gain from views (views are drawn as outlines in the room editor; instances can't be placed in them).

I mean, it's perfectly possible, I just personally think the solution is kind of ugly. The first method that comes to mind is to add a callback for every function of the room editor. The window extension would establish a callback for when an instance is placed in the room, when the room is being rendered, when the room is being loaded, and when it's being saved. If Ism thinks such a system would be acceptable, I'd be happy to write the back end to it.

1470
Ideas and Design / Re: Rooms versus Windows
« on: January 21, 2011, 08:55:38 PM »
It isn't entirely unrelated. You presented a system in which keyboard events can be withheld depending on which context ("window") an object is in. Fede brought up a conflict.

Quote
Windows(along with focus) solve this problem by ensuring only the focused window receives keyboard events
Quote
What about keyboard_check_direct()?

The answer, of course, is that keyboard_check_direct would transcend this 'window' concept.

Quote
Surely, Windows can be implemented using Rooms and Objects. But... what about doing things the other way around? Like implementing views using windows.

Your 'window' system is more convenient than rooms, views, and objects. Views can not be done with windows, unless multiple windows can be in focus at once.

Anyway, I like the idea, and I see it as being easily feasible. I'll talk to Ism about it and we'll decide on an interface. Suggestions welcome.