bharvey wrote:
rookwood101 wrote:
I agree, it is extremely unstable in firefox
Which Firefox, which OS, what happens in Firefox's safe mode? Tnx.
12.0 (latest version) windows 7 64 bit and the same thing happens.
I was reading an article the other day about getting smooth animations with the canvas and it mentioned a relatively new javascript function (http://creativejs.com/resources/requestanimationframe/ - requestAnimationFrame) which I think could be used to solve the problem. I think the problem is that firefox is not particularly happy with loops that take too long on each cycle and with requestAnimationFrame (or even using setTimeout) you could have it call itself and firefox (I think) would be happier.
so instead of:
var world; window.onload = function () { world = new WorldMorph(document.getElementById('world')); new IDE_Morph().openIn(world); setInterval(loop, 1); }; function loop() { world.doOneCycle(); }
You could do:
var world; window.onload = function () { world = new WorldMorph(document.getElementById('world')); new IDE_Morph().openIn(world); setTimeout(loop, 1);//OR requestAnimationFrame(loop);//See the article for more information on exact usage) }; function loop() { world.doOneCycle(); setTimeout(loop, 1);//the timeout/reqanimframe calls itself - thus creating a setInterval effect. requestAnimationFrame(loop); }
Last edited by rookwood101 (2012-05-01 18:33:34)
Offline
Hi, rockwood101.
Thanks for the pointer to requestAnimationFrame().
I've been thinking about using it, but so far it is unsupported by some browsers - especially by MS IE9 - so I'm currently reluctant to switch over. The main issue, however, is that I don't think we need it for Snap, because Morphic takes care of most of what's wrong with setInterval() internally, especially through its sophisticated mechanism of progressive screen updates (Morphic only redraws "damaged" screen areas in each display cycle, not everything).
There are also some other open questions related to requestAnimationFrame() that I'm not yet convinced of, and there are hints of "smart" behavior that I find outright scary (e.g. that browsers might be able to throttle the framerate according to what's happening in other apps or based on battery status). I'll keep an eye on browser support, and we'll play with it once it's supported by all browsers, and then we'll see.
In the meantime I doubt that the problems you seem to be experiencing with Firefox are due to not using requestAnimationFrame(). The problem with Firefox is, that it's JS VM is plain slow compared to both Chrome (always faster than everything else, by several orders of magnitude) and Safari, regardless of what they're saying or which benchmarks they're using. But, to be fair, Firefox's Canvas rendering implementation is by far the best, most complete and most accurate in any browser. So, in the best of worlds we'd have Mozilla just switch over to Chrome's (open source) V8 JavaScript VM, and Chrome switch over from WebKit to Mozilla's (open source) Canvas rendering engine. In the meantime we're left with hoping for incremental optimizations and performance gains
Offline
NOOOOO!!! IT DOESN'T WORK ON THE 3DS BROWSER!!!!!!!!!!
I hate the all-caps filter sometimes
Offline
joefarebrother wrote:
NOOOOO!!! IT DOESN'T WORK ON THE 3DS BROWSER!
Should that really surprise you?
Last edited by blob8108 (2012-05-02 14:14:52)
Offline
@shadow and Hardmath:
Okay, I think we're ready. I've made a shared Dropbox folder called manual-pics to hold the new picture files. If you send me an email address I can invite you to it. Or if you're unhappy sharing your email and have a better idea for sharing files I'm happy to have suggestions. I'm bh@cs.berkeley.edu
A rough draft manual is at http://snap.berkeley.edu/draftManual.pdf. Part V, on sprite OOP, is going to change in yet-unknown ways and isn't implemented, so I suggest Parts I-III for shadow and Parts IV, VI-VIII for Hardmath (who gets the extra one because there's just one page in Part VIII).
To avoid confusion please use filenames in the form p43-2.png for the second picture on page 43 of the draft. PNG is preferred because it's unencumbered by patent licensing; JPG second choice and GIF third.
Try to get pictures without grey backgrounds (from palette or scripting area) unless the picture shows the entire Block Editor or input dialog window (in which case still no background outside the window) or the block's location in palette/script/etc is part of the point of the picture, as in p5-1, p6-1, and p6-3.
Suggestions about errors or confusions in the text are welcome too -- if you don't understand something, neither will new users!
And thank you so much for volunteering!
Offline
bharvey wrote:
@shadow and Hardmath:
Okay, I think we're ready. I've made a shared Dropbox folder called manual-pics to hold the new picture files. If you send me an email address I can invite you to it. Or if you're unhappy sharing your email and have a better idea for sharing files I'm happy to have suggestions. I'm bh@cs.berkeley.edu
A rough draft manual is at http://snap.berkeley.edu/draftManual.pdf. Part V, on sprite OOP, is going to change in yet-unknown ways and isn't implemented, so I suggest Parts I-III for shadow and Parts IV, VI-VIII for Hardmath (who gets the extra one because there's just one page in Part VIII).
To avoid confusion please use filenames in the form p43-2.png for the second picture on page 43 of the draft. PNG is preferred because it's unencumbered by patent licensing; JPG second choice and GIF third.
Try to get pictures without grey backgrounds (from palette or scripting area) unless the picture shows the entire Block Editor or input dialog window (in which case still no background outside the window) or the block's location in palette/script/etc is part of the point of the picture, as in p5-1, p6-1, and p6-3.
Suggestions about errors or confusions in the text are welcome too -- if you don't understand something, neither will new users!
And thank you so much for volunteering!
Sure, I'll work on it! How do you want me to remove the gray background? I'm not much of a graphics whiz, so I'll probably take the whole editor for all of them.
Offline
Oh yes, and about sharing: I'll post a ZIP file on my Google Docs, if you don't mind. I don't want to share my email, if that's ok with you.
Offline
Jens wrote:
Hold on! I'll let you export pictures of scripts without background, same as in Scratch... probably as soon as tonight.
I'll wait till tonight to start, then. When do we need these done?
Offline
okay, here it is:
Today's Snap! alpha build (which I've just posted) features a new "script pic" option in block's context menus.
"script pic" opens a new browser window/tab with a PNG-encoded, background-less (the background is transparent) picture of the script (stack of blocks) the block is part of. It also works for scripts in the block editor, in which case it also includes the prototype hat. You can then save the PNG to your local computer simply by right-clicking on it and using your browser's "save as..." option. I'm hoping that this feature will make exporting pictures of scripts for documentation purposes a lot easier than having to take screenshots and cropping/editing them all the time.
Enjoy, and have a nice weekend!
Last edited by Jens (2012-05-04 05:02:45)
Offline
Hey guys,
I did Part VIII because it looked quick and easy, and I wanted to try it out. Here's the link to Google Docs: Part VIII.zip. Some blocks mentioned there were not found in Snap! What do I do about those? Make custom blocks for now?
P.S. Sorry to be raising so many problems, but I am really busy next week, so maybe someone else could take over my bit (just next week). Thanks.
Last edited by Hardmath123 (2012-05-04 06:29:06)
Offline
roijac wrote:
i could do I if you want @hardmath123
![]()
We can share. There are parts 1,2,3,4,6,7 out of which shadow can do 1 and 2, you do 3 and 4, and I'll do 6 and 7 (I already did 8, and 5 isn't ready yet). How about that, bharvey and roijac?
Offline
Hardmath123 wrote:
Oh yes, and about sharing: I'll post a ZIP file on my Google Docs, if you don't mind. I don't want to share my email, if that's ok with you.
No problem. I downloaded your zip file with no problem (once I worked out why Google Docs wasn't letting me open the individual pictures, duh).
Some blocks mentioned there were not found in Snap! What do I do about those? Make custom blocks for now?
Sure, making custom blocks would be fine. (Be sure to get the input slot types right, if any.)
roijac wrote:
i could help with the in-program help dialogs
Oh, yes! That would be awesome. It's a big job, though, because they should all really be redone totally. I used a bitmap graphics program, which was all I had back then, and so the font rendering is all ugly even though I used Baskerville, the most beautiful font ever.
Thanks, gang!
Offline
Why does the manual have all the (the block) and (the script) blocks still in it? Snap! uses rings instead.
Offline
Save failed: TypeError: Object a ArgMorph 0 [580@419|12@13] has no method 'toXML'
(You should really let users copy and paste these error messages - I had to copy that out by hand)
That has happened in ALL my projects. Why?
GRR, I can't post the images because their URLs exceed the scratch forum character limit! You should REALLY write a PHP script to generate the images!
Offline
joefarebrother wrote:
Why does the manual have all the (the block) and (the script) blocks still in it? Snap! uses rings instead.
I think I've updated the text to talk about rings. But of course the pictures are still the old pictures -- that's one of the reasons we need new ones made. Anything with either a THE BLOCK/SCRIPT or a grey border needs to have a ring instead. Every picture of a solid grey input slot should be a ring instead. If you find things in the text that need changing, give me a page number and I'll do it (although not in the online draftManual.pdf because I don't want to change the page numbers in the middle of this picture project).
Offline
bharvey wrote:
joefarebrother wrote:
Why does the manual have all the (the block) and (the script) blocks still in it? Snap! uses rings instead.
I think I've updated the text to talk about rings. But of course the pictures are still the old pictures -- that's one of the reasons we need new ones made. Anything with either a THE BLOCK/SCRIPT or a grey border needs to have a ring instead. Every picture of a solid grey input slot should be a ring instead. If you find things in the text that need changing, give me a page number and I'll do it (although not in the online draftManual.pdf because I don't want to change the page numbers in the middle of this picture project).
Yes, It TALKS about rings, but SHOWS PICTURES OF (the block) and (the script)
Offline
joefarebrother wrote:
Yes, It TALKS about rings, but SHOWS PICTURES OF (the block) and (the script)
Umm... Yes, we know. This is why, as we speak, shadow and Hardmath and roijac are making new illustrations based on Snap! instead of on BYOB. Every picture will be redone; besides the rings, the block shapes are subtly different. All the tutorials have to be redone, too, eventually.
Offline
@bharvey & Jens
I come back to the issue of block ownership.
Right now, there is only one possibility : a block is owned by a sprite. If this sprite is duplicated the new sprite "inherits" this block. But if a new sprite is created it has no access to this block. We have to re-write the same block over and over for each new sprite...So we have only "local" or inherited blocks, I'm sure that you have "ideas behind your heads". In the past I had suggested to create global blocks owned by the toplevel (created from the palette like it was in the early days of Snap!). Thus, when you change this block, this change is available by all sprites using this block (which is not the case as far as remember in Byob).
Maybe that in a later stage this feature will by mimicked using Methods + attribute OF sprite ?
This toplevel feature would address the issue of "common libraries". When you save your project (with its "void" sprite) all toplevel blocks are saved and are available for a New project.
Offline
Jens wrote:
Yes, I haven't gotten around to implementing global custom blocks ("for all sprites") yet. It's on the list
![]()
Maybe all blocks created for the stage are global?
Offline