TESTS: Say I want to eliminate a common pattern from your handle-key-down
function. If it comes with some tests, four to be precise, a simple run --
without playing -- assures me of basic qualities. If you express tests like
those below and you formulate them first, you get an idea of how to code the
function. And -- for a large function -- a reader quickly gets the idea of how
the function works from reading some tests.
(check-expect (handle-key-down initial-state "w") (set-left-moving
initial-state UP-DIR))
(define (handle-key-down world a-key)
(cond
[(key=? a-key "w") (set-left-moving world UP-DIR)]
[(key=? a-key "s") (set-left-moving world DOWN-DIR)]
[(key=? a-key "up") (set-right-moving world UP-DIR)]
[(key=? a-key "down") (set-right-moving world DOWN-DIR)]
[else world]))
(define (set-left-moving world dir)
(set-left-paddle world (set-paddle-moving (pong-world-left-paddle world) dir
PADDLE-SPEED)))
(define (set-right-moving world dir)
(set-right-paddle world (set-paddle-moving (pong-world-right-paddle world)
dir PADDLE-SPEED)))
GAME PAD: I am happy to see that you used on-pad. Your game does give me an
idea on how to improve the whole 'pad situation'.
-- Matthias
On Dec 29, 2014, at 1:43 PM, Darren Cruse wrote:
> Thanks Matthias and it will be quite fun to tell the others at my next meetup
> who code reviewed this for me! :)
>
> I'll make the changes you suggested though (forgive me) I'll have to think
> about what constitutes useful tests for this. Somehow I've never fully
> bought into TDD though I know I'm one of the last holdouts in the civilized
> world. :) Can I get out of it saying I was just doing this for fun? :)
>
> I'm most of all pleased that you didn't see something I'd fundamentally
> misunderstood, e.g. that would explain why the game performed poorly on the
> raspberry pi.
>
> fwiw Racket is the first lispy language I've ever gotten serious about
> learning. I'm one of those who'd been thrown off by the parens for too long.
> I really like using it now that I'm over the initial learning curve. I
> think my biggest wish would be it had a good story for doing
> smartphone/tablet apps, or that Whalesong was more of a going concern (not
> that I've tried it I wonder if this pong game would run under it without a
> ton of work?)
>
> Thanks again for your time,
>
> Darren
>
>
> On Mon, Dec 29, 2014 at 10:39 AM, Matthias Felleisen <[email protected]>
> wrote:
>
> Hi Darren, thanks for the link to the repo. I cloned it, successfully played
> with and without sound on a mac book -- inside of drracket and from the
> command line-- and never observed a load over 60% for drracket and ditto for
> plain racket. That doesn't mean that your 100% problem doesn't exist, it's
> just that I can't reproduce it.
>
> A couple of comments on the code:
>
> -- I'd place the main function at the top of the function section of the
> file
> right below the constant definitions and data definitions
> [I modified 2e to bring this across but you might be reading the stable
> version.]
>
> -- I also run (main initial-state) out of the repl not the main buffer.
>
> -- Your file is missing tests.
>
> -- Some functions are also missing proper signatures and purpose statements.
>
> But I know "it works" see my homepage :-)
>
> -- Matthias
>
>
>
> On Dec 29, 2014, at 10:46 AM, Darren Cruse wrote:
>
>> Re:
>> Could you post the code somewhere so we can experiment with it?
>>
>> Here it is it's all in one file:
>> pong-world.rkt
>>
>> On Mon, Dec 29, 2014 at 8:05 AM, Matthias Felleisen <[email protected]>
>> wrote:
>>
>> On Dec 28, 2014, at 9:51 PM, Darren Cruse wrote:
>>
>>> One thing I can see is that on-draw is called for every on-tick on all
>>> three platforms btw.
>>>
>>> And even in cases where the program is idling and on-tick has simply
>>> returned the world state it was given unmodified.
>>>
>>> Is that normal I wonder? Part of me thought that since to-draw is a
>>> function of the world state, and the world state hasn't changed, that it
>>> would *not* call to-draw in that case.
>>
>> I experimented with this 'optimization' and, if I recall correctly, it
>> didn't make much of a difference and got in the way of imperative world
>> programs. So I took it out. Mea culpa, I should have commented on this
>> experiment inside the code.
>>
>>
>>
>>> (but it calls to-draw for every on-tick even on the Windows machine which
>>> is using only 6% cpu - so maybe I'm wrong to look to that as the problem)
>>
>>
>> My Mac-based experiments suggest that this call is not the cause of
>> performance problems.
>>
>> ;; ---
>>
>> Could you post the code somewhere so we can experiment with it?
>>
>> Thanks -- Matthias
>>
>>
>>
>
>
____________________
Racket Users list:
http://lists.racket-lang.org/users
