Scratch

Jpg is entirely unsupported, png I believe is only partially supported. And I also like the challenge except when I have to spend hours making the ability to type or getting a scrolling engine to work. And in case you're wondering, this isn't my main account so I don't have any projects.

SkyWrecker wrote:

I understand that Scratch is made to be uncomplicated and easy to use, but the pointless restrictions and lack of access to basic utilities really hold it back and make creating worthwhile projects very difficult. By utilities I mean date, time, etc and as for restrictions, they are needlessly placed throughout Scratch. For example, why can't a sprite go too far off the screen? And for that matter why is the screen so small? 480x360px is smaller than a low end smartphone screen's resolution.
   Also, there are so many visual restrictions such as inability to change how lists, variables and other basic readouts look. Even the Scratch engine itself is not very good with handling even basic tasks. Any form of transparency slows it down drastically and even a simple project will run at 45fps maximum. Since there are so many things I'd like to see added that still weren't present in the Scratch 2.0 demo, I'll just make a list:

-Access to all keys (pointless not to have as it does not make it complicated)
-Access to basic information (Date, time, etc)
-Partial transparency
-Larger display size
-Customizable readouts
-Built in typing script so as not to have to spend hours making one for each project
-No limits in distance off screen that sprites can go
-Better engine or at least an explanation as to why the current one is so slow
-Ability to show/hide mouse pointer
-Ability to change mouse appearance
-Support for all image file types
-Better hit detection

Feel free to mention anything I missed.

for number 1 they made it that way so it would be able to support tablets in the future.

Scratch 2.0 will be in flash so there will be a faster engine.

Jpg is not supported, for a test project that I made the visuals for in Photoshop, all of the sprites were Jpg and the majority of them changed size, position or both when I uploaded it. As for them making the screen small to fit tablets, the iPad is 2048x1536 and 264 dpi... which comes out to being about 10 times the size Scratch allows.

Jackieee wrote:

SkyWrecker wrote:

-Access to all keys (pointless not to have as it does not make it complicated)
I do agree that more keys should be available, but there's also the issue of different keyboards for different OSes, etc.

-Access to basic information (Date, time, etc)
Agreed.

-Partial transparency
Scratch 2.0 uses vector graphics and also supports partial transparency for imported PNG images.

-Larger display size
I don't really think this is needed. The size of the stage in Scratch is about the size of a regular Flash game, and that's about how complex Scratch projects are.

-Customizable readouts
Agreed.

-Built in typing script so as not to have to spend hours making one for each project
What do you mean? Having a text-based version of Scratch? I agree with that.

-No limits in distance off screen that sprites can go
I'm not sure why you'd need this... can you explain?

-Better engine or at least an explanation as to why the current one is so slow
Scratch 2.0's Flash player is much faster than what's currently available, and the unofficial Javascript player sb2.js is a ton faster than the Flash player.

-Ability to show/hide mouse pointer
Disagreed.

-Ability to change mouse appearance
Disagreed.

-Support for all image file types
I've never had an issue with any file types I've imported...

-Better hit detection
I don't understand what you mean by "better"... what needs to be better?

The small display size is really only a problem because you must have an extremely small font to fit a lot of text, or you must make a scrolling engine which is difficult because of screen limits. By that I mean, you can't make a sprite go off screen and keep going forever. It must stop at some point, however that point is fairly close to the edge. For example, a scrolling engine must have scripts that make the frames layer properly, hide when they reach the edge, etc. If there was no limit, it could just keep going and wouldn't need to hide. Also, you're limited to sprites the size of the screen so you must have numerous sprites to scroll a great distance.
   By better hit detection I meant that Scratch doesn't generally register when a small sprite quickly passes through something it should collide with, though it is probably just because of the slow engine. And for typing script I meant the ability to change a variable or add to a list the name of the key you hit, which generally requires making a script for each individual key. I don't know what you meant by different keys for different OSes since every OS has the same keys, but I think we should at least have access to Shift, Ctrl, Enter and all of the other function keys.

My point really was just that there are unnecessary handicaps put on Scratch, namely the sprite size limits, inability to go too far of screen and the lack of access to every key.

I know there are many more versatile and more advanced programming languages but none that I know of with the ability to share what you make with everyone and everyone being able to play around with it an see how it works.