Tentative Todo

[Josh @ Dreamland]

This is what's going on and what will be going on before release.

Current Todo:

• Implement instance system (Currently working on)
• Implement new var (has already been coded)
• Resolve, once and for all, string() vs string, using a special property of macros. (#define string(x) toString(x))
• Make some changes to the parsers to accommodate some of these and more:
• Implement macros in the syntax check
• Implement C++ operators scope resolve :: and template parameter pass <...>
• Implement GML operators not equal <> , access . , and dynamic array subscript [...] .
• Run a check on subscript passes to global variables
• Finish implementing special treatment for variables declared as const.

What's just been done recently includes a fix on global declarations as well as testing of all drawing functions. Only draw_ellipse doesn't work, and I will fix that "soon."

[IsmAvatar]

That was the drawing function I used the most >_<

[Josh @ Dreamland]

it draws -something- of an ellipse. It's actually two parabolas stuck together, because serp doesn't believe in sqrt or trig.

[RetroX]

But a parabolic curve isn't the same as a circular curve. :/

[Josh @ Dreamland]

Painfully aware.
Serp recommends I rename it draw_serplipse().

[luiscubal]

draw_elipse isn't that hard. It's just cos and sin, multiplied by a number plus another number and drawed inside a loop. In OpenGL, at least, it is pretty easy.
Sure, this doesn't use precomputed trigonometry tables, etc. etc., but unless you need some terrific efficiency, this is pretty good.

[RetroX]

Also, as a completely random thought: the number of points on the circle should be settable in points per pixel, not 0-64.  Unless that's how it's already done.

[retep998]

Also, as a completely random thought: the number of points on the circle should be settable in points per pixel, not 0-64.  Unless that's how it's already done.

Remove the cap on 0-64 is a better idea but if you really want points per pixel...
number_of_sides = radius*points_per_pixel*2*pi;

[RetroX]

Also, as a completely random thought: the number of points on the circle should be settable in points per pixel, not 0-64.  Unless that's how it's already done.

Remove the cap on 0-64 is a better idea but if you really want points per pixel...
number_of_sides = radius*points_per_pixel*2*pi;

Yes but it's reliant on a function that I really don't want to mess with every time that I draw a circle/ellipse/roundrect.

[freezway]

so will speed/direction work?

[polygone]

What about the collision system?

[Josh @ Dreamland]

luis: We're going for terrific efficiency.
freezway: That's part of the new instance system, yes.
polygone: Luda doesn't seem to want to continue. I'll ask him about it again sooner or later.

[IsmAvatar]

And I'm guessing you still never got him to get it on an SVN of some sort? So for all you know, he could have been doing absolutely nothing, and just leading you on that he was making good progress?

[Josh @ Dreamland]

He never claimed that he was working on it the entire time nor that he was making good progress; just that at some point some progress was made. If he does it, it will be good, and I will use it. If he does not, I will try to run with his ideas that he forwarded to me; they were pretty good ones.

Aside from retep, who doesn't have experience in pixel perfect collisions, no one has volunteered to work on the system. I'm in no position to just start working on it; if he is going to finish it he'll have to do so before I finish that list above and do it myself.

[retep998]

I volunteer to code anything which doesn't involve working with assembly, java, or pre-existing code.