Silverlight

[d000hg]

One thing that I can't understand nowadays is all this "my new rig gets fifty million fps" stuff that people go on about. If the display is refreshing at, say, 70HZ, you'll get 70fps that actually have any effect on your sensory organs, full stop. Rather than rendering more fps, the application should be doing useful work, like "AI" and such, that's processor-intensive but can be amortised across multiple rendering cycles. If I'd ever written something that could render multiple frames that the punter would never see, I'd have soon come to the conclusion that I was doing it wrong.

Or have they ****ed up with modern games like Doom and tied their background processing to the frame refresh cycle?

The FPS thing is kind of an e-penis thing, and also a way to compare system performance. There's debate at what point FPS increase gets meaningless and in fact it's a pretty complex issue, but basically there's not much difference rendering faster than the refresh rate (some small benefits potentially).

And no, logic is normally separate from FPS although I don't think it's commonly multi-threaded even these days since it's hard to decouple. Game AI might run at 10Hz, physics at 100Hz, etc.

[xoggoth]

What problems do you see? All correct but jumpy

That's about it. A small but noticeable jerkiness. Might be satisfactory if I (and users) hadn't seen Google Street View.

BTW, there's no point ever using less than 10ms for setInterval

Wasn't really trying to apart from above test. I don't need a fast scroll, just hasta be some way to get it a bit smoother apart from using much smaller images, not really much good for my application. 300x300 works great. There's plenty of smooth scroll "kits" (not found one that actually works yet) but from examples they all seem to use images of that size so suspect they don't have any brilliant wrinkles anyway.

PS Don't recall any obvious instal/download but actually Streetview seems to be using ActiveXObjects.

[NickFitz]

Is there a good way of doing a proper "game loop" in browser based JS? All the examples I've seen use timers, and worse suggest you use lots of different timers for different animated objects, which sounds like a recipe for overhead and inconsistency.

In Windows, I've seen people use WM_TIMER messages to do animation, but the much better way is to rewrite the main application message loop to include updating the animation, but that won't work in something that's totally event driven. And presumably if you go into an endless loop in JS, the browser is going to treat that as a hang.

In Flash, being frame based, you can have an onEnterFrame event that's triggered at the frame rate of the movie, which at least means everything runs consistently even if it can sometimes get behind if the renderer can't keep up.

Well, the main application message loop is just a thing that relinquishes control whilst it waits for events to arrive - otherwise, the first app you ran would consume 100% CPU busy-waiting. On a multi-tasking OS, all applications are event-driven, even if the event is the implicit one of being given a timeslice that allows an endless loop to have another go at running to infinity.

For JS, you don't need to think about the main application message loop: that's already in existence in the host context, outside the scope of your code (e.g. in the browser process or, for something like node.js, in a server process) and all you deal with is the messages that are dispatched to your code, which in the case of the browser consist of user interaction events (e.g. the user has moved the mouse over something), network interaction events (e.g. an image has loaded, or an XMLHttpRequest has undergone a state transition), and timer events (interval timer X invokes its callback). These events are all provided by the external context (note that setInterval and setTimer are both methods of the window object, not functions native to the language), which is why JS can easily be deployed in other contexts such as servers (where the events are things like "a remote host connected" or "a disk-based file has been opened and can now be read"). Either way, callbacks are king: whilst the script is being parsed it can do stuff if the context provides for it (e.g. document.write() in browsers, and the creation of variables having global scope) but after that, everything happens as callbacks from the context's event loop.

Personally, I prefer a setup that makes it clear that your code is running as and when things happen that it needs to deal with. (Any attempt to create an endless loop in JS in a browser will result in the browser stepping in and prompting the user that a script is running for too long; otherwise, Denial of Browser attacks would be all over the web.)

JS in the browser doesn't have the concept of frame refreshes, because stuff like that is abstracted away into the browser's rendering engine, which will take care of all the aspects of rendering like double-buffering and clipping content to containing views.

Incidentally, one of the reasons that Flash can be "The best way to tell if your laptop's fan still works" is that ActionScript is constructed on the same principles, but many Flash devs can't seem to get their heads around the idea of creating applications that consist entirely of callbacks; instead, they create busy-waiting loops which consume loads of CPU. The fact that Flash allows this is one of its greatest failings. It should just kill stuff that busy-waits beyond a certain time; then the errant devs would have to learn to do it properly, or be out of a job. But it doesn't, so they aren't, so Flash is a scourge. I've found great inner peace since I blocked it

[NickFitz]

PS Don't recall any obvious instal/download but actually Streetview seems to be using ActiveXObjects.

StreetView uses Flash, which is implemented as an ActiveX control on Windows (and as a demonic swarm of soul-sucking hags on other platforms).

[original PM]

the more alert of you may have noticed a thread in general about me finally getting a system in place - guess what it was developed in Silverlight - so this thread sent shivers down my spine!

However we have approached MS directly about this and apparently during the PDC10 one of MS's lead developers put his foot in it and has been trying to take it out ever since.

So it would seem the rumours about the demise of Silverlight are somewhat premature......

only time will tell I suppose.

[d000hg]

They never said it was being dropped, or mothballed. Only that their main focus for PCs was on HTML5. Certainly no concern it's suddenly going to disappear, and SL4 looks pretty full-featured already.

[AtW]

Certainly no concern it's suddenly going to disappear

They did it to VB and that had much stronger developer support...

[d000hg]

What are you trying to say? VB is still used in loads of legacy projects, if VB.net hadn't replaced it I bet VB6 would be used a lot more even now... VB6 is over a decade old, but SL is still in active development.