Last 7 days

• Dec 11, 2009

  r880 (If the window was in fullscreen, and it loses focus, get out...) committed by facundobatista   -   If the window was in fullscreen, and it loses focus, get out of fullscreen mode or the user will get stuck there.

  If the window was in fullscreen, and it loses focus, get out of fullscreen mode or the user will get stuck there.

Earlier this year

• Nov 05, 2009

  issue 130 (51 of the demos die with "pyglet.gl.lib.GLException: None" ...) commented on by stu.axon   -   OK, heh - maybe last comment a bit lazy... Ran all the tests listed above and they all work fine.... :-D

  OK, heh - maybe last comment a bit lazy... Ran all the tests listed above and they all work fine.... :-D
• Nov 05, 2009

  issue 130 (51 of the demos die with "pyglet.gl.lib.GLException: None" ...) commented on by stu.axon   -   OK, tried the first couple of tests with latest svn and they seem to be working :) Will try and do some development with cocos2d and see what happens....

  OK, tried the first couple of tests with latest svn and they seem to be working :) Will try and do some development with cocos2d and see what happens....
• Nov 04, 2009

  issue 131 (Can't see text written in built in python interpreter) Status changed by lucio.torre   -  

  Status: Fixed

  Status: Fixed
• Nov 02, 2009

  issue 131 (Can't see text written in built in python interpreter) commented on by napalumbo   -   I was using 0.3.0rc0. This is fixed in 0.3.0. Please change the state to closed

  I was using 0.3.0rc0. This is fixed in 0.3.0. Please change the state to closed
• Nov 02, 2009

  issue 131 (Can't see text written in built in python interpreter) reported by napalumbo   -   What steps will reproduce the problem? 1. Press ctrl + i 2. write quit() 3. see no text on screen but anyway the app stops because we have written quit() What is the expected output? What do you see instead? See the "quit()" text on the screen. No text What version of the product are you using? On what operating system? 0.3.0 Please provide any additional information below.

  What steps will reproduce the problem? 1. Press ctrl + i 2. write quit() 3. see no text on screen but anyway the app stops because we have written quit() What is the expected output? What do you see instead? See the "quit()" text on the screen. No text What version of the product are you using? On what operating system? 0.3.0 Please provide any additional information below.
• Oct 28, 2009

  issue 121 (AssertionError: Backslashes not permitted in relative path) commented on by stu.axon   -   Sorry, I should've mentioned I'm running Vista 32bit, not 64bit like the similar problem there was before.

  Sorry, I should've mentioned I'm running Vista 32bit, not 64bit like the similar problem there was before.
• Oct 28, 2009

  issue 130 (51 of the demos die with "pyglet.gl.lib.GLException: None" ...) reported by stu.axon   -   What steps will reproduce the problem? 1. In order to run anything I first had to workaround the bug mentioned here (remove the assert in pyglet): http://code.google.com/p/los-cocos/issues/detail?id=121&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Component 2. Try running various demos and notice the same error. tetrivec does it when you start the game, as do various demos. Here is the output from test_3d_fullscreen.py Traceback (most recent call last): File "test_3d_fullscreen.py", line 48, in <module> director.run (main_scene) File "..\cocos\director.py", line 287, in run event_loop.run() File "c:\usr\python25\lib\site-packages\pyglet\app\win32.py", line 63, in run self._timer_func(0, 0, timer, 0) File "c:\usr\python25\lib\site-packages\pyglet\app\win32.py", line 84, in _timer_func sleep_time = self.idle() File "c:\usr\python25\lib\site-packages\pyglet\app\__init__.py", line 187, in idle dt = clock.tick(True) File "c:\usr\python25\lib\site-packages\pyglet\clock.py", line 698, in tick return _default.tick(poll) File "c:\usr\python25\lib\site-packages\pyglet\clock.py", line 295, in tick item.func(delta_t, *item.args, **item.kwargs) File "..\cocos\cocosnode.py", line 688, in _step action.step(dt) File "..\cocos\actions\base_actions.py", line 101, in step self.update( min(1, self._elapsed/self.duration ) ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 346, in update self.actions[ found ].start() File "..\cocos\actions\basegrid_actions.py", line 123, in start self.target.grid.init( self.grid ) File "..\cocos\grid.py", line 81, in init self.grabber.grab(self.texture) File "..\cocos\framegrabber.py", line 132, in grab self.fbuf.texture2d (texture) File "..\cocos\gl_framebuffer_object.py", line 70, in texture2d texture.level) File "c:\usr\python25\lib\site-packages\pyglet\gl\lib_wgl.py", line 94, in __call__ result = self.func(*args, **kwargs) File "c:\usr\python25\lib\site-packages\pyglet\gl\lib.py", line 105, in errcheck raise GLException(msg) pyglet.gl.lib.GLException: None I tried running all the demos, and there were 51 with the same error: test_3d_fullscreen.py test_accel_amplitude.py test_accel_deccel_amplitude.py test_camera_orbit_with_grid.py test_corner_swap.py test_fadeouttiles_bl.py test_fadeouttiles_down.py test_fadeouttiles_tr.py test_fadeouttiles_up.py test_flip.py test_flip_x.py test_flip_x_3d.py test_flip_y.py test_flip_y_3d.py test_grid_effect_in_layer.py test_grid_effect_in_sprite.py test_jumptiles3d.py test_lens_3d.py test_liquid_16_x_16.py test_move_corner_down.py test_move_corner_up.py test_multiple_grid_effects.py test_quadmoveby.py test_reuse_grid.py test_ripple3d.py test_shaky3d.py test_shakytiles3d.py test_shattered_tiles_3d.py test_shuffletiles.py test_skew_horizontal.py test_skew_vertical.py test_stop_grid.py test_transition_corner_move.py test_transition_envelope.py test_transition_fadebl.py test_transition_fadetr.py test_transition_fadeup.py test_transition_flipx.py test_transition_flipy.py test_transition_flip_angular.py test_transition_shuffle.py test_transition_splitcols.py test_transition_splitrows.py test_transition_turnofftiles.py test_turnoff_tiles.py test_twirl.py test_waves.py test_waves3d.py test_wavestiles3d.py test_waves_horizontal.py test_waves_vertical.py I also found a couple of other exceptions: test_reverse_time.py Traceback (most recent call last): File "test_reverse_time.py", line 29, in <module> main_scene.do( flip + ReverseTime(flip) ) NameError: name 'ReverseTime' is not defined test_remove_add_by_name.py. Traceback (most recent call last): File "test_remove_add_by_name.py", line 25, in <module> main_scene.add( color, name='color' ) File "..\cocos\cocosnode.py", line 374, in add raise Exception("Name already exists: %s" % name ) Exception: Name already exists: color

  What steps will reproduce the problem? 1. In order to run anything I first had to workaround the bug mentioned here (remove the assert in pyglet): http://code.google.com/p/los-cocos/issues/detail?id=121&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Component 2. Try running various demos and notice the same error. tetrivec does it when you start the game, as do various demos. Here is the output from test_3d_fullscreen.py Traceback (most recent call last): File "test_3d_fullscreen.py", line 48, in <module> director.run (main_scene) File "..\cocos\director.py", line 287, in run event_loop.run() File "c:\usr\python25\lib\site-packages\pyglet\app\win32.py", line 63, in run self._timer_func(0, 0, timer, 0) File "c:\usr\python25\lib\site-packages\pyglet\app\win32.py", line 84, in _timer_func sleep_time = self.idle() File "c:\usr\python25\lib\site-packages\pyglet\app\__init__.py", line 187, in idle dt = clock.tick(True) File "c:\usr\python25\lib\site-packages\pyglet\clock.py", line 698, in tick return _default.tick(poll) File "c:\usr\python25\lib\site-packages\pyglet\clock.py", line 295, in tick item.func(delta_t, *item.args, **item.kwargs) File "..\cocos\cocosnode.py", line 688, in _step action.step(dt) File "..\cocos\actions\base_actions.py", line 101, in step self.update( min(1, self._elapsed/self.duration ) ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 348, in update self.actions[ found ].update( new_t ) File "..\cocos\actions\base_actions.py", line 346, in update self.actions[ found ].start() File "..\cocos\actions\basegrid_actions.py", line 123, in start self.target.grid.init( self.grid ) File "..\cocos\grid.py", line 81, in init self.grabber.grab(self.texture) File "..\cocos\framegrabber.py", line 132, in grab self.fbuf.texture2d (texture) File "..\cocos\gl_framebuffer_object.py", line 70, in texture2d texture.level) File "c:\usr\python25\lib\site-packages\pyglet\gl\lib_wgl.py", line 94, in __call__ result = self.func(*args, **kwargs) File "c:\usr\python25\lib\site-packages\pyglet\gl\lib.py", line 105, in errcheck raise GLException(msg) pyglet.gl.lib.GLException: None I tried running all the demos, and there were 51 with the same error: test_3d_fullscreen.py test_accel_amplitude.py test_accel_deccel_amplitude.py test_camera_orbit_with_grid.py test_corner_swap.py test_fadeouttiles_bl.py test_fadeouttiles_down.py test_fadeouttiles_tr.py test_fadeouttiles_up.py test_flip.py test_flip_x.py test_flip_x_3d.py test_flip_y.py test_flip_y_3d.py test_grid_effect_in_layer.py test_grid_effect_in_sprite.py test_jumptiles3d.py test_lens_3d.py test_liquid_16_x_16.py test_move_corner_down.py test_move_corner_up.py test_multiple_grid_effects.py test_quadmoveby.py test_reuse_grid.py test_ripple3d.py test_shaky3d.py test_shakytiles3d.py test_shattered_tiles_3d.py test_shuffletiles.py test_skew_horizontal.py test_skew_vertical.py test_stop_grid.py test_transition_corner_move.py test_transition_envelope.py test_transition_fadebl.py test_transition_fadetr.py test_transition_fadeup.py test_transition_flipx.py test_transition_flipy.py test_transition_flip_angular.py test_transition_shuffle.py test_transition_splitcols.py test_transition_splitrows.py test_transition_turnofftiles.py test_turnoff_tiles.py test_twirl.py test_waves.py test_waves3d.py test_wavestiles3d.py test_waves_horizontal.py test_waves_vertical.py I also found a couple of other exceptions: test_reverse_time.py Traceback (most recent call last): File "test_reverse_time.py", line 29, in <module> main_scene.do( flip + ReverseTime(flip) ) NameError: name 'ReverseTime' is not defined test_remove_add_by_name.py. Traceback (most recent call last): File "test_remove_add_by_name.py", line 25, in <module> main_scene.add( color, name='color' ) File "..\cocos\cocosnode.py", line 374, in add raise Exception("Name already exists: %s" % name ) Exception: Name already exists: color
• Oct 28, 2009

  issue 121 (AssertionError: Backslashes not permitted in relative path) commented on by stu.axon   -   Hi, I've just had the same problem (Windows Vista Home, Cocos 0.3.0, Pyglet 1.1.3) Instead of changing the path I removed the assertion which seems to make this and other demos work. I guess this really needs fixing in pyglet. The problem is that the relative path ..\cocos\resources is passed to this function when in windows.

  Hi, I've just had the same problem (Windows Vista Home, Cocos 0.3.0, Pyglet 1.1.3) Instead of changing the path I removed the assertion which seems to make this and other demos work. I guess this really needs fixing in pyglet. The problem is that the relative path ..\cocos\resources is passed to this function when in windows.
• Sep 10, 2009

  issue 129 (HexMap - new function get_neighbors()) reported by Gontro   -   While currently the HexMap class has the get_neighbor() method, I was wondering if an addition could be made to add a function that grabs all the neighbors of the passed cell and return them in a dict(). Definition =========================================================================== class HexMap(RegularTesselationMap): ... ... def get_neighbors(self, cell): return { self.UP_LEFT: self.get_neighbor(cell, self.UP_LEFT), self.UP: self.get_neighbor(cell, self.UP), self.UP_RIGHT: self.get_neighbor(cell, self.UP_RIGHT), self.DOWN_LEFT: self.get_neighbor(cell, self.DOWN_LEFT), self.DOWN: self.get_neighbor(cell, self.DOWN), self.DOWN_RIGHT: self.get_neighbor(cell, self.DOWN_RIGHT) } =========================================================================== Usage =========================================================================== neighbors = hexmap_layer.get_neighbors(selected_cell) print neighbors['up'].tile.id ===========================================================================

  While currently the HexMap class has the get_neighbor() method, I was wondering if an addition could be made to add a function that grabs all the neighbors of the passed cell and return them in a dict(). Definition =========================================================================== class HexMap(RegularTesselationMap): ... ... def get_neighbors(self, cell): return { self.UP_LEFT: self.get_neighbor(cell, self.UP_LEFT), self.UP: self.get_neighbor(cell, self.UP), self.UP_RIGHT: self.get_neighbor(cell, self.UP_RIGHT), self.DOWN_LEFT: self.get_neighbor(cell, self.DOWN_LEFT), self.DOWN: self.get_neighbor(cell, self.DOWN), self.DOWN_RIGHT: self.get_neighbor(cell, self.DOWN_RIGHT) } =========================================================================== Usage =========================================================================== neighbors = hexmap_layer.get_neighbors(selected_cell) print neighbors['up'].tile.id ===========================================================================
• Sep 10, 2009

  issue 128 (HexMapLayer - Code errors) reported by Gontro   -   Using rev879 The problem is with the new implementation of the HexMapLayer in the tiles.py file. Original Code =========================================================================== class HexMapLayer(HexMap, MapLayer): '''A renderable, scrollable hex map. ''' def __init__(self, id, tw, th, cells, origin=None, properties=None): HexMap.__init__(self, id, tw, th, cells, origin, properties) HexMapLayer.__init__(self, properties) =========================================================================== Patched Code =========================================================================== class HexMapLayer(HexMap, MapLayer): '''A renderable, scrollable hex map. ''' def __init__(self, id, tw, th, cells, origin=None, properties=None): HexMap.__init__(self, id, th, cells, origin, properties) MapLayer.__init__(self, properties) ===========================================================================

  Using rev879 The problem is with the new implementation of the HexMapLayer in the tiles.py file. Original Code =========================================================================== class HexMapLayer(HexMap, MapLayer): '''A renderable, scrollable hex map. ''' def __init__(self, id, tw, th, cells, origin=None, properties=None): HexMap.__init__(self, id, tw, th, cells, origin, properties) HexMapLayer.__init__(self, properties) =========================================================================== Patched Code =========================================================================== class HexMapLayer(HexMap, MapLayer): '''A renderable, scrollable hex map. ''' def __init__(self, id, tw, th, cells, origin=None, properties=None): HexMap.__init__(self, id, th, cells, origin, properties) MapLayer.__init__(self, properties) ===========================================================================
• Sep 09, 2009

  issue 122 (Cocosnode.transform() will ignore .children_anchor in some c...) commented on by ccanepacc   -   I think the issue is more deep that a simple bug, see http://groups.google.com/group/cocos-discuss/t/5b66db70021e3668 and http://groups.google.com/group/cocos-discuss/browse_thread/thread/3369253ef3e5c4d5

  I think the issue is more deep that a simple bug, see http://groups.google.com/group/cocos-discuss/t/5b66db70021e3668 and http://groups.google.com/group/cocos-discuss/browse_thread/thread/3369253ef3e5c4d5
• Sep 04, 2009

  issue 103 (tools/editor.py don't draw selection correctly) commented on by Devon.ScottTunkin   -   I noticed this too, and after thinking it was a bug in editor.py, I found that the road_map.xml or whatever it is called has an offset of (100, 0) for the map offset. This seems rather odd...

  I noticed this too, and after thinking it was a bug in editor.py, I found that the road_map.xml or whatever it is called has an offset of (100, 0) for the map offset. This seems rather odd...
• Sep 04, 2009

  r879 (removed duplicated code) committed by ricardoquesada   -   removed duplicated code

  removed duplicated code
• Sep 04, 2009

  r878 (auto remove particles when particle count== 0) committed by ricardoquesada   -   auto remove particles when particle count== 0

  auto remove particles when particle count== 0
• Sep 04, 2009

  r877 (added Grouped or Free movement to particle system. to test i...) committed by ricardoquesada   -   added Grouped or Free movement to particle system. to test it, try test_particle_sun.py and drag the mouse

  added Grouped or Free movement to particle system. to test it, try test_particle_sun.py and drag the mouse
• Sep 03, 2009

  r876 (avoid subpixel positioning) committed by r1chardj0n3s   -   avoid subpixel positioning

  avoid subpixel positioning
• Aug 30, 2009

  issue 126 (Bug in tiles RectMapLayer._as_xml and Cell._as_xml. All prop...) commented on by Devon.ScottTunkin   -   Richard fixed.

  Richard fixed.
• Aug 27, 2009

  r875 (fix another xml type mangle) committed by r1chardj0n3s   -   fix another xml type mangle

  fix another xml type mangle
• Aug 27, 2009

  r874 (fix a couple more filename mangles) committed by r1chardj0n3s   -   fix a couple more filename mangles

  fix a couple more filename mangles
• Aug 27, 2009

  r873 (don't alter the filenames as found in the XML) committed by r1chardj0n3s   -   don't alter the filenames as found in the XML

  don't alter the filenames as found in the XML
• Aug 27, 2009

  r872 (don't make everything unicode) committed by r1chardj0n3s   -   don't make everything unicode

  don't make everything unicode
• Aug 27, 2009

  issue 127 (cocos.batch.BatchNode.add() asserts (svn trunk 864+)) commented on by ccanepacc   -   It turns out that cocos.batch in trunk has undergone some changes, not totally compatible with 0.3.0 Some simple changes in the app (cocograph) provided compatibility with both cocos 0.3.0 release and cocos trunk. ( see http://groups.google.com/group/cocos-discuss/t/e7434fd358bf05ca if necesary ). Anyway, I think is not an error.

  It turns out that cocos.batch in trunk has undergone some changes, not totally compatible with 0.3.0 Some simple changes in the app (cocograph) provided compatibility with both cocos 0.3.0 release and cocos trunk. ( see http://groups.google.com/group/cocos-discuss/t/e7434fd358bf05ca if necesary ). Anyway, I think is not an error.
• Aug 27, 2009

  issue 127 (cocos.batch.BatchNode.add() asserts (svn trunk 864+)) commented on by ccanepacc   -   delete this issue please - totally wrong - short between the ears. In fact theres a problem with cocosgraph + cocos svn, but not what I reported. If something solid comes will report.

  delete this issue please - totally wrong - short between the ears. In fact theres a problem with cocosgraph + cocos svn, but not what I reported. If something solid comes will report.
• Aug 27, 2009

  issue 127 (cocos.batch.BatchNode.add() asserts (svn trunk 864+)) commented on by ccanepacc   -   Sorry, 'asserts' must have been 'will raise an exception'.

  Sorry, 'asserts' must have been 'will raise an exception'.
• Aug 27, 2009

  issue 127 (cocos.batch.BatchNode.add() asserts (svn trunk 864+)) reported by ccanepacc   -   cocos.batch.BatchNode.add() asserts (svn trunk 864+) I found the error while running cocosgraph alpha, but its easy to spot the problem in cocos.batch.py: cocos.batch.BatchNode.add() calls super(BatchNode, self).add(child, z, name) which translates to cocos.cocosnode.CocosNode.add(child, z, name) This have a wrong signature, must be: super(BatchNode, self).add(child, z=z, name=name) What version of the product are you using? On what operating system? cocos svn trunk 864+ svn diff atached.

  cocos.batch.BatchNode.add() asserts (svn trunk 864+) I found the error while running cocosgraph alpha, but its easy to spot the problem in cocos.batch.py: cocos.batch.BatchNode.add() calls super(BatchNode, self).add(child, z, name) which translates to cocos.cocosnode.CocosNode.add(child, z, name) This have a wrong signature, must be: super(BatchNode, self).add(child, z=z, name=name) What version of the product are you using? On what operating system? cocos svn trunk 864+ svn diff atached.
• Aug 26, 2009

  issue 126 (Bug in tiles RectMapLayer._as_xml and Cell._as_xml. All prop...) reported by Devon.ScottTunkin   -   What steps will reproduce the problem? 1. Create a tiles.RectMapLayer xml with non unicode type properties or with cells with non unicode type properties (xml attached) 2. load this xml file as a tiles.resource: import cocos r = cocos.tiles.load('cocosissue.xml') #and then resave it r.save_xml('cocosissue.xml') What is the expected output? What do you see instead? If the original xml had a non unicode type property <property type="int" name="age" value="7" /> for the maplayer or cell it will now be unicode <property type="unicode" name="age" value="7" />, which is wrong. What version of the product are you using? On what operating system? both .3 and latest revision have this problem. windows xp. Please provide any additional information below. _python_to_xml = { str: unicode, unicode: unicode, int: repr, float: repr, bool: repr, } _as_xml (in RectMapLayer and Cell) for k in self.properties: v = self.properties[k] v = _python_to_xml[type(v)](v) # XXX v is now unicode, or repr of bool, int, float which is str p = ElementTree.SubElement(m, 'property', name=k, value=v, type=_xml_type[type(v)]) # XXX this will always be unicode p.tail = '\n' a simple fix is: v = self.properties[k] vs = _python_to_xml[type(v)](v) p = ElementTree.SubElement(m, 'property', name=k, value=vs, type=_xml_type[type(v)])

  What steps will reproduce the problem? 1. Create a tiles.RectMapLayer xml with non unicode type properties or with cells with non unicode type properties (xml attached) 2. load this xml file as a tiles.resource: import cocos r = cocos.tiles.load('cocosissue.xml') #and then resave it r.save_xml('cocosissue.xml') What is the expected output? What do you see instead? If the original xml had a non unicode type property <property type="int" name="age" value="7" /> for the maplayer or cell it will now be unicode <property type="unicode" name="age" value="7" />, which is wrong. What version of the product are you using? On what operating system? both .3 and latest revision have this problem. windows xp. Please provide any additional information below. _python_to_xml = { str: unicode, unicode: unicode, int: repr, float: repr, bool: repr, } _as_xml (in RectMapLayer and Cell) for k in self.properties: v = self.properties[k] v = _python_to_xml[type(v)](v) # XXX v is now unicode, or repr of bool, int, float which is str p = ElementTree.SubElement(m, 'property', name=k, value=v, type=_xml_type[type(v)]) # XXX this will always be unicode p.tail = '\n' a simple fix is: v = self.properties[k] vs = _python_to_xml[type(v)](v) p = ElementTree.SubElement(m, 'property', name=k, value=vs, type=_xml_type[type(v)])
• Aug 24, 2009

  r871 (rationalise from three Rect implementations down to two(!)) committed by r1chardj0n3s   -   rationalise from three Rect implementations down to two(!)

  rationalise from three Rect implementations down to two(!)
• Aug 23, 2009

  r870 (Replace custom resource path crap in cocos.tiles with pyglet...) committed by r1chardj0n3s   -   Replace custom resource path crap in cocos.tiles with pyglet.resource crap. Fix RectMapLayer bug so test_tiles.py works again. Fix test_tiles_model so the path is haxxed to use local cocos.

  Replace custom resource path crap in cocos.tiles with pyglet.resource crap. Fix RectMapLayer bug so test_tiles.py works again. Fix test_tiles_model so the path is haxxed to use local cocos.
• Aug 22, 2009

  r869 (Test using bezier going through 4 specific points ) committed by facundobatista   -   Test using bezier going through 4 specific points

  Test using bezier going through 4 specific points
• Aug 20, 2009

  r868 (new test & fix) committed by r1chardj0n3s   -   new test & fix

  new test & fix
• Aug 19, 2009

  r867 (flesh out the tiles model code waaay more and add unit tests) committed by r1chardj0n3s   -   flesh out the tiles model code waaay more and add unit tests

  flesh out the tiles model code waaay more and add unit tests
• Aug 03, 2009

  r866 (more generic Rect implementation (from pyglet's wydget; my c...) committed by r1chardj0n3s   -   more generic Rect implementation (from pyglet's wydget; my code, I contribute it here) and generic tile map collider

  more generic Rect implementation (from pyglet's wydget; my code, I contribute it here) and generic tile map collider
• Jul 31, 2009

  issue 124 (grid effect partially broken in cocos svn 865) commented on by ccanepacc   -   follow up: similar visibility problems shows in cocos svn trunk 865 at tests test_multiple_grid_effects.py -> same as others test_transition_corner_move.py -> background not visible until the transform ends (works ok in cocos 0.3.0 release ) test_transition_fadebl.py -> idem test_transition_fadetr.py -> idem test_transition_fadeup.py -> idem test_transition_turnofftiles.py -> idem The problem was introduced at r 768, in framegrabber.py, by forcing as framegrabber the GenericGrabber; previously the FBOGrabber was used. From the commented out lines near line 64, seems that the intention was to select the FBOGrabber and fallback to the generic if FBOs not available. A quick test flipping the comment out status in lines 64-65 shows that all failing tests now runs normally.

  follow up: similar visibility problems shows in cocos svn trunk 865 at tests test_multiple_grid_effects.py -> same as others test_transition_corner_move.py -> background not visible until the transform ends (works ok in cocos 0.3.0 release ) test_transition_fadebl.py -> idem test_transition_fadetr.py -> idem test_transition_fadeup.py -> idem test_transition_turnofftiles.py -> idem The problem was introduced at r 768, in framegrabber.py, by forcing as framegrabber the GenericGrabber; previously the FBOGrabber was used. From the commented out lines near line 64, seems that the intention was to select the FBOGrabber and fallback to the generic if FBOs not available. A quick test flipping the comment out status in lines 64-65 shows that all failing tests now runs normally.
• Jul 30, 2009

  issue 125 (minor glitch in test_reverse_time.py) reported by ccanepacc   -   What steps will reproduce the problem? 1. run test_reverse_time.py ( found in the cocos provided tests directory) What is the expected output? What do you see instead? Expected an action play an then the reverse of the action Instead got a traceback: Traceback (most recent call last): File "test_reverse_time.py", line 29, in <module> main_scene.do( flip + ReverseTime(flip) ) NameError: name 'ReverseTime' is not defined What version of the product are you using? On what operating system? cocos svn trunk 865, also cocos 0.3.0 release Please provide any additional information below. To fix simply replace 'ReverseTime' with 'Reverse'

  What steps will reproduce the problem? 1. run test_reverse_time.py ( found in the cocos provided tests directory) What is the expected output? What do you see instead? Expected an action play an then the reverse of the action Instead got a traceback: Traceback (most recent call last): File "test_reverse_time.py", line 29, in <module> main_scene.do( flip + ReverseTime(flip) ) NameError: name 'ReverseTime' is not defined What version of the product are you using? On what operating system? cocos svn trunk 865, also cocos 0.3.0 release Please provide any additional information below. To fix simply replace 'ReverseTime' with 'Reverse'
• Jul 30, 2009

  issue 124 (grid effect partially broken in cocos svn 865) reported by ccanepacc   -   What steps will reproduce the problem? 1. run test_grid_effect_in_layer.py or test_grid_effect_in_sprite.py ( to be found in the cocos test directory ) 2. Notice that in the first is explicity stated that the ColorLayer must be visible all the time What is the expected output? What do you see instead? I expected what was described in the test, instead the ColorLayer disapears. Note that the second test dont states anything, but in cocos 0.3.0 the background remains visible; instead, with cocos trunk svn 865 the background also disapears. What version of the product are you using? On what operating system? win XP - python 2.6 - pyglet 1.1.3 release - cocos svn trunk 865 Please provide any additional information below. grid effect partially broken in cocos svn 865, was working ok in cocos 0.3.0 release. win XP - python 2.6 - pyglet 1.1.3 release

  What steps will reproduce the problem? 1. run test_grid_effect_in_layer.py or test_grid_effect_in_sprite.py ( to be found in the cocos test directory ) 2. Notice that in the first is explicity stated that the ColorLayer must be visible all the time What is the expected output? What do you see instead? I expected what was described in the test, instead the ColorLayer disapears. Note that the second test dont states anything, but in cocos 0.3.0 the background remains visible; instead, with cocos trunk svn 865 the background also disapears. What version of the product are you using? On what operating system? win XP - python 2.6 - pyglet 1.1.3 release - cocos svn trunk 865 Please provide any additional information below. grid effect partially broken in cocos svn 865, was working ok in cocos 0.3.0 release. win XP - python 2.6 - pyglet 1.1.3 release
• Jul 29, 2009

  r865 (This new class name kinda sucks. And it's not really an Int...) committed by r1chardj0n3s   -   This new class name kinda sucks. And it's not really an IntervalAction. And it's had to override the __deepcopy__ mechanism to work But I believe it's still a good idea :) Ideas: - make it not be an IntervalAction, - use properties off the target (speed, acceleration, speed limits) alongside rotation, thus avoiding the deepcopy issue

  This new class name kinda sucks. And it's not really an IntervalAction. And it's had to override the __deepcopy__ mechanism to work But I believe it's still a good idea :) Ideas: - make it not be an IntervalAction, - use properties off the target (speed, acceleration, speed limits) alongside rotation, thus avoiding the deepcopy issue
• Jul 14, 2009

  issue 123 (CocosNode.remove_action() mostly not working) reported by ccanepacc   -   CocosNode.remove_action(action) dont remove actions for most of cocos actions. Included bugdemo and posible fix. The bugdemo ( bugdemo_remove_action.py ) shows this for MoveTo : A sprite is put at window left side; When the layer containing the sprite does .on_enter(), an action MoveTo ( 'window right side', 10 seconds) is performed over the sprite. Also in the same on_enter, it is arranged that at 5 seconds a .remove_action() will be issued at the sprite (with the correct argument). It is expected the sprite stops near the window's center. Observed: the sprite reachs the window's right side, that is, .remove_action() performed a NOP""" Other info: win XP, python 2.6.1, cocos 0.3 release or cocos svn trunk r864 About the bug causes and the fix: The failure to perform is due to the fact that: 1) CocosNode adds an action ( .do(action) ) by adding a copy.deepcopy of action at the currently active actions 2) While instructed to do .remove_action(my_action), it checks if it has an action such that action==my_action, if true then removes that action 3) but if 'b' is a class instance, then it is generally untrue that b==copy.deepcopy(b) To fix that, possible options are : a) That CocosNode dont store a copy.deepcopy() but the real thing, then the test will trivially succed. As I dont know the rationalle to store a copy, I can't tell if this is good or not. Alternative: b) Modify the base class of cocos actions so that if b instance of cocos actions, then b==copy.deepcopy(b) holds True Clearly that would need to define an apropiate __eq__ method for the actions base class, no big deal Another Alternative: c) Change the condition to delete from 'action==my_action' to something as action.is_copy(my_action) I choosed b) for my fix, wich is very easy to implement: 1) in the action baseclass __init__ add a member that holds a 'primordial_id'. Instances normally created will not repeat that id; a copy.copy or copy.deepcopy will mantain the same id for the new instance, so.. 2) in action baseclass __eq__ checks that the other is an action and have the same id. ( that will ensure b==copy.deepcopy(b) ) If for some reason is desired a more strong __eq__ for other ortogonal uses, compatibility with the desired .remove_action() behavoir must be considered, and if not compatible, use option c)

  CocosNode.remove_action(action) dont remove actions for most of cocos actions. Included bugdemo and posible fix. The bugdemo ( bugdemo_remove_action.py ) shows this for MoveTo : A sprite is put at window left side; When the layer containing the sprite does .on_enter(), an action MoveTo ( 'window right side', 10 seconds) is performed over the sprite. Also in the same on_enter, it is arranged that at 5 seconds a .remove_action() will be issued at the sprite (with the correct argument). It is expected the sprite stops near the window's center. Observed: the sprite reachs the window's right side, that is, .remove_action() performed a NOP""" Other info: win XP, python 2.6.1, cocos 0.3 release or cocos svn trunk r864 About the bug causes and the fix: The failure to perform is due to the fact that: 1) CocosNode adds an action ( .do(action) ) by adding a copy.deepcopy of action at the currently active actions 2) While instructed to do .remove_action(my_action), it checks if it has an action such that action==my_action, if true then removes that action 3) but if 'b' is a class instance, then it is generally untrue that b==copy.deepcopy(b) To fix that, possible options are : a) That CocosNode dont store a copy.deepcopy() but the real thing, then the test will trivially succed. As I dont know the rationalle to store a copy, I can't tell if this is good or not. Alternative: b) Modify the base class of cocos actions so that if b instance of cocos actions, then b==copy.deepcopy(b) holds True Clearly that would need to define an apropiate __eq__ method for the actions base class, no big deal Another Alternative: c) Change the condition to delete from 'action==my_action' to something as action.is_copy(my_action) I choosed b) for my fix, wich is very easy to implement: 1) in the action baseclass __init__ add a member that holds a 'primordial_id'. Instances normally created will not repeat that id; a copy.copy or copy.deepcopy will mantain the same id for the new instance, so.. 2) in action baseclass __eq__ checks that the other is an action and have the same id. ( that will ensure b==copy.deepcopy(b) ) If for some reason is desired a more strong __eq__ for other ortogonal uses, compatibility with the desired .remove_action() behavoir must be considered, and if not compatible, use option c)
• Jun 30, 2009

  issue 118 (a scene or layer containing a cocos.draw.Canvas will crash a...) commented on by ccanepacc   -   opps, forgot the bugdemo script, here it is

  opps, forgot the bugdemo script, here it is
• Jun 30, 2009

  issue 118 (a scene or layer containing a cocos.draw.Canvas will crash a...) commented on by ccanepacc   -   Made a script that demostrates the problem, and rewrote the 1st bug report for better understandbility: The script does, in pseudocode: push a scene with contains a cocos.draw.Canvas loop forever: wait 2 seconds (*) push a scene, content dont matter for the bug (but FYI is a ColorLayer) wait 2 seconds director.pop() I suppose it can fail in more ways, but in my machine I see: The second time that (*) executes, the program terminates with traceback: [...] File "c:\python26\lib\site-packages\cocos2d-0.3.0-py2.6.egg\cocos \draw.py", line 320, in free self._vertex_list.delete() File "C:\Python26\lib\site-packages\pyglet\graphics \vertexdomain.py", line 399 , in delete self.domain.allocator.dealloc(self.start, self.count) File "C:\Python26\lib\site-packages\pyglet\graphics\allocation.py", line 293, in dealloc assert self.starts AssertionError The problem is: when pushing in (*), the _vertex_list for the cocos.draw.Canvas object is freed. After the following pop, the Canvas has a dangling reference wich it not detect, and draws with it. I asume that in certain combinations of driver,hardware,load... , the draw could fail (or display garbage). As I noted, the draw seems to proceed without problems in my system. Then, at the next push, it tries to free the same _vertex_list, wich produces the assertion fail that terminates the run. The patch submited simply adds some defensive programming at the on_exit, and ensures in on_enter that draw will detect it needs to regenerate _vertex_list Aditional info: win XP sp3, python 2.6.1, cocos 0.3.0 release and cocos SVN r864

  Made a script that demostrates the problem, and rewrote the 1st bug report for better understandbility: The script does, in pseudocode: push a scene with contains a cocos.draw.Canvas loop forever: wait 2 seconds (*) push a scene, content dont matter for the bug (but FYI is a ColorLayer) wait 2 seconds director.pop() I suppose it can fail in more ways, but in my machine I see: The second time that (*) executes, the program terminates with traceback: [...] File "c:\python26\lib\site-packages\cocos2d-0.3.0-py2.6.egg\cocos \draw.py", line 320, in free self._vertex_list.delete() File "C:\Python26\lib\site-packages\pyglet\graphics \vertexdomain.py", line 399 , in delete self.domain.allocator.dealloc(self.start, self.count) File "C:\Python26\lib\site-packages\pyglet\graphics\allocation.py", line 293, in dealloc assert self.starts AssertionError The problem is: when pushing in (*), the _vertex_list for the cocos.draw.Canvas object is freed. After the following pop, the Canvas has a dangling reference wich it not detect, and draws with it. I asume that in certain combinations of driver,hardware,load... , the draw could fail (or display garbage). As I noted, the draw seems to proceed without problems in my system. Then, at the next push, it tries to free the same _vertex_list, wich produces the assertion fail that terminates the run. The patch submited simply adds some defensive programming at the on_exit, and ensures in on_enter that draw will detect it needs to regenerate _vertex_list Aditional info: win XP sp3, python 2.6.1, cocos 0.3.0 release and cocos SVN r864
• Jun 30, 2009

  issue 122 (Cocosnode.transform() will ignore .children_anchor in some c...) reported by ccanepacc   -   What steps will reproduce the problem? 1. grab the app http://cocos- discuss.googlegroups.com/web/anchors_interactive_test.zip (weights only 7KB). It shows some basic CocosNodes, and it allows to interactivelly specify the subclass, transform_anchor, and children_anchor to be seen. 2. Run the app. I suggest to not select class Sprite (because thereis a bug report regarding Sprites and Anchors), also to not select ColorLayer (because his .draw() method references directly .children_anchor). Any other class will show cleary the problem. 3. set transform_anchor to (0,0) , set .children_anchor to (100,0), press enter. What is the expected output? What do you see instead? After pressing enter I would expect the object image to move, instead it remains at the same position. What version of the product are you using? On what operating system? cocos svn r864 Please provide any additional information below. I think that in CocosNode.transform(), after the rotation, the code must be functionally equivalent to: glTranslatef( self.children_anchor_x - self.transform_anchor_x, self.children_anchor_y - self.transform_anchor_y, 0 ) but the actual code behaves diferently, maybe while trying to spare the transform when the delta is 0. Anyway, is probably faster to call the transform than checking the properties to see if the result will be (0,0) A simple patch is attached;

  What steps will reproduce the problem? 1. grab the app http://cocos- discuss.googlegroups.com/web/anchors_interactive_test.zip (weights only 7KB). It shows some basic CocosNodes, and it allows to interactivelly specify the subclass, transform_anchor, and children_anchor to be seen. 2. Run the app. I suggest to not select class Sprite (because thereis a bug report regarding Sprites and Anchors), also to not select ColorLayer (because his .draw() method references directly .children_anchor). Any other class will show cleary the problem. 3. set transform_anchor to (0,0) , set .children_anchor to (100,0), press enter. What is the expected output? What do you see instead? After pressing enter I would expect the object image to move, instead it remains at the same position. What version of the product are you using? On what operating system? cocos svn r864 Please provide any additional information below. I think that in CocosNode.transform(), after the rotation, the code must be functionally equivalent to: glTranslatef( self.children_anchor_x - self.transform_anchor_x, self.children_anchor_y - self.transform_anchor_y, 0 ) but the actual code behaves diferently, maybe while trying to spare the transform when the delta is 0. Anyway, is probably faster to call the transform than checking the properties to see if the result will be (0,0) A simple patch is attached;
• Jun 28, 2009

  r864 (merged arnaud's patches) committed by lucio.torre   -   merged arnaud's patches

  merged arnaud's patches
• May 29, 2009

  issue 121 (AssertionError: Backslashes not permitted in relative path) reported by jackmil7   -   Running cocos2D samples on Windows raise this error: File "hello_world.py", line 11, in <module> import cocos File "..\cocos\__init__.py", line 64, in <module> pyglet.resource.reindex() File "C:\PythonPackages\pyglet\pyglet\resource.py", line 327, in reindex 'Backslashes not permitted in relative path' AssertionError: Backslashes not permitted in relative path What version of the product are you using? On what operating system? Windows 2000, cocos2D 0.3.0 Solution: Instead of pyglet.resource.path.append(os.path.join(os.path.dirname(__file__), "resources")) must be pyglet.resource.path.append(os.path.join(os.path.dirname(__file__), "resources").replace('\\', '/')) Adding .replace('\\', '/') works for Mac OS X, Linux and Windows.

  Running cocos2D samples on Windows raise this error: File "hello_world.py", line 11, in <module> import cocos File "..\cocos\__init__.py", line 64, in <module> pyglet.resource.reindex() File "C:\PythonPackages\pyglet\pyglet\resource.py", line 327, in reindex 'Backslashes not permitted in relative path' AssertionError: Backslashes not permitted in relative path What version of the product are you using? On what operating system? Windows 2000, cocos2D 0.3.0 Solution: Instead of pyglet.resource.path.append(os.path.join(os.path.dirname(__file__), "resources")) must be pyglet.resource.path.append(os.path.join(os.path.dirname(__file__), "resources").replace('\\', '/')) Adding .replace('\\', '/') works for Mac OS X, Linux and Windows.
• May 09, 2009

  r863 (Fixed the virtual coordinate calculus when the window doesn'...) committed by facundobatista   -   Fixed the virtual coordinate calculus when the window doesn't have the same aspect relation than the original.

  Fixed the virtual coordinate calculus when the window doesn't have the same aspect relation than the original.
• May 05, 2009

  issue 120 (cocos Exception: No empty particle when returning to a scene) commented on by holomorph   -   Any of those look like a fine option, I don't have a preference as long as it still looks good and doesn't crash :)

  Any of those look like a fine option, I don't have a preference as long as it still looks good and doesn't crash :)
• May 04, 2009

  issue 120 (cocos Exception: No empty particle when returning to a scene) Status changed by lucio.torre   -   1- on enter should not generate a particle, agreed. 2- maybe we should return true or false to indicate if a particle was created. or maybe just replace the oldest particle. i think that an exception may be too much, but not having any way of knowing if your particles are being added is bad too. what do you think?

  Status: Accepted

  1- on enter should not generate a particle, agreed. 2- maybe we should return true or false to indicate if a particle was created. or maybe just replace the oldest particle. i think that an exception may be too much, but not having any way of knowing if your particles are being added is bad too. what do you think?

  Status: Accepted
• May 02, 2009

  issue 120 (cocos Exception: No empty particle when returning to a scene) reported by holomorph   -   File "run_game.py", line 4, in <module> main.main() File "/home/bjorn/source/pyweek8/gamelib/main.py", line 19, in main cocos.director.director.run (theMenu.MainMenuScene()) File "/home/bjorn/source/pyweek8/cocos/director.py", line 296, in run event_loop.run() File "/usr/lib/python2.5/site-packages/pyglet/app/xlib.py", line 94, in run sleep_time = self.idle() File "/usr/lib/python2.5/site-packages/pyglet/app/__init__.py", line 193, in idle window.dispatch_event('on_draw') File "/usr/lib/python2.5/site-packages/pyglet/window/__init__.py", line 1217, in dispatch_event EventDispatcher.dispatch_event(self, *args) File "/usr/lib/python2.5/site-packages/pyglet/event.py", line 340, in dispatch_event if handler(*args): File "/home/bjorn/source/pyweek8/cocos/director.py", line 306, in on_draw self._set_scene( self.next_scene ) File "/home/bjorn/source/pyweek8/cocos/director.py", line 369, in _set_scene scene.on_enter() File "/home/bjorn/source/pyweek8/cocos/scene.py", line 106, in on_enter super(Scene, self).on_enter() File "/home/bjorn/source/pyweek8/cocos/cocosnode.py", line 443, in on_enter c.on_enter() File "/home/bjorn/source/pyweek8/cocos/layer/base_layers.py", line 80, in on_enter super(Layer, self).on_enter() File "/home/bjorn/source/pyweek8/cocos/cocosnode.py", line 443, in on_enter c.on_enter() File "/home/bjorn/source/pyweek8/cocos/layer/base_layers.py", line 80, in on_enter super(Layer, self).on_enter() File "/home/bjorn/source/pyweek8/cocos/cocosnode.py", line 443, in on_enter c.on_enter() File "/home/bjorn/source/pyweek8/cocos/cocosnode.py", line 443, in on_enter c.on_enter() File "/home/bjorn/source/pyweek8/cocos/particle.py", line 167, in on_enter self.add_particle() File "/home/bjorn/source/pyweek8/cocos/particle.py", line 245, in add_particle self.init_particle() File "/home/bjorn/source/pyweek8/cocos/particle.py", line 304, in init_particle raise Exception("No empty particle") Exception: No empty particle What steps will reproduce the problem? 1. create a scene with a particle system (I used Sun and Smoke) 2. from that scene push another scene on the director (eg a menu) 3. exit the other scene to return to the first 4. repeat until exception hit What version of the product are you using? On what operating system? I grabbed the svn earlier this week. Please provide any additional information below. I worked around this issue by just returning from init_particle if (as I understand it) there is no more room to create a new particle, instead of throwing. Probably the right thing is to not automatically be calling init_particle when on_enter is called.

  File "run_game.py", line 4, in <module> main.main() File "/home/bjorn/source/pyweek8/gamelib/main.py", line 19, in main cocos.director.director.run (theMenu.MainMenuScene()) File "/home/bjorn/source/pyweek8/cocos/director.py", line 296, in run event_loop.run() File "/usr/lib/python2.5/site-packages/pyglet/app/xlib.py", line 94, in run sleep_time = self.idle() File "/usr/lib/python2.5/site-packages/pyglet/app/__init__.py", line 193, in idle window.dispatch_event('on_draw') File "/usr/lib/python2.5/site-packages/pyglet/window/__init__.py", line 1217, in dispatch_event EventDispatcher.dispatch_event(self, *args) File "/usr/lib/python2.5/site-packages/pyglet/event.py", line 340, in dispatch_event if handler(*args): File "/home/bjorn/source/pyweek8/cocos/director.py", line 306, in on_draw self._set_scene( self.next_scene ) File "/home/bjorn/source/pyweek8/cocos/director.py", line 369, in _set_scene scene.on_enter() File "/home/bjorn/source/pyweek8/cocos/scene.py", line 106, in on_enter super(Scene, self).on_enter() File "/home/bjorn/source/pyweek8/cocos/cocosnode.py", line 443, in on_enter c.on_enter() File "/home/bjorn/source/pyweek8/cocos/layer/base_layers.py", line 80, in on_enter super(Layer, self).on_enter() File "/home/bjorn/source/pyweek8/cocos/cocosnode.py", line 443, in on_enter c.on_enter() File "/home/bjorn/source/pyweek8/cocos/layer/base_layers.py", line 80, in on_enter super(Layer, self).on_enter() File "/home/bjorn/source/pyweek8/cocos/cocosnode.py", line 443, in on_enter c.on_enter() File "/home/bjorn/source/pyweek8/cocos/cocosnode.py", line 443, in on_enter c.on_enter() File "/home/bjorn/source/pyweek8/cocos/particle.py", line 167, in on_enter self.add_particle() File "/home/bjorn/source/pyweek8/cocos/particle.py", line 245, in add_particle self.init_particle() File "/home/bjorn/source/pyweek8/cocos/particle.py", line 304, in init_particle raise Exception("No empty particle") Exception: No empty particle What steps will reproduce the problem? 1. create a scene with a particle system (I used Sun and Smoke) 2. from that scene push another scene on the director (eg a menu) 3. exit the other scene to return to the first 4. repeat until exception hit What version of the product are you using? On what operating system? I grabbed the svn earlier this week. Please provide any additional information below. I worked around this issue by just returning from init_particle if (as I understand it) there is no more room to create a new particle, instead of throwing. Probably the right thing is to not automatically be calling init_particle when on_enter is called.
• May 01, 2009

  r862 (Example how to change text and color of a Label. ) committed by facundobatista   -   Example how to change text and color of a Label.

  Example how to change text and color of a Label.
• Apr 28, 2009

  r861 (error in names) committed by ricardoquesada   -   error in names

  error in names
• Apr 28, 2009

  r860 (loader working again) committed by ricardoquesada   -   loader working again

  loader working again