ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

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: OpenAL + Linux
« on: October 04, 2009, 11:38:10 AM »
This isn't about me personally understanding templates, this is about me making my parser "understand" them. Just enough to where it can default the required template parameters to var.

Announcements / Re: OpenAL + Linux
« on: October 03, 2009, 07:36:08 PM »
I'm happy right now, with everything working. (Mostly)

Also, I want to have basic knowledge of templates for this really awesome reason I keep hinting at:
Code: [Select]
map a; a["power level"] = 9001.234;
map<int,int> b; b[1] = 2;

Keeping track of template parameters will let my parser know what to do with that. Also, it'll let me know if I can treat X member as int for a.b = c.

Announcements / OpenAL + Linux
« on: October 03, 2009, 10:16:59 AM »
= No.

My drivers suck. Tried to fix that with Retro, as well as my mouse problems... Long story short, I Just finished reinstalling the X server. <_<"

Anyway, my sound quality sucks so bad I can't test audio here. I'll do that on Windows, but it should still work in Linux for anyone whose drivers don't suck as bad as mine.

Other issue is template instantiation, which I'm going to have to do every time a template is used. (Because map<var,var> is different than map<int,int> in enough ways that I need to keep track separately).
Though, honestly, I can't really think of a good reason to keep track to the level of instantiating them, so maybe I'll drop the idea before it hurts something.

I have to attend some English garbage at some point, but for the most part, no more homework in there for a while. What I do need to do is draft a large economics paper, read some biology crap, and work on my psychology things. Hopefully those do not consume TOO Much time.

Templates are one of the few remaining obstacles. I'm going to run through the rest of the process to see when I would need to know anything but how many args are optional. It may turn out that I don't need to know anything else. If that's the case, it's solved. That leaves with(), switch(), and #include.

I'll keep you posted when each of those is cleared.

General ENIGMA / Re: Enigma IDE (written in C++ using wxWidgets)
« on: October 01, 2009, 07:51:47 PM »
Heh, I downloaded the source before I left for school a couple days ago, but it had dependencies you only pre-built for Windows, so I had to go before I could compile it. Haven't had enough time to partition off to doing so since (Am presently working on parser and biology homework, mostly the latter), but I'll have it compiled at some point. >_<"

General ENIGMA / Re: Enigma IDE (written in C++ using wxWidgets)
« on: September 22, 2009, 05:43:17 PM »

I could certainly use an additional team member. Heh, you're the first to put in a formal request to be one. But sure, I could use all the help I can get.

Right now I'm up to my eyeballs in homework. I have an essay to be writing for English that I've been putting off to work on ENIGMA. Hopefully my grade doesn't suffer for it. I should be working on that now.

I... have no formal process for adding someone to the team. I will certainly give your interface a look as soon as this essay is out of my face. (I'll want time to distract myself so I can proofread it after).

I should probably have edited this with my thoughts before you read it. In case not, though, letting you know I'll look at it ASAP.

Announcements / Re: I'm bookmarking this day
« on: September 20, 2009, 08:56:59 PM »
If it was just math and science, I'd do nothing outside of class. There are so many core requirements, it's not funny. Or fair.
Right now I'm finishing my psychology essay. I Just finished my Econ project, and made the cfile parser correctly handle typedef'ing new types. (as in typedef struct {...})

I may have to make a unique flag to tell if the type is a typedef, and then use the primary member, that way typedef will work with all the references.

That would mean that it'd use the only member in the type as the official one.
And recurse on more typedefs.

General ENIGMA / Re: Enigma IDE (written in C++ using wxWidgets)
« on: September 20, 2009, 08:53:44 PM »
X has nothing but a basic window, with flags if I recall correctly.

...It also had some terrible-ass keyboard event handling code. Ism did the windows, and looking at her code, it was a bitch. I did the keyboard, and lemme tell you. WAS. NOT. FUN.

Also if I recall correctly, Blender uses only the code necessary to make a window and a GL context, and the rest of their UI is custom-drawn. Probably took them a couple 9001 years.

General ENIGMA / Re: Enigma IDE (written in C++ using wxWidgets)
« on: September 19, 2009, 08:11:58 AM »
I gave the championship title for worst save/load dialog that will ever exist to Blender.
As long as it doesn't look like that, I'll greet whatever it is with a smile.

Mild inconvenience is one thing, but Blender's type-the-filename-yourself-and-don't-expect-to-be-in-the-same-directory-next-time-you-see-this-dialog interface kills me. And there's no navigation at all. It starts you in C:\Program Files\Blender\1000\different\folders\location of exe\ and then expects you to navigate to the folder you want from there. I resorted to copying and pasting the path to the folder I wanted in its open box.

Only then did I find out it stores a history for the dangerously observant.

Announcements / Re: I'm bookmarking this day
« on: September 19, 2009, 08:07:33 AM »
Too much debate, all the time ;_;

For those who are interested, I got a B on my first English paper. It makes me want to bite into something.

At any rate, parsers are still moving along in my free time, which isn't much, but now it's weekend, so I can conjure more.

Have a second English paper to write. Makes me want to smash something.

Announcements / Re: I'm bookmarking this day
« on: September 17, 2009, 02:58:41 PM »
I can see threading a pathfinding script, as long as you didn't constantly need the entire path.
If it was optimized for threading, especially. Optimized in the sense that it can put multiple pieces together, including fixing the beginning and end of the path where the points may have moved during processing.

With things like threading, you'll lose the general-purpose functionality you get from simpler scripting, but ideally with a great speed gain.

Announcements / Re: I'm bookmarking this day
« on: September 17, 2009, 09:13:31 AM »
1. A thread to do the drawing
  Why bother
2. A thread to handle the input
  Mark does that, you end up getting the mouse in eight different positions during a lagtastic step
3. A thread to perform AI
  Can't think of an instance that'd be useful, but that wouldn't be part of ENIGMA
4. A thread to handle the audio
  That's necessary, everyone does that
5. A thread to handle collisions
  That would be awful. Unless you had them split up across multiple cores, there'd be more harm than good to come from doing that. (Taking sync on all this into account)
6. A thread to handle GC(since it was in its own thread, GC would no longer be bad for game speed)
  GC? Garbage collection? This is C++. The only garbage collection I do is leftovers from instance_destroy(), and that causes next to no lag. But yeah, it wouldn't hurt, and that's probably the best use for threads here.

Announcements / Re: I'm bookmarking this day
« on: September 14, 2009, 08:51:03 PM »
Objects can potentially be moved to a separate thread by threading the instance handling code and treating it as a set of separate lists. Scripts can be threaded by turning them over to the kernel to run until they complete. It will be impossible to obtain a return value from a threaded script. (It would have to set a global variable when it is done.)

Functions would look like this:

The last function probably raised some O_o. It exists for efficiency, so that instance_exists won't waste time iterating an unused feature. Because of this, threaded instances would be essentially nonexistent. At best, they would exist when the function is called on their own thread. This function would deliberately iterate all threads.

Announcements / Re: I'm bookmarking this day
« on: September 14, 2009, 06:58:57 PM »
And waiting for the threads to catch up would often be disadvantageous. It would be a pain in the ass to synchronize the threads in the first place, but then you have the fact that people might not want it done so.

That being the case, I think the best way is to let the user do it with my surface method (Possibly double buffering them, as well. I could implement a specific function set for doing so.)

In fact... I could probably fully implement an automatic system that worked off of that surface idea. The draw event of threaded instances would be called while the target is set to a specific buffer for thread two.

Announcements / Re: I'm bookmarking this day
« on: September 13, 2009, 09:59:20 PM »
Think of it this way. If I let you multithread your object list, one object could be lagging like hell on one thread while the other worked fine. They're like mini-processes under one name. However. Synchronizing threads is a notorious bitch, except for some bloated Microsoft APIs, which I'm not touching anyway.

What that means:
Assuming I could make a separate function list on a new thread, in addition to some confusion with instance_exists (like an instance_sortof_exists()), I can't think of a way right now that objects from other threads could draw anything. (Aside from me calling it again in the first thread).

As retro said, you tell one thread to sleep, it's busy while it does. If that thread is sleeping or lagging, then, I'll have no way of telling it to draw. And frameskipping... probably doesn't work between threads. I have one GL context. So automatic threaded draw is out of the question.

HOWEVER. Once surfaces are figured out (as in, functional on more than 1 in 10 users' cards), I imagine the more... conceptually strong users could figure out how to use them to thread drawing. (IE, a thread2 object that draws global.second_thread_surface)

As far as multithreaded draw with depth... Right now, I'm really tired, so it might just be sleep talking, but I can't even think of a way to do depth between threads. Each thread would be its own "layer" as in GIMP and Photoshop, I imagine.

Another consideration would be threaded scripts. Those could easily work in the background, without much need for automatic sync.

Announcements / Re: I'm bookmarking this day
« on: September 13, 2009, 09:48:35 AM »
Was planning on having the ability to thread a script, and *possibly* move an instance to a new thread. There's no reason to multithread the compiler, that I can think of. GCC is the labor intensive one, and it is probably multithreaded.