Color-based sensing, is when a sprite senses a wall or object or something, bu using the <if color [] is touching color []> or <if touching color []> blocks. Its the most basic method of sensing, as it is simple to do. For those who don't know about any other methods of sensing, or want to know more about them, here's some quick descriptions.
Sprite-based sensing, is when there is 4 or more alternate sprites other than the main character which sense each side of the character, using a variable, such as leftHitTest, rightHitTest, downHitTest, and upHitTest. Each sprite always goes to the position of the main character, and if it is touching another object or color then it sets it's variable to 1, or else 0, like a boolean. And of course these sensors are with 100% Ghost Effect on. The player uses these variables to help it's movement.
Array-based sensing, is the most uncommon, and is where there is a list of positions of where every block on the level is, and the character uses that list, with it's x and y position to determine if it is touching the wall. This is what I use for my One-Sprite One-Script Level Creator Player, my Mario Level Creator Player, and my Lego Level Creator Player.
Now let's compare then, with some pros and cons.
Color-Based Sensing
+Simple and easy to implement
-Inaccurate
-Looks weird when a sprite isn't supposed to have those colors on it.
Sprite-Based Sensing
+More accurate than Color-Based Sensing
+Still somewhat to implement.
-Slightly more laggy.
-When you press the stop button, the ghost effect goes away so you can see the sensors.
Array-Based Sensing
+Very accurate
+Just as, maybe a bit less laggy than sprite-based sensing
+Can create level creators and level codes with
-Difficult to implement
-Only works in some situations.
So I want to hear your opinions. Do you think Color-Based Sensing is all that great? Whats your opinion on the other sensing methods?
Discuss.
In my opinion, color-based sensing is bad to use, and is just a don't. For your first couple of games, sure, but at least grow into the sprite-based sensing. For most games, I recommend just sprite-based sensing. In other situations though, you can use Array-Based Sensing, but rarely, so for the most part, skip that.
Offline
Colour based sensing is MUCH faster than normal sensing, becuse it doesn't have to detect for pixel perfect collision for all the sprites to be collided with.
The "If Touching" Block lags. A lot. With pixel perfect sensing comes a hefty price, speed. You may have noticed that games that use a lot of hit-tests (archmage games) run slowly outside presentation mode because of this.
Array based sensing is very impractical in scratch. Why? Because of lack of support for multi-dimentional arrays. People have to emulate multidimensional arrays, which also comes at a price.
Offline
I just use whatever is best in the situation.
Offline
There is a method where you have a sprite with a costume without the color sensing, and a costume that has the color sensing over it. Start it with the costume on color sensing, implement the sense scripts, and switch it back to the normal costume.
It's fast, its easy, and it doesn't have those weird colors over it.
Problem solved
Last edited by Kileymeister (2010-01-11 16:54:22)
Offline
Kileymeister wrote:
There is a method where you have a sprite with a costume without the color sensing, and a costume that has the color sensing over it. Start it with the costume on color sensing, implement the sense scripts, and switch it back to the normal costume.
It's fast, its easy, and it doesn't have those weird colors over it.
Problem solved![]()
Aha - but everything that happens in scratch has a cost. Switching costumes is one of them.
Offline
And also I hate how everyone uses Hit-tests. You DO NOT ever need them.
Just move x-velocity, check for X-collisions then move Y-velocity, check for Y collisions. You can get whether it's up/down from the starting veloicity.
Last edited by RHY3756547 (2010-01-11 17:02:58)
Offline
RHY3756547 wrote:
And also I hate how everyone uses Hit-tests. You DO NOT ever need them.
Just move x-velocity, check for X-collisions then move Y-velocity, check for Y collisions. You can get whether it's up/down from the starting veloicity.
I noticed that when i was programming NinjaX
Offline
RHY3756547 wrote:
Kileymeister wrote:
There is a method where you have a sprite with a costume without the color sensing, and a costume that has the color sensing over it. Start it with the costume on color sensing, implement the sense scripts, and switch it back to the normal costume.
It's fast, its easy, and it doesn't have those weird colors over it.
Problem solved![]()
Aha - but everything that happens in scratch has a cost. Switching costumes is one of them.
Yeah, but its instantaneous. No one notices. At least with my method its instantaneous. How is switching costumes a cost?
Offline
Kileymeister wrote:
RHY3756547 wrote:
Kileymeister wrote:
There is a method where you have a sprite with a costume without the color sensing, and a costume that has the color sensing over it. Start it with the costume on color sensing, implement the sense scripts, and switch it back to the normal costume.
It's fast, its easy, and it doesn't have those weird colors over it.
Problem solved![]()
Aha - but everything that happens in scratch has a cost. Switching costumes is one of them.
Yeah, but its instantaneous. No one notices. At least with my method its instantaneous. How is switching costumes a cost?
The scratch engine has to interpret mode code AND it has to rerender the scene. With enough, the game will become jittery.
Last edited by RHY3756547 (2010-01-11 17:08:16)
Offline
RHY3756547 wrote:
Kileymeister wrote:
RHY3756547 wrote:
Aha - but everything that happens in scratch has a cost. Switching costumes is one of them.Yeah, but its instantaneous. No one notices. At least with my method its instantaneous. How is switching costumes a cost?
The scratch engine has to interpret mode code AND it has to rerender the scene. With enough, the game will become jittery.
Yeah but no one cares. It runs fine with switching costumes.
Offline
RHY3756547 wrote:
Colour based sensing is MUCH faster than normal sensing, becuse it doesn't have to detect for pixel perfect collision for all the sprites to be collided with.
The "If Touching" Block lags. A lot. With pixel perfect sensing comes a hefty price, speed. You may have noticed that games that use a lot of hit-tests (archmage games) run slowly outside presentation mode because of this.
Array based sensing is very impractical in scratch. Why? Because of lack of support for multi-dimentional arrays. People have to emulate multidimensional arrays, which also comes at a price.
You know too much. Shoo shoo away!
j/k
But lolz is this basically common knowledge for every programming language? Because you sure know a lot lolz >.>
Based on what I've read so far, your new motto is "which comes at a price". Seriously it feels like you've said that 3 times.
Last edited by Lucario621 (2010-01-11 17:13:03)
Offline
Kileymeister wrote:
RHY3756547 wrote:
Kileymeister wrote:
Yeah, but its instantaneous. No one notices. At least with my method its instantaneous. How is switching costumes a cost?The scratch engine has to interpret mode code AND it has to rerender the scene. With enough, the game will become jittery.
Yeah but no one cares. It runs fine with switching costumes.
![]()
I care.
Every fps lost from scratch's low max fps of 40 makes me cry. :'(
Offline
Colour sensing is good if the colour doesn't look out of place. If you have purple lines everywhere then it looks unprofessional.
Sprite based sensing is good for testing collisions at specific points but it does lag a bit.
Array sensing is good for many programming languages, but not scratch. There is no reason I can think of to use array based sensing in large scrolling levels. Its hard to code and laggy.
Offline
RHY3756547 wrote:
Kileymeister wrote:
RHY3756547 wrote:
The scratch engine has to interpret mode code AND it has to rerender the scene. With enough, the game will become jittery.Yeah but no one cares. It runs fine with switching costumes.
![]()
I care.
![]()
Every fps lost from scratch's low max fps of 40 makes me cry. :'(
The max is only 40???
So THAT's why my huge game Disaster can only run at 17 fps...
Offline
I've used color collision in Sphered, PapiJump, and iCopter. I find it more useful, as I want to try and eliminate lag in my games.
Offline
Kileymeister wrote:
RHY3756547 wrote:
Kileymeister wrote:
Yeah but no one cares. It runs fine with switching costumes.![]()
I care.
![]()
Every fps lost from scratch's low max fps of 40 makes me cry. :'(The max is only 40???
So THAT's why my huge game Disaster can only run at 17 fps...
Actually - that's the interpreter not being able to keep up with the lowly framerate of about 40.
The scratch team have plenned to meke every part of scratch online (including the editor) by v2.0, which will mean it will all be Java, so why not make scratch compile applications into java? It would lose the lag of the interpreter (basically ALL of the lag) and would allow for more graphically intense games with the CPU processing use lower.
Offline
RHY3756547 wrote:
And also I hate how everyone uses Hit-tests. You DO NOT ever need them.
Just move x-velocity, check for X-collisions then move Y-velocity, check for Y collisions. You can get whether it's up/down from the starting veloicity.
I think that it may be my fault that people use those, since a lot of people learn how to do that from my projects. The reason I do collisions like that is because that is how I learned how to make collisions for platformers in actionscript. In actionscript there is a command called a shapeflag hit test that lets you check for collisions at specific coordinates. Since scratch doesn't have a shape flag hit test or something similar I used sprites.
Sorry for promoting sloppy code, maybe you can code a platformer engine that doesn't use sprites for collisions and I can refer people to that one instead.
Offline
Lucario621 wrote:
But lolz is this basically common knowledge for every programming language? Because you sure know a lot lolz >.>.
No, this isn't common knowledge for programmers. You only start to become concerned with things like collision testing when you start to make games which is something a lot of programmers (at least the ones I know) don't get too much into.
Scratch is shallow enough to understand everything pretty quickly if you already know programming.
Offline
floatingmagictree wrote:
I've used color collision in Sphered, PapiJump, and iCopter. I find it more useful, as I want to try and eliminate lag in my games.
Except I didn't like Sphered because you didn't change the costume from color-sensing to regular and back or make it roll. >.> I liked fg123's method.
Please leave a message at the beep.Offline
I like color based sensing, but when you use common colors, you have to make all the other sprites weird colors.
Offline
that's why you should use both color and sprite sensing. if there's like a fighting game, and you put 'if touching sprites', when you're attacking, and the opponent also happens to attack like 2 seconds later, you'll both be considered hit.
Offline