User:Horganick

From IPRE Wiki
Jump to: navigation, search

Summer 2013 Research

Sprites for Ego Syntonic Learning in Computer Science Education

module documentation here


June

Up to June 10th

June 11th

  • Create a new Sprite class which may contain several images called "costumes" to display the Sprite with. (The static methods call the public methods of this class)

TODO

DONE - needs to be tested more, will do this tomorrow 
DONE - need to find similar sized, transparent pngs to use for the different costumes 
DONE - Consider: outline for all Sprite functionality, how will I integrate pygame, collections
- schedule for the rest of the summer

June 12th

  • Sprites Class update continued.
  • Current Sprites Module Documentation here. This will be merged with the documentation on the Calico website after the next update.
  • Sprites Module Functionality TODO here.
DONE -all costumes must be changed every time the current costume is changed.

TODO

DONE - commit first update to bitbucket
DONE - keep track of all actions performed on the sprites so that when a costume is added mid-program, 
it will be in correct location
- show available costumes and their ID numbers in the tab underneath the sketch window
- Consider: costumes currently added in an OOP fashion; that is, if the user adds a costume to sprite1, sprite2 
cannot wear that costume. consider storing all costumes in a static library?
          -No, should still be OOP because each sprite has a different location/orientation, likewise its costumes 
          (which are really just Graphic.Pictures) should have different location/orientation.  Storing in one static 
          library would assume that they all had the same location/orientation, right?
                     - 7/3/13 No, the library could be static since we are changing the changeCostume() function.                          
                       If we go through with the displaying all possible costumes then we should use a static 
                       library (otherwise it would be confusing for students to think a costume was available when 
                       it was actually only attached to a particular sprite)
                       BUT what if you want two sprites to be in different locations with the same costume.  If the 
                       pictures are static then they can't be in different locations at the same time.  So perhaps 
                       there could be a pane for the default costumes and a pane for the user-added costumes (which 
                       might only be available to some of the sprites)


June 13 and 14th

  • Good progress on designing the new event manager. Current plan: do initial implementation in Python, see how it works, then go back to C# & Jigsaw.
DONE - make example scripts for presentation
DONE - start sketching out event manager
DONE - completely change current costuming system (take out the for loops)
DONE - make new documentation system for features todo list

June 17th

  • Working on taking out all the for loops in Sprite but running into some issues with the transparency and vertical/horizontal flipping.

June 18th

  • Sick; working at home on laptop on the looping problem in Python

June 19th

  • Decided I need a queue of past flipping/rotation actions for the Sprites (as opposed to just looking at the latest _rotation and number of past vertical or horizontal flips). Started working on this in Python.

Notes: Complete the action immediately and put the action in storage. When we want to undo everything we will complete the actions in storage in LIFO order. We will make a negative rotation for each positive rotation and vice versa. This seems easy enough for vertical and horizontal flips but it seems that the rotations might need to be stored differently since they have a parameter. Perhaps two different structures... And it might be easier to store keys that represent the methods instead of the methods themselves.

  • Done initial implementation in Python. Rotations and vertical/horizontal flips appear to work correctly. rotateTo() method still needs adjusting. Need to figure out nested classes so I can put the ImageManager class inside the Sprite class.

June 20th

  • Part of the problem seems to be that rotate() and rotateTo() work on different coordinate systems. rotate() has 0 at the top and 90 to the left while rotateTo() has 0 at the top and 90 to the right.
  • In order to undo a rotateTo() command we must store the sprite's rotation before rotateTo() is applied.

June 24th

  • All rotations and flips seem to be working correctly, now will focus on converting to C# and integrating ImageManager with the Sprite class
  • current implementation here
  • Need a way to pass methods in C#. Func doesn't seem right because it requires only one parameter.
  • Action / Delegates???

June 25th

June 26th

  • Getting stuck with the conversion to C#, will go back to working on more Sprite-related stuff like the glide and sound functions.
  • Potential Glide problem: Initial implementation is to just slowly move the Sprite forward with a loop and the wait() function. You can't set a Sprite to glide across the screen and then move control to the next function (you would have to wait for the gliding to finish). Any way to avoid this? Ie have some other thread working on moving the Sprite slowly across; meanwhile control has moved on passed the glide() call

Even if this isn't a problem though, it doesn't work very intuitively with multiple scripts-- if you create multiple threads with a different Sprite in each one, and you want all the Sprites to glide at the same time you won't be able to do that (because they would have to glide one at a time). ALSO an even bigger problem with the multiple threads is that since its non-OOP you have to selectSprite(>name<) every time you want a specific sprite to do something. BUT since control keeps switching between the threads, you can never select() and then immediately do the thing you wanted to do. Instead, you select(), control switches to other threads, .... then you get back to the thing you wanted to do but by then your sprite may have been affected by the other threads when it wasn't supposed to be. This should be helped by the tell-to block that is in progress (but we should find something to help the non-OOP programmers).

June 27th

  • Gliding basically done (should test more)
  • Simply creating a sprite that will serve as the background is not sufficient since it draws over the other sprites. In addition, it seems like other sprites cannot be drawn onto the background sprite since it is not of the Window class.

June 28th

  • Backdrops done. Example backdrop .pngs are not that great so they should be changed later.
  • Basic speech bubbles and speaking done.

June 30th

  • Major problem--- the dictionary of sprites is static so sprites stay there after the window is closed. I would like to have a function that is called when the window is closed which clears the dictionary. Then students will not be able to select sprites which were created and edited in previous sketches.


July

July 1st

  • Meeting at Sarah Lawrence College
  • Think about message system in terms of ROS (Subscribe/Publish/Service)
  • Ability to broadcast over chat from one computer to another
  • Integrated costume editor

July 2nd

  • looping problem fixed (without the elaborate undo/redo)
  • static dictionary is cleared correctly
  • can change whether or not sprites will be visible on creation
  • can remove sprites but left it so that init() automatically creates "Sprite1"
TODO fix alpha issues and/or change .pngs so that they become transparent properly
TODO fix rotation bug in Graphics module
DONE change color of text white

July 3rd

  • new Issue/Update tracker
  • working on copySprite(string otherSpriteName) now. Considering name change, does copySprite sound like it is going to copy the object's contents or that one sprite is going to copy the movements of the other sprite? Perhaps imitateSprite(string otherSpriteName) would be better. --- DONE
TODO update the Sprite documentation and merge module to Calico main branch (or at least start updating the documentation so that it won't all be left until the end of the summer)
DONE background and basic music functionality
DONE (ish) volume control

July 5th

  • worked on volume control, see issue #10 for more details (moderate bug)
  • worked on a basic collision but having some problems testing... too slow in jigsaw so converted to python but the python makes the infinite loop quit?

July 8

  • Posse workshop and TA office hours
  • event brainstorming ---> Doug is working on C# implementation

July 9

DONE change costume/backdrop access by name instead of index
DONE throw errors?
DONE make text be white
DONE documentation online before conference!!!!!!!!!!!!!!!
DONE examples in jigsaw
DONE examples in python

//Scratch work

subscribe("Ally", "mouseClick", MyProc)
public void subscribe(string spriteName, string message, Func<object,Event,object> procedure) {
Sprite sprite = getSprite(spriteName);
if (message == "mouseClick")
sprite.onMouseClick += procedure;
}

July 10th

Busy day--- made a bunch of examples, have been doing some error checking. Would like to add more sounds but the ones I got from here caused a bunch of errors?


July 18th

Back from the conference, lots of updates!

  • addBackground() and addCostume() now are used for when the image is not in examples/images/SpritesModule/backgrounds or examples/images/SpriteModule/costumes
  • everything in the above folders is automatically loaded
  • sound paths in examples/sounds are automatically loaded -->bug with addSound() though, see issue #20


TODO

  • need versions of documentation now that the Sprite Module has been officially released.
  • replace currentCostume with a new image instead of all the stuff happening in changeCostume()
  • fix transparency and rotation bugs
  • pygame like functionality
  • subscriptions
  • email Alexander Repenning about papert / body syntonicity --- references besides Mindstorms?
  • REMEMBER TO UPDATE EXAMPLES according to new code


July 19th

Started working on adding in subscribe to the events module. Not going well.

This no longer works, perhaps because of updates to the Graphics and Events modules:

import Myro
import Graphics
import Events

Events.init()

win = Graphics.Window("Test", 600, 300)
circle1 = Graphics.Circle((100, 100), 50)
circle1.draw(win)
circle2 = Graphics.Circle((400, 100), 50)
circle2.draw(win)
square = Graphics.Rectangle((200, 100), (300, 200))
square.draw(win)

def message3(o, e):
    print("You clicked me!")

def message4(o, e):
    print("You clicked me too!")

def message5(o, e):
    print("motion:" + str(e))

circle1.subscribe("mouse-press", message3)
circle2.subscribe("mouse-press", message4)

circle2.subscribe("mouse-motion", message5)
square.subscribe("mouse-motion", message5)


This should at least trigger code but it doesn't-- maybe I'm not using it right?

import Events

def code():
    print("in code()")

def main():
    Events.subscribe("fakeMessage", code)
    Events.publish("fakeMessage")

main()


This causes an immediate crash-- perhaps because the events module is initialized within Sprites?

import Sprites
import Events


def code():
    print("in code()")

def main():
    Sprites.init()
    Events.subscribe("fakeMessage", code)
    Events.publish("fakeMessage")

main()


  • also problems with syncing IPRE's Calico with the July repository. Created a temporary repository to work with until I can figure out how to resolve git conflicts.
  • Note that the first example works with older versions of IPRE's Calico.


July 22nd

  • Field trip with Summer Science Research program



August

August 12th

  • major changes to Sprites Module
  • Sprite now a part of Graphics Module, Sprites Module includes a more specialized Sprite Class and the Group Class
  • Events Module basically done
  • Animation good (ish)
  • working on poster and examples now


  • screen shot of an example game:

GameIntro.gif