Pages: 1
  Print  
Author Topic: While we (as in forthevin) are moving shit  (Read 2654 times)
Offline (Male) Josh @ Dreamland
Posted on: May 18, 2013, 05:48:14 pm

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

View Profile Email
Here's a question to think about while we're moving shit.

A lot of functions take specific types of objects as input. This hasn't been a big problem so far, because all objects have been 2D. When users go 3D, the tier object_planar will need swapped out for a hypothetical object_spatial, which implements an x, y, and z. We're going to have cast issues out the ass one way or another, but I think it'd benefit us to have some community discussion before anything big happens.

Ideally, we could solve this by moving functions such as motion_add into the object_planar class. But thanks to our friend, with(){}, this is, as usual, completely off the table. That said, I think we can still use vtables to help mitigate issues, like so:
  • Class object_spatial and class object_planar extend class object_positionable, which has a virtual $add_motion
  • Each child class, object_planar and object_spatial, implement a motion setter for two and three dimensions, but object_planar ignores the given z coordinate.

If we do this, cast checks can be eliminated for engine code, and errors can be reported for assigning z-motion in a 2D object in debug mode (possibly only when a certain flag is set, like -pedantic or -w-wrong-fucking-dimensionality). Other functions, such as those in extensions, would either have to do cast checking or use the virtual methods from object_positionable to be able to whore the vtable.

By the way, let me make one thing clear: if your code contains dynamic_cast, you are doing something wrong. Rule of thumb.

Any thoughts, suggestions, or visions of disastrous issues with the proposed or existing systems are welcomed.

Cheers
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 #1 Posted on: May 19, 2013, 05:45:41 pm

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

View Profile
I really don't have an opinion as I said it is quite fuxd up and I would like to be able to inherit no locals or have an option for that.
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 #2 Posted on: May 22, 2013, 07:58:34 am

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

View Profile Email
forthevin: You reading this? It seems you've begun migrating #define'd functions to enigma_user by rewriting them as regular functions that call the original. That's, in general, a good idea, but it breaks overloads. Would you be interested in a parser macro specifically designed to alias a function in ENIGMA's compiler? You'd call something like $ENIGMA_alias(random_integer, irandom), and it would create a duplicate definition in the current scope. Just an idea.

Otherwise, we'll have to stick with macros for the time being. Or worse: alias all overloads. Not a fan of that idea.

I don't mind macros, because what we're avoiding is C++ definitions that conflict with user code, not user/ENIGMA code that conflicts with C++ definitions.
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 (Unknown gender) forthevin
Reply #3 Posted on: May 22, 2013, 09:33:24 am

Contributor
Joined: Jun 2012
Posts: 167

View Profile
Yes, I migrated several #define'd functions as inlined functions. I didn't think it would break anything, but you are right that it will break overloads. As for a parser macro, I think that is overkill; I mostly did it because I thought it wouldn't break anything, and when all else is equal, inlined functions are nicer than macros. I think it is fine to use macros otherwise for these cases, since the macros in question are generally quite simple. I can go through the commits I made regarding enigma_user and revert the different macro-to-inlined migrations if you want (I see that you have already fixed one case in mathnc.h).
Logged
Offline (Male) Josh @ Dreamland
Reply #4 Posted on: May 22, 2013, 01:45:00 pm

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

View Profile Email
My only bitch with macros is that the syntax checker will sound stupid. The code will read irandom(1,2,3) instead of choose(1,2,3), and the checker will bitch, "Too many arguments to function `random_integer': expected at most 2, provided 3". That might confuse the fuck out of people, or they might assume that ENIGMA is a mind-reading sentient. Either way, it's a little tacky.
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 (Unknown gender) forthevin
Reply #5 Posted on: May 23, 2013, 01:35:17 pm

Contributor
Joined: Jun 2012
Posts: 167

View Profile
I looked through the commits containing the migration to enigma_user, and it seems that the only #defines I touched was the ones in the mathnc.{cpp,h} files.

You have a good point regarding the confusing renaming and errors. As for whether the overloads should all be aliased, or a parser macro should be implemented instead to handle it, they would give the same result for the user if I understand things correctly. I decided to try to estimate how many overloaded #define'd user functions we have. I searched for them using "grep" (grep -R '#define [a-zA-Z_][a-zA-Z0-9_]* [a-zA-Z_][a-zA-Z0-9_]*$' *), and after filtering out false positives, I ended up with 16 candidates, and it turned out 1 of them was overloaded (namely the #define irandom random_integer case). While I am not certain that the search have caught all overloaded #define'd user functions, I do believe it gives a good guess of how many overloaded functions there are. So, given that there seems to be very few overloaded #define'd user functions, I would propose that we alias the non-overloaded as well as the overloaded ones, unless we find/write more overloaded #define'd user functions.
Logged
Offline (Male) Josh @ Dreamland
Reply #6 Posted on: May 23, 2013, 02:41:22 pm

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

View Profile Email
By aliased, I assume you mean #define'd? There is another way we have aliased function in the past, but it might not bode as well with -flto when I finally get around to passing that flag. I believe we did it for make_color; we just used int (*const make_color)(unsigned char,unsigned char,unsigned char) = make_color_rgb;, which, as you know, copies the function pointer to a new variable. I'm not really a fan of this, as I believe it forces the compiler to make both functions use CALL, but I could be mistaken (especially if we add a const in after that asterisk).

I am personally fine with macros, at very least for now.
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) Josh @ Dreamland
Reply #7 Posted on: May 23, 2013, 02:42:33 pm

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

View Profile Email
Is it just me, or is that snippet tag a bit ugly? Maybe I'll add a teletype tag in the near future.
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) polygone
Reply #8 Posted on: May 23, 2013, 07:26:34 pm

Contributor
Location: England
Joined: Mar 2009
Posts: 794

View Profile
I thought draw_get_pixel was added as a macro.

Is it just me, or is that snippet tag a bit ugly? Maybe I'll add a teletype tag in the near future.
I always thought it was ugly but you seemed to like it.
Logged
I honestly don't know wtf I'm talking about but hopefully I can muddle my way through.
Offline (Unknown gender) forthevin
Reply #9 Posted on: May 24, 2013, 05:30:07 am

Contributor
Joined: Jun 2012
Posts: 167

View Profile
Josh, sorry about the confusion regarding aliasing, I meant aliasing them by writing an inlined function. Given that there seemingly are very few overloaded #define'd user functions, I don't think using inlined function will be much work or be very verbose.

In regards to function pointers, that is still the way it is implemented in the OpenGLES graphics system, while it is implemented through inlined functions in all the other graphics systems. I agree with you about the function pointers, it is not the best option. One thing I am wondering about is whether a template could be used to do the inlining and avoid the issues with a macro. But I still think simple inlined functions should be sufficient for our needs. If things change, we can always reconsider.

Regarding the snippet tag, I don't think it is bad when used for proper C++ code, but it doesn't look nice with Unix commands or the defines.

polygone, draw_get_pixel is indeed added as a macro to draw_getpixel, but draw_getpixel is not an overloaded function, so it would be easy to use an inlined function instead.

In regards to 3D objects, it would be very nice to have them at some point. One issue that I see with the proposed solution is that not all functions are easy to extend. For instance, move_contact_* and move_outside_* take directions as arguments. Would an extra directional argument be provided for the 3D object, such as a latitude-direction? That question also depends on how the 3D object is represented in object_spatial. An alternative to generalizing the different functions dependent on object_planar is to create 3D versions for them to use with the 3D objects instead, but that has some issues as well.

I also have another question, namely how the user should switch between 2D and 3D objects. Will it be switchable as a subsystem in the editor for all objects? And will the switching internally be implemented as a subsystem, or implemented some other way?
Logged
Pages: 1
  Print