Skip to content

Catch up with upstream. #31

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 33 commits into from
Jun 20, 2016
Merged

Catch up with upstream. #31

merged 33 commits into from
Jun 20, 2016

Conversation

IBwWG
Copy link
Collaborator

@IBwWG IBwWG commented Jun 20, 2016

No description provided.

Gama11 and others added 30 commits April 26, 2016 21:24
This is only an issue on dynamic targets (Neko, HTML5).
closes #1835
The accelerateFromAngle function has a problem in that if sine or cosine of the angle is negative, then the maximum velocity will end up being negative, which it's never supposed to be.

For example, If your current velocity was 10, and you wanted a limit of 100; depending on the angle of rotation you can suddenly end up with a maximum velocity of -100. This makes your velocity of 10 look to be 110 over the maximum. Then you get an extreme change of velocity. In the app I was working on I ended up with a constant oscillation between -100 and +100 from one frame to the next. Adding the Math.abs functions inside accelerateFromAngle, fixes this.
With hscript version >= 2.0.5 compiling with -DhscriptPos gives compilation error:
flixel/4,0,1/flixel/system/debug/console/ConsoleUtil.hx:156: characters 9-42 : Class<hscript.Error> has no field EInvalidAccess

The proposed fix uses the error() method now defined in hscript's Interp class (following usage in hscript's Interp.hx)
The description of time was a bit wordy.
- less redundancy in addQuad() by using a helper method
- less nesting by inverting an if in render()
- added unit tests to ensure consistent behavior
- fixed drawDebug's value changing after the signal is dispatched
- removed inline from setters (too complex)
Gama11 added 3 commits June 16, 2016 14:36
This happened only if Git was not available on the command line, which led to a "process creation failure" exception. This meant that the macro wouldn't return to the previous working directory, throwing off Lime's build process.

Caused by 00a39e6.
@IBwWG IBwWG merged commit 119aa76 into codingthat:dev Jun 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.