{"action":"created","issue":{"url":"https://api.github.com/repos/pvcraven/arcade/issues/85","repository_url":"https://api.github.com/repos/pvcraven/arcade","labels_url":"https://api.github.com/repos/pvcraven/arcade/issues/85/labels{/name}","comments_url":"https://api.github.com/repos/pvcraven/arcade/issues/85/comments","events_url":"https://api.github.com/repos/pvcraven/arcade/issues/85/events","html_url":"https://github.com/pvcraven/arcade/issues/85","id":191268860,"number":85,"title":"Alternative to global pyglet window subclass as the unit of programming","user":{"login":"pauleveritt","id":455142,"avatar_url":"https://avatars.githubusercontent.com/u/455142?v=3","gravatar_id":"","url":"https://api.github.com/users/pauleveritt","html_url":"https://github.com/pauleveritt","followers_url":"https://api.github.com/users/pauleveritt/followers","following_url":"https://api.github.com/users/pauleveritt/following{/other_user}","gists_url":"https://api.github.com/users/pauleveritt/gists{/gist_id}","starred_url":"https://api.github.com/users/pauleveritt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pauleveritt/subscriptions","organizations_url":"https://api.github.com/users/pauleveritt/orgs","repos_url":"https://api.github.com/users/pauleveritt/repos","events_url":"https://api.github.com/users/pauleveritt/events{/privacy}","received_events_url":"https://api.github.com/users/pauleveritt/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-11-23T13:21:44Z","updated_at":"2016-12-09T02:33:14Z","closed_at":null,"body":"For non-trivial coding, arcade provides a base class at application.Window. IMO, there are a few flaws with this:\r\n\r\n- We have to have a global variable \"window\"\r\n- People code to the pyglet API directly, and we can't mediate that relationship\r\n- Some odd things pop up, e.g. making users call start_render() because we're not mediating\r\n\r\nMy previous alternative used decorators and thus, raised the conceptual complexity dramatically. Here's a different proposal.\r\n\r\nFirst, leave the function-oriented approach as-is, and portray it as aimed at interactive use by people that barely know Python.\r\n\r\nNext, have an arcade.Game base class which doesn't subclass from pyglet.window.Window. Instead, its constructor creates an instance of arcade.Window, which subclasses from pyglet.window.Window.\r\n\r\nThe most important part: arcade.Game passes its ``self`` into arcade.Window. Then, arcade.Window implements all the ``animate`` etc. methods, doing some work and calling ``self.app.animate`` which the user implements.\r\n\r\nHere is an example of a game written that way: https://github.com/pauleveritt/asteroids/blob/master/gameng.py\r\n\r\nIt has no user-visible additional complexity from the current approach. It has a couple of things that are complexity reduction (e.g. no start_render).\r\n\r\nHere are the base classes: https://github.com/pauleveritt/asteroids/blob/master/arcadeng.py\r\n\r\nVery simple, no advanced concepts. The magic is on line 50, where self is passed into the window.\r\n\r\nWith this in place, arcade users don't have to learn pyglet. For example, I changed pyglet's ``animate`` method to ``update_model`` to better reflect the intention of our programming model. Later, I'd like to make batching transparent to use: https://github.com/pauleveritt/asteroids/blob/master/experiment_pyglet_sprites.py\r\n\r\nThis example is 4x faster than the non-batching, but it is complex to use. We might be able to come up with a simplified programming model, once we mediate the relationship.\r\n\r\nI'd also like to make our base class into an abstract base class, so it will be clear what they have to implement.\r\n\r\nFinally, I realize this is a colossal change. If this was approved, I'd have to do all the work to make the change. I'm not asking others to do it."},"comment":{"url":"https://api.github.com/repos/pvcraven/arcade/issues/comments/265917348","html_url":"https://github.com/pvcraven/arcade/issues/85#issuecomment-265917348","issue_url":"https://api.github.com/repos/pvcraven/arcade/issues/85","id":265917348,"user":{"login":"pauleveritt","id":455142,"avatar_url":"https://avatars.githubusercontent.com/u/455142?v=3","gravatar_id":"","url":"https://api.github.com/users/pauleveritt","html_url":"https://github.com/pauleveritt","followers_url":"https://api.github.com/users/pauleveritt/followers","following_url":"https://api.github.com/users/pauleveritt/following{/other_user}","gists_url":"https://api.github.com/users/pauleveritt/gists{/gist_id}","starred_url":"https://api.github.com/users/pauleveritt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pauleveritt/subscriptions","organizations_url":"https://api.github.com/users/pauleveritt/orgs","repos_url":"https://api.github.com/users/pauleveritt/repos","events_url":"https://api.github.com/users/pauleveritt/events{/privacy}","received_events_url":"https://api.github.com/users/pauleveritt/received_events","type":"User","site_admin":false},"created_at":"2016-12-09T02:33:14Z","updated_at":"2016-12-09T02:33:14Z","body":"I made a branch (unpushed) and found that doing labels in batches, even backwards compatible without batches without re-implementing the existing drawing code, was easy.\r\n\r\nSprites are a different story. Pyglet sprites have an option to let you create a sprite in a batch. Since you don't use pyglet sprites, I have to understand what that option does, then learn about how you are using vertex buffer objects, textures, etc...then apply the pyglet sprite batching code."}}
{"actor":{"display_login":"pauleveritt"}}