On Aug 10, 2015, at 1:19 PM, John Carmack <jo...@oculus.com> wrote: > We are just getting ready to “release” my son’s little Racket game, but after > doing all the development on OS-X, I find that the windows performance is > terrible. In hindsight, we should have just used bitmap / dc drawing > directly, but it grew out of playing with HTDP / Realm of Racket examples. > > It is a scrolling game, with a 4096 x 640 bitmap drawn into a 1280 x 640 > window.
[And I thought that by restricting the image size I could prevent that problem.] > It started out with the map just being a big image composed with place-image > for each solid object, but that got incrementally slower for every block in > the map. Freezing the image made it even slower. > > On the mac at least, I found that if I manually created a bitmap and draw the > objects into it with (send dc draw-bitmap …) then it would draw quickly, but > only if I used (send hidden-canvas make-bitmap …) to create the bitmap. > Using (make-platform-butmap …) or (make-screen-bitmap …) both resulted in > slow performance. > > On windows, it seems I always get slow performance. > > A simple testbed program that just draws the bitmap to a window with (send dc > draw-bitmap …) is fast, but the (place-image …) of the bitmap in the > 2htdp/universe program is slow, and it does seem to get slower with > increasing bitmap size. > > Any suggestions to save us from having to rewrite all the drawing code? place-image is highly protective and prunes the two images that are composed so that we get the 'expected' behavior (e.g., a line that crosses the boundary of a scene is cut off). I suspect that functions such as overlay and underlay and their cousins (same teachpack) are somewhat faster and may help here -- if you know that the images don't need pruning. Otherwise you repeat this calculation. In general, I will freely admit that 2htdp/universe and 2htdp/image were designed for learners from middle school through freshman year college. not full-fledged programs. We definitely need to think about a growth path from these simple libraries to performant programs, w/o giving up their functional character. It is possible and some of Jay's work goes in this direction (see package catalog). Our challenge is to make these approaches more compatible -- Matthias p.s. Robby (in Europe) and Jay may have a better take on how to improve the performance of the image part of your program. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
