Re: ViewPort in ‘play’

37 views
Skip to first unread message

Ben Lippmeier

unread,
Jun 5, 2013, 10:52:59 PM6/5/13
to Francesco Mazzoli, haskel...@googlegroups.com

cc-ing to the haskell-gloss list

On 06/06/2013, at 10:19 AM, Francesco Mazzoli wrote:

> I was playing with gloss, and I think it would be really handy to have a
> function to enable zoom/pan controls for ‘play’ too. I could easily write
> such a thing, but I took a quick look at the code and it seems like the
> machinery is all there waiting to be used (the ViewPort stuff), so I thought
> that reusing that would be more appropriate.
>
> What do you think? I can take a look at the code myself, but I want to make
> sure that you wouldn’t be opposed to the patches for some reason that I have
> overlooked.

Improvements most welcome, provided they don't complicate the existing API. I considered adding an extra flag to the Display type to enable panning and zooming, but then `Display` becomes more like a `Configuration` type that doesn't just represent the shape of the output window.

Perhaps you could factor out the viewport handling code into a separate module. Maybe make a module Graphics.Gloss.Data.ViewPort and have functions like:

updateViewStateWithEvents :: [Event] -> ViewState -> ViewState
viewPortOfViewState :: ViewState -> ViewPort
applyViewPortToPicture :: ViewPort -> Picture -> Picture

With those functions it would be easy for the client programmer to add viewport handling to their own code just by using the existing 'play' interface, and the ViewPort code itself would be cleaner.

Thoughts?

Ben.


Ben Lippmeier

unread,
Jun 6, 2013, 9:33:19 PM6/6/13
to Francesco Mazzoli, haskel...@googlegroups.com

On 06/06/2013, at 6:08 PM, Francesco Mazzoli wrote:

> At Thu, 6 Jun 2013 12:52:59 +1000,
> Ben Lippmeier wrote:
>> Improvements most welcome, provided they don't complicate the existing
>> API. I considered adding an extra flag to the Display type to enable panning
>> and zooming, but then `Display` becomes more like a `Configuration` type
>> that doesn't just represent the shape of the output window.
>>
>> Perhaps you could factor out the viewport handling code into a separate
>> module. Maybe make a module Graphics.Gloss.Data.ViewPort and have functions
>> like:
>>
>> updateViewStateWithEvents :: [Event] -> ViewState -> ViewState
>> viewPortOfViewState :: ViewState -> ViewPort
>> applyViewPortToPicture :: ViewPort -> Picture -> Picture
>>
>> With those functions it would be easy for the client programmer to add
>> viewport handling to their own code just by using the existing 'play'
>> interface, and the ViewPort code itself would be cleaner.
>>
>> Thoughts?
>
> That sounds fine. I’m quite busy now but I’ll send some darcs patches when I
> get around writing it.
>
> I guess that then it would be better to change the other ViewPort-using
> interfaces (Simulate, Animate, ...) to use the high-level API, right?

I think the Simulate and Animate API modes should provide viewport handling automatically, but the implementation of all should use the same code, yes.

Ben.


Reply all
Reply to author
Forward
0 new messages