ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

Pages: 1 2 »
  Print  
Author Topic: Critical Change, Function Renaming  (Read 4277 times)
Offline (Male) Goombert
Posted on: May 05, 2013, 05:53:09 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2993

View Profile
I just want to discuss also that it is my intention once we have obtained GameMaker's entire userbase, to rename several functions.

For instance, d3d_model_create, would be just model_create, d3d_draw_model, would be model_draw(). The reason for this? Game Maker used to be only Direct3D, but now has OpenGL for its cross platform works, as does ENIGMA, so the whole d3d_* prefix is misleading and 4 extra characters you have to type. All the transform functions will lose d3d_* completely because they also work for 2D.

I just want to know what everybody thinks about it, if you would generally be opposed to it or what. Also I want to know would you rather it be an all at once thing, or groups of functions renamed in each monthly update until the entirety is renamed over the course of about a year. Thoughts guys?
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Male) Josh @ Dreamland
Reply #1 Posted on: May 06, 2013, 12:39:04 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2951

View Profile Email
By convention, functions meant to be used exclusively in 3D are given the d3d_ prefix. Some of those functions are still applicable for drawing in 2D, such as d3d_transform_*, but there is no reason to lose it for the model functions. I am fine with draw_ being the dimensionality-agnostic drawing namespace, d3d_ (shorthand for draw_3d_) being the 3D drawing namespace, and d2d_ being the 2D drawing namespace, in case someone wants to add wrappers for d2d_model, or whatever.

It might be wise to make certain that for all possible graphics systems, 2D and 3D drawing will both utilize transformation matrices that the user can easily manipulate.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Goombert
Reply #2 Posted on: May 06, 2013, 01:06:42 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2993

View Profile
No no no no no, when we do this I want d3d_* dropped from models completely, because we will also have 2D polygons poly_create(); poly_vertex(); poly_draw(); etc or we could name em shape or whatever so that their is a way of buffering 2D vector graphics as well we can also combine this with SVG support Josh. That alone gives the ambiguation of models being purely 3D, and Id rather they just be model_create(); and model_draw(); anything else is redundant. Transform functions should come all the way down from d3d_transform_set_identity(); to trans_set_identity();, even that aint necessary really, there is no need to set the identity when you just ambiguate the transformation functions to be taking place ONLY on SUBSEQUENT draw calls, for instance it could just be rotate(); or translate(); or scale(); or draw_rotate(); draw_translate(); draw_scale(); etc

Especially all the data structure functions, ds_grid_create(); could be just grid_create(); because they are just built off of standard C++ lists, queue's, maps, etc
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #3 Posted on: May 06, 2013, 05:32:33 AM

Developer
Joined: Apr 2008
Posts: 1860

View Profile
For compatibility you will have to have both for very long time as well. And I don't really think it matters that much. d3d_model's also work in 2D in GM, just like transform functions.

Quote
ONLY on SUBSEQUENT draw calls
Isn't this how its always been? You "can't change the past", so of course the transform only works for subsequent draw calls. But identity() is still needed, because I sometimes rotate or scale the whole world while still adding transformation to individual objects.
Logged
Offline (Male) Goombert
Reply #4 Posted on: May 06, 2013, 06:48:57 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2993

View Profile
Ohhh I see, I didnt think of that Deus, but yes I understand it will have to be long after YYG goes bankrupt, but nonetheless we still need to rewrite our transformation code into shaders. :P

But as far as the models go, they would need to be their own extra set of functions, because otherwise you have to pack an extra z value as 0 into every vertex buffer of a model. We already have 2D draw_primitive_begin() or whatever for 2D shapes, so it would just be Models & Shapes (or polygons, whatever you wan call em)

When I get back around to graphics systems, I am also adding some camera functions so you can instantiate a projection and you dont have to set ALL of its properties each time, eg aspect ratio and camera angle only need set once, and I am going to add functions to easily rotate the camera so you don't have to do the hard math each time :)
« Last Edit: May 06, 2013, 06:51:42 AM by Robert B Colton » Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Male) Josh @ Dreamland
Reply #5 Posted on: May 07, 2013, 10:55:39 AM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2951

View Profile Email
if you think that 3D models should be used in 2D, then I suppose we can define draw_model_* to d3d_model_*. I am completely opposed to model_ as a namespace, or poly_ as a namespace. draw_polygon* or d2d_polygon*. The drawing functions are presently divided into two namespaces, draw_ and d3d_. As I said, I'm not opposed to a d2d_, but aside from that, stick to draw_ or d3d_.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Goombert
Reply #6 Posted on: May 07, 2013, 11:25:13 AM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2993

View Profile
No you misunderstood Josh, models are ambiguated as 3D and polygons/shapes as 2D. poly_create(); poly_draw(); model_create(); model_draw();

But you misunderstand, I don't intend of any of this until after YYG is out of the way, it would have to be. But no d3d and d2d is a very bad connotation. Just model_* is all you should need to type not d3d_model_*, thats unbeliably redundant.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Female) IsmAvatar
Reply #7 Posted on: May 07, 2013, 03:16:07 PM

LateralGM Developer
LGM Developer
Location: Pennsylvania/USA
Joined: Apr 2008
Posts: 877

View Profile Email
Especially considering the first D in D3d refers to "Direct" from Windows. Much like how mplay refers to the deprecated Direct Mplay, so I broke off in naming convention for my networking functions and opted for the net_ namespace (I think).
Logged
Offline (Male) Josh @ Dreamland
Reply #8 Posted on: May 07, 2013, 04:37:30 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2951

View Profile Email
I think net_ is a suitable namespace. I also think draw3d_ is a little verbose, so d3d_ makes a suitable replacement. As far as I'm concerned, model_ is not an acceptable namespace, and neither is poly_. When people want to explore their draw options, they will type draw_ and hit control-space. Your polygon functions won't show up.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Goombert
Reply #9 Posted on: May 07, 2013, 07:51:35 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2993

View Profile
See Josh your argument is a double edged sword. Think about this, a simple person would automatically connect the function name to the model_* namespace, that is kind of a given, but you see d3d_* is not, and it would in fact require people to go searching, where as with model_draw(); it is so much easier to guess it just makes sense.

Like I also stated in the IRC, models don't have to have texture data, they can just be a vector representation of an object. And in fact physics engines like Newton, Bullet allow you to use models to represent a collision body. Now take box2D as well, an SVG vector graphic for instance could define a shape but it is intended for graphics, GM:S added a polygon editor, so yes we do need poly_* functions, but anyway a model used with newton for instance might just have nothing to do with graphics at all, and thus why I am against the ambiguation.

And Ism makes a very compelling argument, it is all just very verbose.
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Male) Josh @ Dreamland
Reply #10 Posted on: May 07, 2013, 09:01:30 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2951

View Profile Email
I had stated my intention to re-think the "D" in "D3d" to stand for "Draw" rather than "Direct." This makes sense, anyway, because you can't name the functions 3d_, and draw3d_/draw_3d_ is too much typing. draw_polygon_ is pretty bad in that department, but at least it's easy to find. No one would think to type polygon_ when looking to draw a polygon. It's great that you believe other systems will be able to use the same polygon objects as the graphics systems. What do you suppose those functions will be called? polygon_use_with_newton()? polygon_set_as_mask_for_object()? No, you're probably thinking along the lines of physics_mask_from_polygon(). Not to imply that any of the names would be that long; those were just examples. Similarly, users would call draw_polygon() if they intended to draw a polygon, just as they call draw_sprite() or  draw_background() to draw a sprite or background, respectively. Now, assuming polygons are a resource, I am unopposed to placing manipulation functions in a polygon_ namespace, so long as the documentation for the functions in the other namespaces are clear on the need for those functions. I am talking, of course, of  polygon_create(), like  sprite_create_from_screen(), etc.
Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Goombert
Reply #11 Posted on: May 07, 2013, 09:53:49 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2993

View Profile
Uhm no, if I wanted a polygon function, I would start typing polygon_ how the hell am I supposed to automatically make the connection to a draw command?

And it would be like...
newton_shape_create();
newton_shape_model();

newton_* I plan to prefix newt_*

Also...

b2d_shape_create();
b2d_shape_polygon();

Why?

because thats already the function name thanks to GM :P but my b2d_* system attempts to get rid of the Studio nonsense
Actually in the Studio extension its physics_fixture_shape_polygon(); but you can blame YYG for that Josh

polygon_create(); is perfect
« Last Edit: May 07, 2013, 09:59:46 PM by Robert B Colton » Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Male) Josh @ Dreamland
Reply #12 Posted on: May 07, 2013, 10:00:49 PM

Prince of all Goldfish
Developer
Location: Pittsburgh, PA, USA
Joined: Feb 2008
Posts: 2951

View Profile Email
You're only furthering my point. The function is physics_fixture_shape, not polygon_as_fixture_shape. And yes, if you wanted a generic polygon function, such as _create, you would think to check polygon_*. But if you were thinking about drawing a polygon, you would use draw_polygon, just like every other function in GM that does any drawing (except, of course, the 3d functions, which use the namespace d3d_). None of that "polygon_draw" shit, and none of the "model_draw" shit you're proposing, either.
« Last Edit: May 07, 2013, 10:03:31 PM by Josh @ Dreamland » Logged
"That is the single most cryptic piece of code I have ever seen." -Master PobbleWobble
"I disapprove of what you say, but I will defend to the death your right to say it." -Evelyn Beatrice Hall, Friends of Voltaire
Offline (Male) Goombert
Reply #13 Posted on: May 07, 2013, 10:30:05 PM

Developer
Location: Cappuccino, CA
Joined: Jan 2013
Posts: 2993

View Profile
You are incorrect Josh, it is
Code: [Select]
physics_fixture_set_polygon_shape();
For reference...
https://enigma-dev.org/docs/Wiki/Physics_fixture_set_polygon_shape

And you are incorrect again, it is
Code: [Select]
d3d_model_draw(); and it does venture out from the norm of the regular functions

For reference...
https://enigma-dev.org/docs/Wiki/d3d_model_draw

However I do like draw_model(); better, and yes I would be willing to go with that if thats what you want.  (Y)
Logged
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.

Offline (Unknown gender) TheExDeus
Reply #14 Posted on: May 08, 2013, 06:30:34 AM

Developer
Joined: Apr 2008
Posts: 1860

View Profile
He was correct on both accounts. Stop drinking.
He said it's not:
polygon_as_fixture_shape();
which it's not, as it doesn't start with "polygon", but with "physics". The same with drawing functions which all start with draw_ and d3d_.

Thus I agree with Josh. I don't have a solid opinion on the create functions, like should we have polygon_create() or not, but drawing should always start with draw_ or d3d_. And there is no problem to add a search function inside the script editor. There you could type "polygon" and it would not only return "polygon_" functions, but "draw_polygon" as well.
Logged
Pages: 1 2 »
  Print