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

1501
Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 05, 2011, 09:37:34 am »
Assuming you calculated the normal and took (distance-used_distance)*sin(dirdif(normal,dir)), then performed the second iteration perpendicular to that normal, it' work fine. Until, of course, you want us to check a third corner and so on. Then our algorithm becomes O(ND) as we have to keep iterating so long as there is yet any distance left to be iterated, not to mention it wouldn't look quite how the user would envision it in his ideal dream world. To get it to keep navigating around objects nicely, we would have to make our recursive calls to the function use no more of our remaining distance than it takes to move, in your drawing, inst1->bbox_left past inst2->bbox_right. Fortunately, with bboxes, all of this is insanely easy to calculate. Polygons and 3D meshes will not make this task quite so easy, and though it's well within the realm of possibility, my fear is, as always, efficiency.

The method may require a different subroutine to call that behaves like move_contact() but returns the distance it was able to travel before collision. That returned distance would then be subtracted from our remaining distance (we'd min() the distance required against the distance remaining before we ever invoked the subroutine to ensure this value will keep our remainder >= 0), and then the current function would be re-invoked.

It'd probably be useful and save memory to just return the distance traveled in the original move_contact. It's not like it won't already be in a register; returning it would probably just tell the compiler to keep it in eax.

1502
Announcements / Re: Happenings
« on: January 05, 2011, 09:19:30 am »
apt-get install "cook"

1503
Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 04, 2011, 08:01:45 pm »
Oh, does it do so in GM? That would mean a change in algorithm (this one stops as soon as it hits a wall).

1504
Announcements / Re: Happenings
« on: January 04, 2011, 02:46:56 pm »
Yeah, that should never happen.

Yes, but the makefile needs updated. Ism updated it for you last time by running automake_all.sh from SHELL/.
You can update it manually, if you wish, or find a competent shell to update it for you. (Or commit and ask Ism to do so again, or I can).

I forget why I couldn't do fonts, be it compression or otherwise. We'll see about those...

1505
Announcements / Happenings
« on: January 03, 2011, 07:42:06 pm »
So after four people in less than a month struggled to install ENIGMA, I've finally begun redoing ENIGMA.exe. It will automatically call mingw-get to install necessary files; the user needs only to specify a drive letter (if he or she is dissatisfied with the default, being the current drive). I was actually looking for a function to prompt for drive letter, but couldn't find one and so abandoned the notion.

In other news, Gary has added unix names to all user accounts. As new users sign up, they will be given a unix name (or can edit it themselves). This name will be used in the Wiki shortly enough, and for user upload directories and whatnot later on.

In what may be old news, ENIGMA is only three functionalities away from being able to run the official GM platform example perfectly. The three include instance_deactivate() and co, dialog functions (for showing and logging high scores), and tiles. We'll see about those three ASAP. (But after the Windows installer).

With any luck, the provisions I am implementing in the Windows installer (new organization system for compilers and makefiles) will mean, once and for all, simplicity of adding devices for which ENIGMA can officially compile. Also with this addition will come the ability to use ENIGMA portably if configured on a USB drive.

Wish us luck.

1506
Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 03, 2011, 12:22:31 pm »
>You can't easily check for 'solid objects that collide with box from the two furthest points' when only using one reference point on the bbox.

Yes, you can. That's why I broke it into quadrants. I didn't have time to sketch up my idea yesterday (or even to draft it fully), but today, I do.

http://dl.dropbox.com/u/1052740/MoveBboxSolid.png

Code: (C) [Select]
case 0: // Quadrant 0; horizontal up to nearly vertical
  const int dx = inst2->bbox_left - inst->bbox_right, dy = inst2->bbox_bottom - inst->bbox_top; // Get horizontal distance
  const int tdt = (dx > dy)?  dx/cos(dir) : dy*sin(dir);
  if (tdt < td and /*a rectangle that is our translated rectangle with a 1px border collides with our inst2->bbox*/ true)
    td = tdt;

1507
Function Peer Review / Re: move_contact functions optimised for bbox
« on: January 02, 2011, 11:59:33 pm »
A for loop is unnecessary with bboxes.
1) Calculate furthest bbox point when translated from the untranslated position.
i.     If your bottom-left corner is at (0,0) and you are 32x32 pixels, and you are checking 10px at 45 degrees, the coordinate you want is 10*cos(45 deg) + 32, 10*sin(45 deg) + 32
2) Loop, looking for solid objects that collide with box from the two furthest points ((0,0) and (10*cos(45 deg) + 32, 10*sin(45 deg) + 32) in our example)
3) Check untranslated rectangle for collisions; if you're colliding with it initially, we obviously can't move any closer, so break.ass
4) Switch the quadrant of our angle (wrap(angle,360) / 90). This code assumes inst is the current instance and inst1 is the instance we're looping through. Neither are translated from their original position. It assumes a variable representing total displacement, dt. distSquared is parameter dist * parameter dist.
Code: (C) [Select]
case 0: // Quadrant 0; horizontal up to nearly vertical
  const int dx = inst2->bbox_left - inst->bbox_right; // Get horizontal distance
  const int tdt = (dx >= 0)?dx/cos(45) : (inst2->bbox_bottom - inst->bbox_top)*sin(45);
  if (tdt < td)
    td = tdt;

I lack time to do the other three quadrants. You can do them and debug, or I will later. Peace.

1508
Function Peer Review / Re: file_delete
« on: December 30, 2010, 09:11:10 pm »
It's implemented somewhere. It probably hasn't been included because its set isn't complete.

Most GM functions are easy to implement.

1509
Issues Help Desk / Re: Segfalt with enigma compiler
« on: December 30, 2010, 03:33:51 pm »
The hard part is actually doing anything with JEdit. I've been thinking a compatibility tool for GM users would be desirable.

The real struggle is getting people to be aware of the components of ENIGMA that GM simply doesn't offer. They'll have to ease into it, which means lots of compatibility settings. It wouldn't be wise to just replace all comparison = with == upon loading a GM6, because users wouldn't learn anything (they'd still use =, then file a bug report when it failed).

Right now the idea is to have two settings panes saved; one for creating EGM files, another for loading/creating GM6 files. That, however, requires collaboration between ism and myself, so...

1510
Issues Help Desk / Re: Segfalt with enigma compiler
« on: December 29, 2010, 01:39:13 pm »
Now if only the type coercer were so competent. That's what I get for adopting an even remotely standard method.

...:P

1511
Issues Help Desk / Re: Segfalt with enigma compiler
« on: December 29, 2010, 11:05:50 am »
I just fixed that segfault a bit ago, but haven't yet committed it due to an issue that came with it.
I'd appreciate it if you linked to them with their description (should the top 10 change).

1512
Proposals / Re: Additions to new platform system
« on: December 28, 2010, 11:28:14 pm »
C:\MinGW\bin\
/usr/bin/
fuk:i:r:apple:xcode:fuck:stuffthatsworthitssize:stuffwestolefromgnu:bin
C:\DevKitPRO\DevKitPPC\bin\

1513
Proposals / Re: Additions to new platform system
« on: December 27, 2010, 03:56:54 pm »
TGMG:
Please extend this: http://enigma-dev.org/docs/wiki/index.php?title=Compilers/
And this: http://enigma-dev.org/docs/wiki/index.php?title=Module_hierarchy

I'm not opposed to having a Makefiles/ folder of the same design under SHELL/.

1514
Function Peer Review / Re: distance_to_object
« on: December 26, 2010, 06:16:01 pm »
Not to mention, enigma::fetch_inst_iter_by_int(object) is literally as efficient as can be. It is, in fact, the function that composes with(). It is set up such that there is no way to make it any faster; the iterator it returns accounts for all aspects of instance iteration, including ID, object index with heredity, and keywords such as all, other, or noone.

1515
Proposals / Re: Introduction / Profile Forum?
« on: December 26, 2010, 11:03:23 am »
Oh, haha. I thought you were talking about docs in general. I saw something about replies being useful, and figured you were thinking that discussion on a particular piece of ENIGMA would promote understanding for future readers.

Anyway, what you're describing is what SourceForge has. A competency level for each language. We could tailor it to ENIGMA, giving a competency level for each system or function set, I suppose. And by "we," I mean someone who isn't me. I despise PHP.