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
Proposals / Re: switch and mp_step functions.
« on: January 06, 2011, 10:57:49 PM »
I hate implementing functions, anymore. I much prefer just working on parser candy.

The worst part about this is that I had a discussion about mp_linear_step with a buddy not long ago, and I showed how an implementation of the function that performed -better- than Game Maker's could be written without an A* implementation (if only because Mark's A* implementation is a world-class failure).

Someone made a path plotting example in GM that used four different implementations; I think it would be neat if ENIGMA offered each of them to choose from.

The example I'm thinking of colored in all the tiles to show how it calculated the optimal path with the selected algorithm. If anyone knows which one I'm talking about, I'd appreciate if they indicated it to me once more (having a GM-friendly implemetation of these for at least reference would be a good thing).

As for switch, I guess it's about time I implemented that. I might just check if all of the case labels are literals to choose between C switch and GML switch, and screw the hash implementation.

1502
Announcements / Re: Happenings
« on: January 05, 2011, 11:44:22 AM »
yum install cook

cd /usr/ports/sysutils/cook && make && make install

Don't forget the sudo.

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

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

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

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

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

1508
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;

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

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

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

1512
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

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

1514
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\

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