This is a read-only archive of the old Scratch 1.x Forums.
Try searching the current Scratch discussion forums.

#1 2013-01-28 10:19:06

s_federici
Scratcher
Registered: 2007-12-18
Posts: 500+

1S1S vs multiple sprites

Does anyone know of a project with a lot of similar objects (e.g. ants moving around or bouncing balls or else) that runs faster in its 1S1S version than in its multiple-sprites version?

Offline

 

#2 2013-01-28 17:19:25

blob8108
Scratcher
Registered: 2007-06-25
Posts: 1000+

Re: 1S1S vs multiple sprites

I was going to suggest looking at amcerbu's physics projects to try and find two you could compare, but I can't find a direct comparision...  smile


Things I've made: kurt | scratchblocks2 | this cake

Offline

 

#3 2013-01-28 17:23:02

mythbusteranimator
Scratcher
Registered: 2012-02-28
Posts: 1000+

Re: 1S1S vs multiple sprites

Nah, 1s1s just shows programming awepicness.  wink


http://www.foxtrot.com/comics/2012-04-01-fdb37077.gif
clicky

Offline

 

#4 2013-01-28 18:14:19

Magnie
Scratcher
Registered: 2007-12-12
Posts: 1000+

Re: 1S1S vs multiple sprites

You could probably create your own projects that do both? But I believe using multiple sprites in general is faster, you just have to maintain multiple of the same object (which will probably change thanks to cloning in 2.0).

Last edited by Magnie (2013-01-28 18:14:39)

Offline

 

#5 2013-01-28 18:16:24

technoguyx
Scratcher
Registered: 2008-10-18
Posts: 1000+

Re: 1S1S vs multiple sprites

I suppose you could avoid forever-loop-sync problems like this by designing a project as 1s1s. But then again you could do exactly the same implementing a updating cycle like this:

when gf clicked
forever
    set [timer_init v] to (timer)
    broadcast [update v] and wait
    broadcast [render v] and wait
    repeat until <((timer_init) - (timer)) > ([1] / [60])> //60 FPS
        wait [0] secs
    end
end
(I haven't tried it myself; read it from someone in these forums)

_________________
Yay for new posts while previewing  tongue  As Magnie said, it's way better to manage similar sprites as one sprite that is stamped.


http://getgnulinux.org/links/en/linuxliberated_4_78x116.png

Offline

 

#6 2013-01-29 08:57:07

s_federici
Scratcher
Registered: 2007-12-18
Posts: 500+

Re: 1S1S vs multiple sprites

Magnie wrote:

I believe using multiple sprites in general is faster

Yes. For every other programming language using sprites would be slower (it requires a considerable overhead) but, as Scratch lists are much slower than handling sprites (and you need lists to store all the necessary information), in the end multiple sprites are faster than 1S1S.

Offline

 

#7 2013-01-30 04:28:56

s_federici
Scratcher
Registered: 2007-12-18
Posts: 500+

Re: 1S1S vs multiple sprites

s_federici wrote:

Scratch lists are much slower than handling sprites (and you need lists to store all the necessary information), in the end multiple sprites are faster than 1S1S.

Unfortunately, this isn't good for me when I have to show why the majority of programming languages are heavily 1S1S (1 thread) and not based on multiple threads instead...

Offline

 

Board footer