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

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.

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.

Announcements / Re: Happenings
« on: January 24, 2011, 05:34:15 pm »

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

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

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.

Announcements / Re: Happenings
« on: January 24, 2011, 03:45:16 pm »
As soon as people verify that this works for them:

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.

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.

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.

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.

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

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

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.

Announcements / Re: Happenings
« on: January 19, 2011, 10:59:23 am »
The DLLs are small; its the concept that irks me.

Announcements / Re: Happenings
« on: January 19, 2011, 09:41:43 am »
Since we don't force users to add anything to their path, GCC needs to be invoked with an understanding of where its precious DLLs are. This is the first MinGW release for which this is the case, because the MinGW team decided that DLLs really aren't so bad. So now even programs created with MinGW have dependencies on DLLs, and working around that is difficult.

Announcements / Re: Happenings
« on: January 19, 2011, 09:32:34 am »
I've fixed it, but now GCC misbehaves if it doesn't have the correct path.

Issues Help Desk / Re: Unit Formations In RTS
« on: January 18, 2011, 01:10:40 pm »
You mean, like an object index? :P
Anyway, the assign is where you'd want to use a switch(), not a for(). :P
And yes, I'm getting to it.

Issues Help Desk / Re: Combining members
« on: January 18, 2011, 10:31:58 am »
I'll have you know it's JoshmAvaland.

Announcements / Re: Happenings
« on: January 18, 2011, 09:10:56 am »
MrGriggs: I won't have access to them until later today.

HaRRiKiRi: I've deleted those files twice already. Someone keeps accidentally resurrecting them. I will delete them a third time, if it pleases the court.

MrGriggs: What is that?