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

1486
Function Peer Review / Re: move_towards_point
« on: January 11, 2011, 07:16:55 PM »
Actually, I have no idea why the fuck Ism's implementation works. direction.rval.d is in degrees. Or at least it's supposed to be. There is the possibility that it is only in degrees when it is the last variable set.

1487
I don't know why it's doing that if you're specifying the whole screen as the rectangle.

1488
I don't think two branches are unreasonable.

HaRRi, note two things. First, tbx and tby are both 1 for Po2 textures. Second, I believe the most efficient way to code this function is by giving it this structure:

Code: (C) [Select]
if (tbx == 1)
  if (tby == 1)
    //YOUR CURRENT METHOD
  else
    //DRAW LARGE TILED HORIZONTAL STRIPS OF SIZE REQUESTED_WIDTH * SPRITE_HEIGHT
else
  if (tby == 1)
    //DRAW LARGE TILED VERTICAL STRIPS OF SIZE SPRITE_WIDTH * REQUESTED_HEIGHT
  else
    //THE INEFFICIENT METHOD

1489
Proposals / Re: switch and mp_step functions.
« on: January 10, 2011, 07:27:41 PM »
You can just copy-paste it into "Definitions" under ENIGMA settings in the mean time, MrGriggs.

1490
You could just implement the 3D sound functions in ENIGMA's current OpenAL implementation; we'd appreciate it. (ENIGMAsystem/SHELL/Audio_Systems/OpenAL/)

1491
Proposals / Re: Shader effects
« on: January 10, 2011, 07:20:04 PM »
Yes, they will. I asked Retep a while back to research the difference in shader languages for DirectX and OPenGL. He never got back to me with the results. I want to ensure that ENIGMA's shader language is standard, and so I want to know what I'm up against. ENIGMA may implement its own shader language.

1492
General ENIGMA / Re: String Physics
« on: January 10, 2011, 06:39:32 AM »
HaRRi:
I didn't mean to imply that including a GL extensions library was all you had to do. You actually have to declare the function yourself and fetch a pointer to it.

Code: (C) [Select]
void glGenFramebuffersEXT(GLsizei n, GLuint* ids) { show_error("Surfaces not supported by card."); }
void (*glGenFramebuffersEXT)(GLsizei n, GLuint* ids) = &error_function_glsize_gluint;

//...

if (WHATEVER_YOURE_USING_SUPPORTS("GL_FRAMEBUFFER_EXT"))
    glGenFramebuffersEXT = WHATEVER_YOURE_USING_LOAD("GL_FRAMEBUFFER_EXT", "GL_GEN_FRAMEBUFFERS_EXT");

Or something like that.

1493
Proposals / Re: Object member functons
« on: January 09, 2011, 01:12:24 PM »
The stack is pushed twice at the beginning of the expression in my example, then popped twice right after.

pop_with(K) was what I was considering. But it wasn't until you posted it again that I realized I was thinking about it incorrectly. My first instinct was that there'd be no way to instantiate a template because the return type of func() can't be gathered from &func. But now I see that a simple template function would have done it.

Code: (C) [Select]
inline template<typename any> any& pop_with(any &r) { return r; }
So thank you, Luis; the simplicity of the matter escaped me.

1494
Proposals / Re: Object member functons
« on: January 09, 2011, 12:41:29 AM »
That's how with_iter works, luis. Issue is, you just passed func() the return value of enigma::pop_with().

1495
Proposals / Re: Object member functons
« on: January 08, 2011, 11:22:38 AM »
Unfortunately, r9k, it's not that simple. It's not as simple as polygone's suggestion, either.
The only way to implement this cleanly is too flawed to implement:
Code: (GML) [Select]
obj1.func()becomes
Code: (C) [Select]
(enigma::with_iter(obj1), func())When the expression starts, it will be as though it was executed for obj1. When the expression ends, the with_iter will destruct, and the code will be back in its original scope. However, this will fail catastrophically:
Code: (GML) [Select]
obj1.func(obj2.func())Both will be executed for obj2. This is because at the beginning of the expression, obj1 is pushed as the current instance, then obj2 is as well.

I haven't yet found a way around this.

1496
Proposals / Re: switch and mp_step functions.
« on: January 07, 2011, 02:38:48 PM »
Go for it. Feel free to do the A* shit, because I don't really want to. :P

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

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

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

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