New release? (And beyond)

[starwed]

We've basically finished going through the old pull requests and old but easy to fix issues.  Once the last couple land, we should consider doing another release.   (0.5.4 or 0.6?)

Blocking
Off the top of my head, some stuff that needs doing before a release.
* I'd like someone else to take a look at my dirty rectangles rewrite: https://github.com/craftyjs/Crafty/pull/429
* Some changes landed on master instead of develop, we need to merge those together before testing: https://github.com/craftyjs/Crafty/issues/433
* Once those are resolved, we need to actually get people to test the develop branch!
* Changes to documentation will need to be made live -- who is in charge of crafty.js etc?

If anyone knows of any crazy show-stopping bugs in Crafty, now would be a good time to let us know!

Future?
Going through all the old issues, there are some common pain points we should start addressing:
* Sprites and SpriteAnimations:  I believe grozen's branch has fixed several of these issues, but there are still several lurking bugs.  Will require breaking backwards compatibility for animations.  (https://github.com/craftyjs/Crafty/pull/426)
* Viewport: Many bugs to do with the viewport; with the benefit of hindsight I think it could probably be refactored.
* Mobile: Figure out what we're missing for mobile work?  (Maybe it works fine now, but I have no personal experience and there are several old open issues.)
* Documentation: People I've talked to who have tried to learn Crafty say that the documentation could use some work.  Probably we should do something to encourage feedback here?

[Guy Rozen]

I have only three things to say:

1. I will do my best to wrap my pull request ASAP. Don't want to hold anything back.
2. The documentation can definitely use some sprucing up. The only reason I felt comfortable using Crafty is because I do not shy of diving into the code to figure out how to use things, and at times I felt that I was forced to do just that. This is something I really tried to address in my pull request. I could do my best to tackle more documentation.
3. Another thing I think is sorely missing is a beefier contribution section in the repo's readme. While we are a very welcoming bunch, I think it would be best if we explained how to make fixes/write new features in greater details. Specifically, how to write documentation (a link to the Style Guide, perhaps?) and something about writing/running tests.

Bonus thing to say: way to go, starwed!

[starwed]

Ok, I've landed the two blockers (merging from master, and the dirty rectangles rewrite.)

We need people to test this!  There are bunches of fixes and performance improvements from a great many people; it's been a while since we released.  I'll try to put together a changelog and post it here.

[Steve Byrnes]

To make it easier for people to test: This is the new crafty.js file

http://sjbyrnes.com/crafty/crafty.js

and this is the new documentation:

http://sjbyrnes.com/crafty/api/index.html

(I used the latest develop version, 4403a0fa110a21765e64b4fabb002259efb7481e )

My own personal stuff is running correctly. The "core" unit tests pass
in latest firefox and chrome. I haven't tried the demo games.

:-D --Steve

> --
> You received this message because you are subscribed to the Google Groups
> "Crafty" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to craftyjs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Ricardo Moran]

Hi, I found a drawing bug in one of my games. I isolated the problem in the following example: https://dl.dropboxusercontent.com/u/43706148/Crafty/testing.crafty.0.5.3/main.html.

As you can see, I have two entities. If I remove the background entity then the bug dissapears. I'm sorry I don't have the time to debug this right now, but I just wanted to let you know about the problem. BTW, this happened on Chrome, Firefox, and IE10.

Richo

[Ricardo Moran]

Oh! another one on the same example. If I press any key the console shows me this error:

1. Uncaught TypeError: Cannot read property 'nodeName' of undefined crafty.js:6439
1. Crafty.extend.keyboardDispatchcrafty.js:6439
2. afncrafty.js:4686

Cheers,

Richo

[starwed]

Ah, ok, dumb mistake on my part.  The new dirty rectangles code doesn't take into account the MBR of rotating objects, which leads to those drawing artifacts.  The reason it disappeared when there was no background is because, with only one entity, it defaulted to redrawing everything rather than worrying about the dirty rects.  (We do that if the number of entities to redraw is more than 60% of the total.  That's a pretty arbitrary number; we should probably figure out what sort of heuristic to use there.)

Luckily it takes minimal code to fix this; just something I forgot to consider!

The second problem with the keyboard triggered error messages came from some code that stops Crafty from grabbing keyboard events when we're focused on a textarea or input.  It's a one line fix to check that we're actually focused on something before trying to access its nodeName property.

Thanks for the reports!  I'll land the fixes tomorrow morning/afternoon (unless someone beats me to it!)

[starwed]

Ok, I landed fixes for those two bugs.

There were still very slight drawing artifacts in Ricardo's example.  I think this was improper rounding when calculating the MBR, which I fix here: https://github.com/craftyjs/Crafty/pull/470

That prevents the issue I saw, but I didn't do the work of confirming that rounding was the direct cause of the bug.  I'm not sure why we didn't see this before, though it might be due to an error in the old merge algorithm systematically overestimating merged areas.

On Tuesday, 14 May 2013 17:48:02 UTC-4, starwed wrote:

[starwed]

Oh, and here is a link to the new built version: http://abstractvisitorfactory.com/~tim/crafty.js

That's built off the current HEAD of develop: c109bc24b2bda13dbb0a82681239681097c6a525

On Tuesday, 14 May 2013 17:48:02 UTC-4, starwed wrote:

[Steve Byrnes]

I started playing with the demos.

http://sjbyrnes.com/crafty/repository/Crafty/demos/

(using the latest, c109bc24b..., at
http://sjbyrnes.com/crafty/repository/Crafty/crafty.js )

One thing I noticed in Connect 4 is that the font size is wrong (you
have to get to the "winner" screen). Here is a fiddle with the
relevant part of the code:

http://jsfiddle.net/dPFk5/

On my computer at least (firefox + linux), the font size in the fiddle
is ~10 no matter how what size you set it to. Is that true for other
people?

:-D --Steve

[starwed]

Ah, that's because we now provide a default font size and family, which will override the css you provided when the entity is rendered.  If you use .textFont to set the size, it works ok. 

I'm not really sure what the best approach/behavior is here; suggestions?  The css spec doesn't allow setting the size or family separately, and you can't query the canvas to determine their current state.

[Steve Byrnes]

I suggest to just fix the demo.

The documentation already makes it very clear that .textFont is the
right way to set the font, so most people will not think to use
.css().

If that's not enough, something can be added to the Text documentation
somewhere that says: "For DOM text entities, you can use .css() to set
SOME properties (like user-select), but the font and color settings
should always only be adjusted using .textFont() and .textColor(), not
.css()". But again, I doubt it's necessary to say anything at all.
--Steve

[Ricardo Moran]

Great! Now all my projects work fine with the new version :). Thanks!

Richo

--

[Steve Byrnes]

I updated to the latest development version
(137708e8f362214a4f3b912b78d32dd27f2911af)

The compiled script...
http://sjbyrnes.com/crafty/repository/Crafty/crafty.js

The documentation...
http://sjbyrnes.com/crafty/repository/Crafty/build/api/index.html

The unit-tests...
http://sjbyrnes.com/crafty/repository/Crafty/tests/
(I know that core.html is supposed to work -- and works for me -- but
most or all of the other files are out-of-date.)

The demos...
http://sjbyrnes.com/crafty/repository/Crafty/demos/

I haven't tried all the demos, but I did notice a problem with fruit
assassins -- there are white boxes around the fruit. I don't think
they're supposed to be there ... if I remember right, they weren't
there before.

[Steve Byrnes]

> http://sjbyrnes.com/crafty/repository/Crafty/demos/
>
> I haven't tried all the demos, but I did notice a problem with fruit
> assassins -- there are white boxes around the fruit. I don't think
> they're supposed to be there ... if I remember right, they weren't
> there before.

Update: I see white boxes around the fruit in firefox (v21) but not
chrome. --Steve

[starwed]

Huh, I don't see white boxes in any browser on my Mac, including FF 21.  Maybe double check in safe mode, in case it's an extension interfering?

[Steve Byrnes]

Strange! Yes, the boxes are still there in safe mode, and even in
safe-mode in a brand-new firefox profile (empty cache). This is
firefox 21.0+build2-0ubuntu0.12.10.2. There is no problem for me (no
boxes) in firefox 20 or 21 in windows. Very strange!

By the way, I tried switching the game to crafty.js instead of
crafty-local.js, but it didn't make any difference:

http://sjbyrnes.com/crafty/test/demos/fruitassassin/fruitassassin.htm

Does anyone else see white boxes? Or just me?

Has anyone else come across situations where there is different
behavior in firefox-in-linux versus firefox-in-windows/mac? --Steve

[starwed]

If your firefox build is from ubuntu's repos, they might have tweaked the settings?  You could try installing a mozilla built firefox binary directly: https://help.ubuntu.com/community/FirefoxNewVersion/MozillaBuilds

I did a quick look for possible known bugs, could it be this one?  https://bugzilla.mozilla.org/show_bug.cgi?id=831244

[Steve Byrnes]

Update: I submitted it as a potential firefox bug

https://bugzilla.mozilla.org/show_bug.cgi?id=875184

Of course it could also be an ubuntu bug. It's even slightly possible
that it's a craftyjs bug ... but it probably should not block the next
crafty release, since I'm apparently the only one who has seen this
problem. :-D --Steve

[darcie....@fitfunner.com]

The main thing I found with the documentation is that a lot of links are missing.  Like pages can be reached from other pages that refer to them, but they don't show up on the navigation menu.  It's also not real easy to find what I need because of how it is organised.  I never know if what I am looking for is going to be in the core, or some other place.  More examples of how to use various features would also be nice.  I find myself doing searches on the crafty.js file just to figure out what variables to pass to a function because I have no examples.

I've also noticed that .attach does not seem to work with tweens, but then there is next to no documentation on either.

I'd like to see sprite text that responds to alpha tweens as well.  I've written my own for just numbers to get by.

Code for auto forking which sounds get loaded would also be nice. 

If animation has to break, I'd like to see it break sooner rather than later.

In general though,  I do have to say that Crafty is a very nice lightweight architecture to work with.  I've been building some fancy loading systems for sprite that I may share in the future depending on how it goes and what the boss thinks.

[starwed]

Thanks for the feedback!  I'll make a note to improve documentation for tweens and attach.

If you can happen to remember any other specific missing docs, feel free to list them out here.

What do you mean by "auto forking which sounds get loaded"?

[starwed]

Also, anyone who ends up diving into the source code to figure out a function should feel free to just open a pull request to add docs! 

Of course even if you're not in the mood, telling us either on the forum or in a github issue is still really helpful.  :)

On Friday, 24 May 2013 12:39:35 UTC-4, darcie....@fitfunner.com wrote:

[Kev Zettler]

Some points on Crafty's Documentation and learning curve. I've found that crafty uses shared names fro different functionality which can be confusing. A few cases: 

The .animate() method. Its used to define an animation, and play an animation when called with different parameters. This is a common gotcha for newbies I've seen. I think simply differentiating the method names like .setAnimation .playAnimation would be helpful here.

"Change" Events. if you check http://craftyjs.com/api/events.html and Ctrl+F for 'Change' you'll find several instances of the 'Change' event. These are all fired from various components with different parameters passed in. It becomes totally confusing when you want to subscribe to 'Change' for an animation and you are getting Change events fired for a sprite moving. Again I don't see why these couldn't be named like: 2dChange, flipChange, moveChange AniChange, etc...

I think these could be added with backwards compatibility, keeping the original double names to not break existing projects. Moving forward I feel more specific names would be better.

[starwed]

Amusingly, both the specific examples you chosen will be fixed when the animation PR request lands: https://github.com/craftyjs/Crafty/pull/426 

I think the overloading of method names is something that's kind of borrowed from jQuery, where I also find it confusing.  It also causes problems where we either have to break the API or workaround the existing behavior, because the original overloaded methods are not flexible enough for new functionality.  So I definitely agree with you here, except I'm also willing to break the current behavior!

In general, "Change" events need to be fired every time an entity will need redrawing.    But we can fire additional, more specific events where it makes sense.  For instance, there will be a "FrameChange" event for animation.  There are already  "Move" and "Rotation" events, but we can definitely go through and add some for things like "Flip".

Thanks for taking the time to give some feedback!

[João Henrique Pimentel]

Hi, just to say that this new version is working well for my games, apart from the CSS styling of fonts that you already discussed =)