Typescript examples of the book

[huanhulan]

Hi all, I have done some of the examples on the book with sodiumjs that I'd like to share with you, here they are:
* zombicus(special thx to @clinuxrulz for helping me with the GC issue)
* bouncing ball with continueous time
* petrol pump
* television switch (which is just the pseudocode in the book)
* battle of paradigms(oop vs frp, no actor model)

[the-real-blackh]

Thank you!!!!!!!!!!!!!!!!

I've given you write access to the Sodium repositories. I'd be very grateful if you could upload your code into the sodium-typescript repository.

[huanhulan]

thank you!!! I will try

[dakom]

Wow this is great! Thanks @huanhulan !!

[dakom]

The bouncing ball example feels a bit janky... I'm guessing that would be fixed by sampling via requestAnimationFrame rather than setInterval/Timeout, though in that case it would drift a bit from the book implementation / learning exercise

[huanhulan]

I use the setTimeout just to demonstrate the notion of “sampling the time".
To be honest, I have not looked into rendering performance of the example yet.

[huanhulan]

em..I use the chrome dev tool to test the performance of the bouncing ball examplle on my computer( i7-4710HQ 2.5GHZ ) with 4x cpu slowdown for about 22 seconds, and the average FPS is about 52.

[dakom]

Without digging into the code, my rough guess is that it's firing a paint event more often than requestAnimationFrame, so there's a queue of pending events building up.

Not entirely sure - but I don't think there should be a problem keeping a steady 60FPS even with a bunch of bouncing balls

Could be the canvas API too. Maybe a bit later I'll make a fork and tinker around...

One thing that comes to mind is that on the web there's really no benefit to painting at anything other than requestAnimationFrame. Of course you might have updates more often than that, or there might not be any updates.

This actually points to one of the most elegant things about FRP imho - you can have different "timers" at different frequencies and compose them to get something else. E.g. the internal bounce logic can run at 200 FPS (or continuously, which is awesome) but you can get a stream of events that snapshots that when it's time to paint, so there's no missed physics and you're not thrashing the paint queue.

Not sure if any of that's the issue here - happy to take a look later if you haven't already solved it by then

[huanhulan]

Yes, requestAnimationFrame is the cure for this example when setting to 60 fps, since under the hood it's hardware related.

But my opinion last day is that I don't want the extra toil, which is changing the timer in someway, since the performance
of the example is "just fine" by my point of view, Because without slowing down the cpu, most of the frames reach 60fps, some of them even above.

Btw, if just thinking operationally, changing the timeout function with a variable can actually impede the performance. So if I really need to refine the performance, I should refactor the index.ts.

[dakom]

Yeah I think for the sake of learning and demoing the book examples, it makes sense to keep it based on the slider

Maybe there could be a tick box to switch between modes or something, or maybe just add a note to the Readme?

Either way - nice work!

[huanhulan]

Good suggestion, thank you~
Btw, I also find out by adding an requestAnimation call inside the timer, let the browser do the patching, can help the performance from what I been told from the result of the devtool. I'm lack of html5 game developing experience so I am not sure if this is the right way since it's a bit of counter-intuitive:

setTimeout(paint,17) -> setTimeout(()=>requestAnimationFrame(paint),17)