ENIGMA Forums

General fluff => General ENIGMA => Topic started by: time-killer-games on March 06, 2014, 08:53:47 am

Title: 360 degree gravity engine
Post by: time-killer-games on March 06, 2014, 08:53:47 am
I was really hoping this would work in ENIGMA because I considered using it in the last world for Alien Joe Bob but sadly it doesn't work (yet). It's the physics engine 2Dcube used for They Need To Be Fed. I also think it would really impress some more people from the GMC, sandbox, etc and convince them to try out ENIGMA.

http://sandbox.yoyogames.com/games/142398
Title: Re: 360 degree gravity engine
Post by: Darkstar2 on March 06, 2014, 02:36:49 pm
I was really hoping this would work in ENIGMA because I considered using it in the last world for Alien Joe Bob but sadly it doesn't work (yet). It's the physics engine 2Dcube used for They Need To Be Fed. I also think it would really impress some more people from the GMC, sandbox, etc and convince them to try out ENIGMA.

http://sandbox.yoyogames.com/games/142398

it runs and compiles fine, but it does not behave the way it should, when you move
the player left / right it floats !

Looked at the source, does this thing even work with GM:S ? I notice view angles, image angle, I thought these functions were not supported anymore, also notice other odd things...Assuming angle function is not the issue, perhaps this could be fixed with some modification to the code.





Title: Re: 360 degree gravity engine
Post by: time-killer-games on March 06, 2014, 04:08:09 pm
Nope those are still a part of studio.  How else was the "They Need to be Fed"  sequel created and published by 2Dcube in GMS? I even tested it so I really don't know why enigma is having this issue.
Title: Re: 360 degree gravity engine
Post by: Darkstar2 on March 06, 2014, 05:36:46 pm
Nope those are still a part of studio.  How else was the "They Need to be Fed"  sequel created and published by 2Dcube in GMS? I even tested it so I really don't know why enigma is having this issue.

/begin_twilight zone Theme

*sigh* that's odd I could have sworn they stopped supporting angle functions after 8.1, or perhaps I might be confusing with room angle or view angle, oh well....

/end_twilight zone Theme

Honestly I don't have a fucking clue why it doesn't work properly despite compiling without errors. :D
I thought it had to do with variables or some incompatible shit but I looked and could not see anything unless there is something
in the script (all the math) that is behaving weirdly :D
I guess you will have to wait until Robert takes a look at it :D

It looks messed up, did you notice the player is not touching the solids, seems to be a major issue with contact position, and sometimes player going through solid objects, floating in the air and staying stuck.
LOL maybe it fits 360 degree gravity indeed !  ;D ;D ;D ;D ;D  (bad joke!)

Anyways, there is still probably quite a few things that won't work in ENIGMA, what I am most disappointed and puzzled is the 3D stuff does not work at all. :(

Title: Re: 360 degree gravity engine
Post by: TheExDeus on March 07, 2014, 05:32:17 am
Code is horrible though. Like the "move" script, where the for loop is totally useless as it will always exit on the first iteration. Or planet_gravity() where he has i array in for cycle. The same with much of the other code. All of that could of been written 700% better. And I am sure he knows it, as he writes how bad his code is in some of the comments. Surprised it didn't lag on Android devices when coding like that. So no surprise it doesn't work in ENIGMA. We try to be relaxed in our syntax, but not that relaxed.

The problem is because collision functions in ENIGMA need to have "!=noone" to actually work as expected. That is because of the way C++ booleans work. So in planet_gravity() and air_gravity() you need to add "!=noone" to all collision functions inside the "if" statements. Then it works as expected.

The only way to make this work the same as GM automatically would be trough the parser. The parser could check for a list of used collision functions and add "!=noone" automatically. But I doubt such a specific test should be added to the parser, as it is meant to be more universal than that. In any case, I though Cube guy could code as he has made great games, but from this source it seems he either codes randomly until it works (without understanding why) or just allows others to code and then just stitches together.

Also colors are different between GM8 (the one I tested in) and ENIGMA, but that is ok, as it's just because of the way we handle bound color. Many topics have been made about it.
Title: Re: 360 degree gravity engine
Post by: time-killer-games on March 07, 2014, 02:27:52 pm
Thanks ExDeus! I'll try that out, and let you know how it works. :D

Edit: I wanted to use HD sprites with this, but when I made the character have a 128x128 sprite the collision mask stayed tiny. I've tried messing around with the code but no luck. :(
Title: Re: 360 degree gravity engine
Post by: Darkstar2 on March 07, 2014, 03:10:15 pm
Thanks ExDeus! I'll try that out, and let you know how it works. :D

Edit: I wanted to use HD sprites with this, but when I made the character have a 128x128 sprite the collision mask stayed tiny. I've tried messing around with the code but no luck. :(

If I remember correctly, I read that this engine was not meant for HD sprites.  :P
To me it seems people will have to rethink
how they write code in ENIGMA or redo
some of the older stuff made with GM.
Personally I would not mind having ENIGMA its own product and not 100% compatible,
but provide the old methods and new methods / alternative and documented,
Currently it seems there are many of the
more complex programs that do not work well or at all, probably some requiring changes in coding, some not working at all.

Title: Re: 360 degree gravity engine
Post by: time-killer-games on March 07, 2014, 06:03:56 pm
@DarkStar It's not that it will only work with a small resolution character sprite, it's just that however he made the engine calculate the players collision mask was set to a fixed, very small size, but what confuses me about how to adjust that, is he didn't use any collision events and only one collision_* function that has seemingly nothing to do with the player's collision with planets. Idk if he used point_distance() with instance_nearest() or what for this specific thing, he codded it in a very complicated, more complicated than it had to be.

@ExDeus - I completely agree, for someone who is incredibly gifted at game development, 2Dcube sucks at coding almost as much as I do, which I didn't at all expect. I'm surprised he actually got the 360 gravity working, that must have been perfect blend of guesswork, guestimations, and pure luck morphed with impressive mathematics research.
Title: Re: 360 degree gravity engine
Post by: Darkstar2 on March 07, 2014, 06:25:51 pm
LOL.  There are some gifted game devs but the coding is horrible.  I'm not exactly advanced either with GML, in fact I know the logic / math (to some extent) as I done programming before, but not to a level where you would do optimized GML, if I were to make a game and use GML I'm sure people would probably compact my code 50% lol.

Personally it is a not a coding competition, I'd probably lose badly too :D  I personally judge a game for the game and not what it was made with and how it was coded.

Must admit TKG, I too was a bit confused with his code, was it intentionally coded that way, maybe :D 

What is with all those  underscores before variable names, am I missing something ?

BTW it sure is quiet on those forums lately :)
What have they done with them ? (the aliens :D)

Title: Re: 360 degree gravity engine
Post by: TheExDeus on March 08, 2014, 11:33:06 am
Quote
What is with all those  underscores before variable names, am I missing something ?
When a system is made to be workable as a module or extension (or what in GM is called an "engine"), then often variables are prefixed with something not to cause problems with other variables. Like when I made an inventory extension, I prefixed all my variables with __variable (two underscores) so that when I need to use a variable "width", I write "__width" so that it is distinct from "width" which is something a user might use.
TL;DR - All variables are in the same scope in GM, so you need prefixes to make them work with other unknown systems.

Quote
BTW it sure is quiet on those forums lately :)
What have they done with them ? (the aliens :D)
I personally have a lot of work to do. Part of my work required a simple GUI for controlling cameras which I made in ENIGMA, so when I was working on that I had to implement and fix some things in ENIGMA. Normally though, my work doesn't deal with ENIGMA and so I normally just "disappear" at these points for some time.
Title: Re: 360 degree gravity engine
Post by: Darkstar2 on March 08, 2014, 03:02:11 pm
Ok thanks I haven't thought of that  (the underscore before variables).  Although some of the code is confusing,  but noticed some stuff like _vx=vx etc...

if I were to build an engine and use _ as to not hog variables and leaving it to the user of the engine, and say use, _myplayer, why would I then use _myplayer=myplayer, doesn't it defeat the purpose ?

Title: Re: 360 degree gravity engine
Post by: time-killer-games on March 08, 2014, 04:21:29 pm
Quote
doesn't it defeat the purpose ?
Why yes it does.

Perhaps he did that for a similar reason arrays can be used, to have more than one value stored in a slight variation of one variable name.

for instance you could do....
Code: [Select]
poop[1]=crap
poop[2]=shit

or the way he did it, which isn't isn't nearly as convenient, and doesn't completely have the same effect
Code: [Select]
poop=crap
_poop=shit

I think he just couldn't think of a variable name that made sense and that could not easily be easily differentiated from a variable name he already had in use, so he added an underscore to the new variable.
Title: Re: 360 degree gravity engine
Post by: TheExDeus on March 08, 2014, 07:37:24 pm
Quote
if I were to build an engine and use _ as to not hog variables and leaving it to the user of the engine, and say use, _myplayer, why would I then use _myplayer=myplayer, doesn't it defeat the purpose ?
Ou sorry, I was referring to why you usually would use it. I didn't actually check why he used it. Now that I did check the code, then he used underscores in several situations for several reasons. Mostly two:
1) Don't interfere with built-in variables. He wanted variables to show x/y coordinate, he couldn't use x/y, because they are built-in and changing them has consequences (moving the object). So he created variables like _x, _y and _speed, to go around that.
2) He used underscore in the vx = _vx/100 case, because he needed a way to return 2 values from scripts. Now GM:S allows that (ENIGMA doesn't for now), but previously scripts could return only one variable. So if you needed two, then you ended up using global variables or something like that. He chose _vx and _vy, which are set in get_vxvy.

But his usage of underscore is very inconsistent. That is one of the things I was referring too, when I said his code is very chaotic and not very though out. It seems to be glued together from many sources.