Scratch

veggieman001 wrote:

Thanks for your interest! I've been working on this for a few months now, and glad to see people like you give comments about it. 

1. I will do that. I just directly copy and pasted code on here without really modifying it too much for that.
2. There is a built in string concatenation function, but I'm trying to make this as easy for beginners as possible so I'm using the function name from Scratch. It would also be difficult for someone starting out to have two different functions, + and Join(), for the different datatypes, string and Variable.
3. loc = 0
4. I personally think, based on the current casting Scratch has, that this is how it would be done if it were possible in Scratch.
5. You may have transparent pixels but I haven't finished doing the collision for such images.

Sorry for being unclear; when I looked at the implementation of the Join() function, it looked a bit clunky (it created a two-element array and joined that together). 

The collisions between two oddly-shaped sprites might be a little messy.  I guess you can rule out collisions between objects that are more than a certain distance apart, but making code for checking each pixel of one with each pixel of another won't be fun.

ubrecma wrote:

veggieman001 wrote:

Thanks for your interest! I've been working on this for a few months now, and glad to see people like you give comments about it. 

1. I will do that. I just directly copy and pasted code on here without really modifying it too much for that.
2. There is a built in string concatenation function, but I'm trying to make this as easy for beginners as possible so I'm using the function name from Scratch. It would also be difficult for someone starting out to have two different functions, + and Join(), for the different datatypes, string and Variable.
3. loc = 0
4. I personally think, based on the current casting Scratch has, that this is how it would be done if it were possible in Scratch.
5. You may have transparent pixels but I haven't finished doing the collision for such images.

Sorry for being unclear; when I looked at the implementation of the Join() function, it looked a bit clunky (it created a two-element array and joined that together). 

The collisions between two oddly-shaped sprites might be a little messy.  I guess you can rule out collisions between objects that are more than a certain distance apart, but making code for checking each pixel of one with each pixel of another won't be fun.

Haha that's weird, must have done that a while ago when I was first starting to understand things. I'll clean that up on Monday.

And yeah, it's not going to be fun. It'll take a while to figure out something that won't be slow.

ImagineIt wrote:

Remember to add cloud variables, cloning and the motion sensor!

:L
There will likely be cloning in a future version but neither cloud variables or a motion sensor are currently planned based on needing web space to do that I don't want to program/host and being way to hard to program, respectively.

If some genius comes in here and offers to do them, fine, but I just can't do those.

Yeah, I'm going to implement cloning, but it's not on my immediate list of thingamadoodles

I've started working on documentation and casting

Bump 

slinger wrote:

Bump 

Haha, thanks.

I'm still having issues with sound in Java, and I've tried two different libraries so it's not the library. It has something to do with the getID3Tags() function of the libraries, apparently.

scratchisthebest wrote:

veggieman001 wrote:

ImagineIt wrote:

Remember to add cloud variables, cloning and the motion sensor!

:L
There will likely be cloning in a future version but neither cloud variables or a motion sensor are currently planned based on needing web space to do that I don't want to program/host and being way to hard to program, respectively.

If some genius comes in here and offers to do them, fine, but I just can't do those.

Speaking. 

I'll try the motion sensor when I have time. It'll have to use gsvideo instead of the default processing.video, because I somehow can't get .video working. 

If .video is a must, you can swap over pretty quick. Just change the import, drop the GS from things and remove cam.play().

also, can you add me on gcode for documentation? I couldn't find out how to shout at you on code, but I tried gplus. You're "Fiberglass Monkey", right?

Heyo! Thanks for being interested.
GSVideo would actually probably be better, considering that it'll be the main library in Processing 2.0 and it uses an open framework.

And I got the message and will add you. 
When you're making changes, put them in Simplicity.pde in the trunk of the source. I'll put them in Java when I have time.

I haven't pushed changes because
a) I don't know how and
b) I hit a processing bug.

costume.pde:

public class Costume {
  public PImage img, cmask;
  public int wids, heis;
  Costume (String cIm) {
    img = loadImage(cIm);
    wids = img.width;
    heis = img.height;
    cmask = createImage(img.width, img.height, RGB);
    cmask.loadPixels();
    img.loadPixels();
    for (int i = 0; i < img.pixels.length; i++) {
      if (img.pixels[i] == 60896) cmask.pixels[i] = color(#FFFFFF);
      else cmask.pixels[i] = color(#000000);
    }
  }
}

//test

I'm getting a syntax error on the last line (the comment) about an unexpected '}'. It's not even on that line.

edit: it's more fun than that.
costume.pde:

//Moving back into simplicity.pde!
//test

same thing.

edit again:
deleting costume.pde causes the error to move to sprite.pde, which moving the contents back into simplicity.pde moves the error to todo.pde. todo.pde is one big comment. deleting that moves the errro to the end of setup() in test.pde, and moving that causes...

grrmrrhrrmrrhrr
Lemme go checkout again.

Last edited by scratchisthebest (2012-06-14 11:00:52)

blob8108 wrote:

From my limited knowledge of Java syntax, should it not be:

Code:

      if (img.pixels[i] == 60896) cmask.pixels[i] = color(#FFFFFF) else cmask.pixels[i] = color(#000000);

If that still doesn't work, you could try putting braces { } around the if and else block.

Just a thought! 

It shouldn't be, actually.

And I though I had commented that part out.
Oh wait no it was only the part where it draws it.

Well, I don't mind if you comment the mask out; I was going to use it for something but I'm not anymore.

MathWizz wrote:

The #FFFFFF will throw a syntax error.

Huh?

Interesting... I thought Processing was simply a Java IDE + library with the regular Java compiler. In regular Java, #000000 would give a syntax error.

MathWizz wrote:

Interesting... I thought Processing was simply a Java IDE + library with the regular Java compiler. In regular Java, #000000 would give a syntax error.

Yeah, it's not exactly the same, although similar.