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

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

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

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

2539
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:
script_start_thread(script)
thread_create()
instance_set_thread(inst,thread)
thread_destroy(thread)
instance_exists_thread(object,thread)
instance_exists_allthreads(object)

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.

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

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

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

2543
General ENIGMA / Re: Enigma IDE (written in C++ using wxWidgets)
« on: September 12, 2009, 09:45:42 pm »
That's not saying much.

2544
General ENIGMA / Re: Enigma IDE (written in C++ using wxWidgets)
« on: September 12, 2009, 09:26:22 pm »
Sounds good, antidote. R4 should be out before then.
a2h-- Why just on Windows?

<_< Retro stole my thunder

2545
Announcements / Re: Greetings from LInux
« on: September 12, 2009, 04:56:06 pm »
Ubuntu has one hourly <_<"
Unlike Windows, though, Ubuntu's don't require restart, save three times.

2546
Announcements / Re: I'm bookmarking this day
« on: September 11, 2009, 02:19:59 pm »
I'm unsure of timeframe once more, now that 9's have evaded me.
This is what would be in a semi-quick R4. For ASAP, remove anything that isn't already being implemented.

Certainly not 3D, or full enough Wii integration to use. Almost certainly not paths. Possibly not sounds, but those are second priority only to backgrounds. It is unlikely that I won't add backgrounds. Tiles, on the other hand, we will see. (It's a matter of time, not ease or capability. Some things will be saved for after there's a working updater and things have settled).

Maybe not Ism's almost-mplay. Not sure on that one.

No interpreter, sorry. I'll see about debug mode as I work with the compiler.

New instance system... I might put it on hold if everything works perfectly, in fear of messing it up again.

DLLs are in, though. Expect them. (Windows only, of course, unless someone has a brilliant plan for working with them on Linux somehow. I've not looked into the matter at all, and although I don't personally think I can run a Windows DLL on Linux, I've heard rumor from someone that there's some way.)

No extensions. But I won't say never.

Limited DnD. (Only the most basic of action_whatever() will be defined at this point, but code flow should work as you are used to)

2547
Announcements / Re: I'm bookmarking this day
« on: September 10, 2009, 07:35:44 pm »
That'd be easy as pie.
Like I was saying yesterday, and as the above demonstrates, the CFile parser is REALLY close to completion. Right now I'm working on parameter declarations, as those require a syntax exception I'm not fond of making. After that, I just have to tell it to recognize the template keyword, which is easy, The template system's already integrated, anyway, just needs the initializer and any debugging that hopefully won't follow.

Then I need to make sure the formatter parser knows what to do with the feedback, and same with syntax checker.

Then I'll make sure it can still compile a game...
Then I'm done...

Perhaps we need some semi-public pre-release testing. I'm thinking it'll just be for forum frequent-fliers, meaning don't tell anyone. I'll start advertising after things work, and a couple things I'm itching to do are finished.

2548
Announcements / I'm bookmarking this day
« on: September 09, 2009, 10:58:18 pm »
I called it fair and square.

Today consisted mostly of school and battling code. But I had fun, and made another awesome dent, at least.

Code: [Select]
Macros:
a:   Serves as typename : struct
{
  b:   Serves as typename : struct
  {
    member1:  int 
    member2:  int 
  };

  itsanintyoubastard:  int 
  nested_struct_instance:  b 
};

auto:   Serves as typename
bool:   Serves as typename
char:   Serves as typename
socks:  int 
colligma:   namespace
{
  a:  int 
  b:  float 
  c:  double 
  d:  somethin 
  e:  somethin 
  f:  char 
  g:  int  Dereference path: (params = 0)</group>
  h:  int  Dereference path: </group>[]*</group>
  somethin:   Serves as typename : struct
  {
    d:  int 
  };

};

const:   Serves as typename
double:   Serves as typename
effing_a:  a 
float:   Serves as typename
int:   Serves as typename
lime:   Serves as typename : struct
{
  candy:  bool 
  disease:  int 
};

long:   Serves as typename
register:   Serves as typename
short:   Serves as typename
signed:   Serves as typename
some_big_ass_function:  int  Dereference path: (params = 0)</group>
static:   Serves as typename
tt1:   Serves as typename : struct
{
  tt2:   Serves as typename : struct
  {
    tt3:   Serves as typename : struct
    {
      a:  int 
    };

    tt3i:  tt3 
  };

  tt2i:  tt2 
};

tt1i:  tt1 
unsigned:   Serves as typename
volatile:   Serves as typename

That was generated from this code:

Code: [Select]
struct a

{

  int itsanintyoubastard;

  struct b

  {

    int member1, member2;

  } nested_struct_instance;

} effing_a;



namespace colligma

{

  int a;

  float b;

  double c;

 

  struct somethin

  {

    int d;

  } d;

  somethin e;

 

  const mutable char f;

 
  long unsigned int (h)*[2];
 

  int g()

  {

    heh; this does nothing;;;;;;

  }

}

int some_big_ass_function()
{
  some code
}

int socks;

struct tt1
{
  struct tt2
  {
    struct tt3
    {
      int a;
    } tt3i;
  } tt2i;
} tt1i;

struct lime
{
  int disease;
  bool candy;
 
  int operator + ();
};

Pretty awesome. Almost awesome enough to cut it.
Rusky will be amused to know I just moved a 500 line if statement to its own source file. Hahahahahaha. That thing was getting in MY way. Will probably move more.

Things you may have noticed: Supports nested bloody everything. Reports types. Reports references (including functions) in some stack for reverse-iteration. Ignores code.  Clunks out at operator+ because it's skipping another huge-ass if statement I just moved. End of list.

It's damn late, and I'm tired. I'll be up at six tomorrow, so. Just bookmarking this day; it's still mine.
(I'll prolly shoot for some [nearly] equally monumental day coming up, which I will justify with some line of BS.)

Ism is working on an SVN-based updater. This is after we fixed her computer, which is also on Ubuntu, that decided to take a dump and lose her partition table. Through some googling we managed to get it working again from a LiveCD.

Would have made an awesome fish tale if we'd still had time to finish. Nyet...

And night.

2549
Announcements / Re: Greetings from LInux
« on: September 09, 2009, 03:24:25 pm »
Basically.

I had OS X working for a glorious twelve minutes with 100 byte/second internet and basically zero applications. Didn't get as far as installing their 400GB "development basics" package before it all died, though.

(400GB is a slight exaggeration, 100b/s is not)

2550
Announcements / Re: Welcome to the new server!
« on: September 09, 2009, 03:18:37 pm »
Updates will probably be largely bug fixes, though. Meaning that it'll be known that the changes work, the rest is what's left to figure out.
But yes, it helps to know what's changed beyond the filename.