Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Regarding you technical points:

Yes, there is an issue with O!, it makes too much garbage, it should be corrected.

I guess your point is to store depth of a drawable instead of traversing the tree? I'm not sure how faster it can make the entire rendering process.

tick(fn) to register fn is only called during initializations (not every frame), it doesn't matter how it is implemented.

Instead of pin({}) you can use pin('name', value) or simply reuse your {} object. I don't see any problem with "_next = {}" where it is used for creating tweening.

Without type hinting it is still fast enough, but good idea.

Thanks for your point about "throw", however I'm not sure functions having "throw" really need to be optimized, but I will consider that.

absoluteMatrix is only for internal use, and I have not documented it yet, but it is what it is and is only updated on ticks for performance reasons.

Thanks for your point about drawImage try/catch.

I'm not sure how drawImage with source params is optimized across different platforms so for now I have let it be as it is. But I agree with your point.

There is obviously a lot to make it run faster but the point is to find bottlenecks which really matter. For example in most case the bottleneck is the physics engine not rendering engine at all.

Also if you notice you can see I have done a lot to make it fast, for example using lots of timestamps (ts) and monitors (mo) to avoid unnecessary calculations.

Anyway feel free to fork it and change anything to prove that I'm wrong! I will appreciate that!



I compared O! GC with few other HTML5 games, it seems that GC frequency is normal with high number of game objects.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: