John Carmack:
> My son's game has a level editor as well as a game loop, and we switch
> between them. However, each new big-bang call creates a new window,
> leaving the previous ones inert on the screen. How can we close the
> windows?
>
Matthias Felleisen:
>
> But people wanted it to stay
>
I, for one, thought the idea of “OS” reads and writes from Get Bonus was a neat
abstraction, even if it is more or less just functional reads and writes to a
giant hash table. Obviously that’s more complicated than would be appropriate
for big-bang, but I thought I’d bring it up anyway.
> On Ju
I have for years hoped to find time to think about 'distributing state' over
handlers in big-bang because I am perfectly aware of the scaling up
limitations. Your hashtable idea might be worth exploring. Tony and I are also
considering his actor system as a source of ideas. This may also give u
On Jun 22, 2015, at 11:31 AM, Jens Axel Søgaard wrote:
> John Carmack:
> My son's game has a level editor as well as a game loop, and we switch
> between them. However, each new big-bang call creates a new window, leaving
> the previous ones inert on the screen. How can we close the windows
On Sun, Jun 21, 2015 at 10:18 PM, Neil Toronto wrote:
> On 06/21/2015 02:54 PM, Alexis King wrote:
>>>
>>> I guess I could add a close-on-stop clauses for programmers
>>> such as your son but it sounds almost like he's ready to move
>>> on to racket proper, as in use the Windowing API directly.
>>
On Jun 21, 2015, at 10:18 PM, Neil Toronto wrote:
> I'm working on a `big-bang3d` game intended to expose shortcomings in
> universe-style programs when used at a larger scale than in the classroom.
> Here are my main criticisms so far:
>
> 1. Adding new state is painful. Every time I add a l
On 06/21/2015 02:54 PM, Alexis King wrote:
I guess I could add a close-on-stop clauses for programmers
such as your son but it sounds almost like he's ready to move
on to racket proper, as in use the Windowing API directly.
FWIW, despite big-bang’s position as a teaching tool, I much prefer it
On Jun 21, 2015, at 2:54 PM, Alexis King wrote:
>> I guess I could add a close-on-stop clauses for programmers
>> such as your son but it sounds almost like he's ready to move
>> on to racket proper, as in use the Windowing API directly.
>
> FWIW, despite big-bang’s position as a teaching tool
The enclosed "big-crunch.rkt" library provides a `big-bang/big-crunch`
form that is the same as `big-bang`, but it closes the window with
`stop-when` produces #t. (I wrote it for my son.)
;; isl+
(require 2htdp/image)
(require 2htdp/universe)
(require "big-crunch.rkt")
(big-bang/big-crunch 1
> I guess I could add a close-on-stop clauses for programmers
> such as your son but it sounds almost like he's ready to move
> on to racket proper, as in use the Windowing API directly.
FWIW, despite big-bang’s position as a teaching tool, I much prefer it over
using the Windowing API directly,
Another option is to arrange that there is only ever a single call to
big-bang and there's a top-level data-type for the different modes of
the game:
World = EditorWorld | PlayerWorld
And when the Editor is ready it returns a Player. This can be a bit
awkward because of the need for a top-level d
It used to be that when you ran a program like this
;; isl+
(require 2htdp/image)
(require 2htdp/universe)
(big-bang 10
(to-draw (lambda (x) (circle (+ (* 10 x) 20) 'solid 'red)))
(on-tick sub1)
(stop-when zero?))
The window would shut down. But people wanted it to stay
open so that the
12 matches
Mail list logo
