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

1546
Function Peer Review / Re: NEEDED FUNCTION LIST
« on: December 07, 2010, 03:22:17 PM »
Let me reiterate (again) that I have no idea why those damn GM*.h headers are still in there. I wrote most of them when I was fourteen. It's time to remove them.

I deleted them years ago and they have since magically resurfaced (Thank you subversion). And as you can see, they're spawning now, and it's kind of obnoxious.

1547
General ENIGMA / Re: variable_* Functions
« on: December 06, 2010, 10:05:13 PM »
...

1548
Proposals / Re: Code Formatting
« on: December 06, 2010, 09:14:13 AM »
Wow, I actually had -not- considered that, polygone. I'll add that to my growing list of ways to boost ENIGMA's notoriety.

1549
General ENIGMA / Re: variable_* Functions
« on: December 05, 2010, 10:03:03 PM »
There's no way to implement them... efficiently. Doing so requires two modifications. They're difficult to make, but only because it pains me to do so. Each variant needs a bool to indicate whether it's been assigned, then each operator needs overloaded to a hash table needs constructed in each instance for new variables added, and a table needs constructed for each object to reference hard-compiled variables.

Honestly, I hardly intend on doing it. But I'm sure someone will cry about it at some point and I'll implement it.

1550
HaRRi, I think if you're going to offer an AA function, it may as well be for all primitives. Let the user make the call to it before and after spline drawing, if they like.

Luis, using a list would increase RAM. It would save push_back for the duration of one frame, then one subtract each frame, but at the cost of another add-dereference from there on. It doesn't really seem worth it...

1551
Yes, overwriting vectors. No, vectors are slow at push_back(). push_back is best case O(1), worst case O(N), and I'd wager the worst case happens the most often. Accessing [] with vectors is O(1). [] just looks up a number, push_back allocates more memory, which often means moving the memory it has. Using push_back for every point every step could mean N^2/2 operations (where N is the number of points) (but I doubt it). Only using push_back when necessary means one frame of N^2/2 disaster case, then the rest are N.

And yes, it's exactly one instruction faster not to return zero. Which could be as much as 20% in the case of draw_primitive_begin(). But that's a really small time, anyway; I'm not too worried. Returning void could mean a compile error if someone tried to assign the return value to a function. (Perhaps I should add checking for that...)

1552
Issues Help Desk / Re: Can't draw anything inside _begin _end
« on: December 04, 2010, 04:56:21 AM »
Well, since the draw event only clears it every time, you'd still have to keep your own array.
The speed will actually decrease from keeping your own array. It is much more efficient to outsource point management to the GPU. Not to mention the number of function calls doubles by this method. At it's simplest, now we're keeping a nonstatic array, and the GPU is keeping a static one. The difference in the long run, though, is negligible; most of the work here is probably in drawing the primitive.
But yes, I see how drawing a circle around each vertex could be useful, so if you have not, I will probably preprocess the current primitive functions manually and rename them to draw_begin, draw_vertex2d() and draw_end(). Then our Game Maker equivalents can do their craziness.

Issue is, now I have to store texture and color data in the array, too.

1553
The unofficial GM spec says all functions have a return value. I haven't completely decided to stray from that, though I myself tend to use void.

1554
Please make that vector static. You can remove points with vector::clear(). If you don't use a stack, you can't have nested splines (earlier you complained about a lack of nested primitives).

The hope is that the point you declare in the function is never instantiated; that instead, the optimizer makes it so the point is written directly on the space allocated by vector<>.

Instead of clearing it, it would be more efficient (speed wise, not memory wise) to keep your own static index, and only push back if index >= vector::size(). That way, you can just reset the index when begin() is called, and the system doesn't need to waste time on allocation otherwise (especially for repetitive spline drawing).

1555
Done. And that's probably a good idea until you get the hang of ENIGMA.
I trust you'll commit your merge_color fix, too?

Also, we do have an IRC for this quick back-and-forth sort of thing.

1556
Which is why I added you. You understand the implications of committing code; you'll be careful. Adding a couple files typically won't break anything. Just don't forget to commit any files you include. If you keep posting about them here, we can look over it and either have you make changes or implement them ourselves. Ultimately, collaboration should pay off in the end.

You're not Harold.Z on SourceForge?

1557
They look nice, HaRRi. I'd recommend keeping your own array, though. Here is my suggestion:
Code: (C) [Select]
#include <stack>
#include <vector>
struct splinePoint { float x,y; };
typedef std::vector<splinePoint> a_spline;
static std::vector<a_spline*> startedSplines;

void draw_spline_begin() { startedSplines.push(new a_spline); }
void draw_spline_vertex(float x, float y) { startedSplines.top()->push_back(splinePoint(x,y)); }
void draw_spline_end() {
  a_spline &arr = *startedSplines.top();
  for (int i = 0; i < arr.size(); i++)
    draw_spline_part( /* I Have no idea of the use case of this function.
      Access points with arr[num]. Do bounds checking. It may be frugal
      to unroll the first and last four elements; remember, the array can
      contain as few as zero points! */
);
  delete &arr;
  startedSplines.pop();
}

Don't implement any PEBKAC checking until ENIGMA has a centralized error system.

When you're done, feel free to commit your code using your SourceForge details.
...Welcome aboard.

1558
Announcements / Re: Scalability
« on: December 02, 2010, 10:33:17 AM »
I started adding some of the file functions to one of those pages, so I don't see why not.

1559
Issues Help Desk / Re: Can't draw anything inside _begin _end
« on: December 01, 2010, 01:57:19 PM »
Essentially. It would require a less-than check every primitive, which is what I consider to be a waste of time. I may offer a second set of primitive functions that have no such time consumers (and smaller names. I'm thinking just draw_begin(), draw_end()).

1560
Issues Help Desk / Re: Can't draw anything inside _begin _end
« on: November 30, 2010, 05:37:12 PM »
Indeed, I chose not to use a custom vertex buffer to render primitives, and nested glBegin()s are invalid. I am unsure why you would be drawing a circle inside your primitive calls in the first place, but if you can make a case for it I'd be happy to use a dynamic array for a custom VBO (another 1980 GL spec that Intel refuses to support).

merge_color worked at one point, but serp found a more efficient way. He just never tests his efficient ways thoroughly. Notice the tabs everywhere. Not my trademark...