ENIGMA Forums

General fluff => General ENIGMA => Topic started by: Goombert on May 05, 2013, 05:53:09 PM

Title: Critical Change, Function Renaming
Post by: Goombert on May 05, 2013, 05:53:09 PM
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?
Title: Re: Critical Change, Function Renaming
Post by: Josh @ Dreamland on May 06, 2013, 12:39:04 AM
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.
Title: Re: Critical Change, Function Renaming
Post by: Goombert on May 06, 2013, 01:06:42 AM
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
Title: Re: Critical Change, Function Renaming
Post by: TheExDeus on May 06, 2013, 05:32:33 AM
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.
Title: Re: Critical Change, Function Renaming
Post by: Goombert on May 06, 2013, 06:48:57 AM
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 :)
Title: Re: Critical Change, Function Renaming
Post by: Josh @ Dreamland on May 07, 2013, 10:55:39 AM
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_.
Title: Re: Critical Change, Function Renaming
Post by: Goombert on May 07, 2013, 11:25:13 AM
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.
Title: Re: Critical Change, Function Renaming
Post by: IsmAvatar on May 07, 2013, 03:16:07 PM
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).
Title: Re: Critical Change, Function Renaming
Post by: Josh @ Dreamland on May 07, 2013, 04:37:30 PM
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.
Title: Re: Critical Change, Function Renaming
Post by: Goombert on May 07, 2013, 07:51:35 PM
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.
Title: Re: Critical Change, Function Renaming
Post by: Josh @ Dreamland on May 07, 2013, 09:01:30 PM
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.
Title: Re: Critical Change, Function Renaming
Post by: Goombert on May 07, 2013, 09:53:49 PM
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
Title: Re: Critical Change, Function Renaming
Post by: Josh @ Dreamland on May 07, 2013, 10:00:49 PM
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.
Title: Re: Critical Change, Function Renaming
Post by: Goombert on May 07, 2013, 10:30:05 PM
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)
Title: Re: Critical Change, Function Renaming
Post by: TheExDeus on May 08, 2013, 06:30:34 AM
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.
Title: Re: Critical Change, Function Renaming
Post by: Goombert on May 08, 2013, 11:33:16 AM
"The function is physics_fixture_shape"

Deus, he stated that it is physics_fixture_shape, he was definitely wrong, your misinterpreting what he said, I already corrected him on the corret name of the two functiosn which is d3d_model_draw(); NOT d3d_draw_model(); like you would assume it is, and its physics_fixture_set_polygon_shape(); in the Studio API.

But the polygon functions would be box2d, SVG graphics support, 2D polygonal type models and rendering, and could have other uses too.
Title: Re: Critical Change, Function Renaming
Post by: TheExDeus on May 08, 2013, 03:02:59 PM
You are not understanding AT ALL what he means. We don't care what the second or the third word is in the function. We care what the FIRST word is. The point is that the function name is:  "PHYSICS_some_long_shit_noone_cares_about();" instead of "POLYGON_some_another_long_stuff()". The same with drawing. The point is not whether its "d3d_model_draw()" or "d3d_draw_model()", but that it's NOT "POLYGON_draw()".

So again, he was correct on both accounts, you just seem slow at the moment.
Title: Re: Critical Change, Function Renaming
Post by: DarkAceZ on May 08, 2013, 10:03:20 PM
if you think that 3D models should be used in 2D
If*
Title: Re: Critical Change, Function Renaming
Post by: Goombert on May 08, 2013, 10:59:08 PM
No no no, Deus, your confused I want draw_polygon, and draw_model, we are all on the same base there  ;D lol you got it backwards dude, I agree with you on that.

And should 3D models be used in 2D? lolololololol

they already are, all your draw_sprite calls? They draw a 3D floor with 0 for the z coordinates lolololololol, everything in OpenGL is 3D, everything in our engine is 3D, theres no need for disambiguation, except between what you are drawing not how you are drawing

And Studio already has polygon_* functions and a polygon editor, I am just wanting us to plan how we intend to restructure some of the dumb things YYG have done after they are long out of business and their persistent nonsense no longer having any influence.
Title: Re: Critical Change, Function Renaming
Post by: TheExDeus on May 09, 2013, 08:55:36 AM
But that is what Josh wants as well. So when you argued with him you already failed. Though the arguing was more about the PHYSICS and POLYGON functions. So basically, if the physics mesh from polygon function should be under physics or polygon. Josh and I argue that it should be under physics.

And we know how our graphics system works.
Title: Re: Critical Change, Function Renaming
Post by: Josh @ Dreamland on May 09, 2013, 09:52:56 AM
Quote
they already are, all your draw_sprite calls? They draw a 3D floor with 0 for the z coordinates lolololololol, everything in OpenGL is 3D, everything in our engine is 3D, theres no need for disambiguation, except between what you are drawing not how you are drawing

Oh, good, then; let's just lose the polygon functions and call everything model_*, while we're at it.
Title: Re: Critical Change, Function Renaming
Post by: TheExDeus on May 09, 2013, 10:41:42 AM
Actually quite correct. There is no real distinction, as I (and many others in GM) have used models just for fast 2d drawing. Can't remember if you can query data from a GL model, so it would be harder to make a function that turns the model into physics mesh. Aren't models a class in ENIGMA?
Title: Re: Critical Change, Function Renaming
Post by: Goombert on May 22, 2013, 07:48:27 PM
Yes Deus however in the new graphics system they are using Vertex Buffer Objects. That creates the problem there because when you pack the vertice data into the VBO it gets sent to the GPU and is then cleared. Now the polygon functions I have already added to my version of Box2D, as you know we have two extensions now. The shape functions are used for building the various polygonal collision objects and stuff within the world. I was just proposing the idea of making them drawable, and all inclusive. And there has got to be a way of modifying a VBO or how vertex data is stored so that a z value is not even passed, I can't think of why there would not be. But I am only proposing dropping d3d_* in the future really, because d3d_model_draw is not consistent with draw_sprite and other draw_* functions. If I am wanting to draw a model then I darn well need to know wtf models are and prefixing them with extra characters that I don't need to waste my time typing always, is not going to help me, in fact a clear abmiguation would help me more to see that their is in fact a difference.
Title: Re: Critical Change, Function Renaming
Post by: TheExDeus on May 23, 2013, 01:08:19 AM
I doubt there is a way to pass something in GL without z. Everything in GL (even huds in games) is always in 3D as that is  a 3D API. I also don't think there is that much overhead in sending z to the GPU. Especially if you send it only once when sending the whole VBO. And GPU does all the calculations on all 3 dimensions, so I think it would be even slower for it if it had special functions for 2D.
Title: Re: Critical Change, Function Renaming
Post by: forthevin on May 23, 2013, 03:47:26 AM
VBO's are actually very flexible. They can be used to transfer arbitrary data, both texture coordinates, points (1D, 2D, 3D and 4D), colors, etc. I don't know how significant the difference is between transferring 2 or 3 coordinates, but I believe it depends on the specific case (how fast the hardware transfer from the CPU to the GPU, how much other data is being transferred per vertex, etc.). Once a point arrives in the GPU, I believe it is generally transformed into 4D homogeneous coordinates once outputted from the vertex shader.
Title: Re: Critical Change, Function Renaming
Post by: Goombert on May 24, 2013, 12:03:28 AM
Ahhh thank you forthevin, thats what I had assumed.  (Y)