Scratch

I know. There's supposed to be a limit so you can't lose sprites off-screen, but it only makes things harder, especially scrolling projects (and pen projects).

OK - here's an example of it cropping up in a 3D Racer I started coding.



OK - that last one is an actual engine bug (still need to fix some problems...) but all the others are really annoying. I can rotate the camera and show you the horror, but I'm too lazy. The engine works REALLY smooth otherwise (15 fps I'd estimate. Much faster than LINE tennis.

Last edited by RHY3756547 (2010-01-19 18:17:39)

Lucario621 wrote:

RHY3756547 wrote:

OK - here's an example of it cropping up in a 3D Racer I started coding.

http://i364.photobucket.com/albums/oo85 … 547/EX.gif

OK - that last one is an actual engine bug (still need to fix some problems...) but all the others are really annoying. I can rotate the camera and show you the horror, but I'm too lazy. The engine works REALLY smooth otherwise (15 fps I'd estimate. Much faster than LINE tennis.

(off-topic) Looks like a cool game!

(on-topic) Can you have it just have it render it with a limit of 180 and 240, while keeping the same slope?

You can't. The engine's limitations automatically snap any values outside the level to ones inside it.

MyRedNeptune wrote:

Scratch is an educational program aimed mostly at children... kids could get confused if they lose a sprite off-screen. 

I do agree though. Perhaps there could be a way to move sprites off-screen without losing them. (for example, being able to pan the view off the screen)

Well, you can always use the sprite bank and use the go-to block to make it go to coordinates 0, 0...

cocoanut wrote:

MyRedNeptune wrote:

Scratch is an educational program aimed mostly at children... kids could get confused if they lose a sprite off-screen. 

I do agree though. Perhaps there could be a way to move sprites off-screen without losing them. (for example, being able to pan the view off the screen)

Well, you can always use the sprite bank and use the go-to block to make it go to coordinates 0, 0...

Well, small children might not know that. 

fanofcena wrote:

MyRedNeptune wrote:

cocoanut wrote:

Well, you can always use the sprite bank and use the go-to block to make it go to coordinates 0, 0...

Well, small children might not know that. 

If they use scratch they should be able to know that 

Scratch is an introduction to programming. The Scratch Team tries to keep it as simple as possible.

And we're talking about like, 6-year-olds here as well. 

RHY3756547 wrote:

fanofcena wrote:

um i have a suggestion instead of private scratch variables use ur own positional variables believe me it solves the problem.

As soon as you hit the go to button even with variables it snaps to screenspace.

Its impossible i think thats a bug with ur programming check the algorithms once again
as this will work only with points ie sprites cant be use sprites ie a point  will be used to render line to generate graphics.

can u show the rendering code once

@ MRN,
well 6 year old kids cannot programm something to make the thing go out of screen
well either thier can be a button to release all the limits from the sprites for pros

Last edited by fanofcena (2010-01-20 02:51:35)

well u just need to tell the sprite where it should intersect with screen boundary if its out of screen thats it that can be done by mathematics. cant u when u r done it is like
set x to intersect pos
set y to intersect pos
and it will be gone

I support this. It's generally useless and you can always get your sprites back whence they are gone just by sending them to 0,0.

It would be nice to have the ability to have sprites go off-screen, especially considering how easy it is to get a sprite back to the center of the stage with the use of the "go to X:_ Y:_" block. (Of course, adding a button that allows for a sprite to return to the center of the screen would make it easier for the younger users who otherwise don't realize how to get a sprite back on the screen).

fanofcena wrote:

RHY3756547 wrote:

fanofcena wrote:

um i have a suggestion instead of private scratch variables use ur own positional variables believe me it solves the problem.

As soon as you hit the go to button even with variables it snaps to screenspace.

Its impossible i think thats a bug with ur programming check the algorithms once again
as this will work only with points ie sprites cant be use sprites ie a point  will be used to render line to generate graphics.

can u show the rendering code once

@ MRN,
well 6 year old kids cannot programm something to make the thing go out of screen
well either thier can be a button to release all the limits from the sprites for pros

You clearly don't understand.

If you ask a sprite to go to x: 400 y: 600, it will end up just going to x: 180 y:240. The same for pen, so it messes up the picture.

Well anyways rhy i found out whats wrong just to make sure arent u using the track to rotate on an axis of itself it should rotate on the car . I did reverse mathematics from the Gif to figure this out.