__________________________________________________ 3D framework studio: http://scratch.mit.edu/studios/202972/ *********************************************************************** Enjoy flying along with the other ships - look out for asteroids! ;) Arrows & WASD to fly ship. Hit 'O' to see options, 'T' for timers. Problems with KEYBOARD LAG?? -see notes in start screen. If you're using Chrome and you still have lag as soon as you hit a key, try switching to Firefox (or even IE - gasp!) (BTW, before you ask: no, you can't fly to the earth, or the moon...)
This uses a NEW EXPERIMENTAL RENDER-ORDERING method I've come up with - but shouldn't look any different to the original. The way this new method works relies on Scratch's 'internal workings' (see below) rather than some scripted sorting of a list - so I decided to share to check it really works for everyone else, and to see if it might even be a little faster than the original version... BACKGROUND: to ensure objects are rendered in the right order onto the screen, they have to be sorted in some way (e.g. by some measure of distance from the camera). The original version takes the most obvious approach: creating a list of the (visible) structures' components, sorting it by distance, and rendering all of them in one loop within a single block, which is set 'non-refresh' to prevent flickering during the render. This version actually creates a clone for each of the objects (or class of object) to be rendered (including each sky object: earth, sun, moon, even stars & dust), and layers them within the Scratch sprite layering system, furthest one from camera being the one moved to front (on top of other sprites). When the "render all" broadcast is sent, the sprites/clones receive it in the order they are layered on the screen. This means the topmost one gets rendered first, and so on to the bottom one (which should be the nearest object, hence last one to render). One really useful extra benefit of this is that we can add any sprite we want into the middle of the Scratch sprite layering, and have it do something during the render itself - something which can't be done (getting at a script in a different sprite) if using a single non-refresh block for the whole render in one go. I've used this to move one of the checks for key-presses (which is in a different sprite) into the middle of the render - hopefully this will make certain key-presses (e.g. double-taps) more reliable in future, and means key control can be a little more subtle (e.g. quick taps). Let me know how it works for you - is it faster than the original?
