I'm not sure how to make the HTDP drawing faster, but I can say how using my library (mode-lambda) relates to it and maybe it will be easy to port your program.
mode-lambda compiles graphical data into a big sprite atlas and draws the whole scene with a single glDraw call. The graphical data can be provided as image files, 2htdp/image objects, picts, or its own special format. Each scene is essentially a list of sprites that are simple structures that have the 2D position, Z layer, which sprite is used, plus independent scaling and rotation and color tinting. Each Z layer can have its own scaling and rotation (plus other stuff). The engine takes two such trees and ensures that if it receives the same tree on back-to-back frames it doesn't update the GPU. So, a huge amount of a 2htdp/image program can be reused. Most games in RoR and other sources I've seen use the image algebra to construct individual objects, but only combine them together using iterated calls to place-image. If that is the case, then it is simple to port things directly because those place-images just become "cons + make-sprite". On the other hand, if whole constellations of objects are scaled/rotated/etc, then porting is much more difficult. I'm happy to look at the code and suggest whether a port could work for you. I have a strong interest in making a version of universe + image that automatically uses my engine as a compatible backend, but I haven't invested the time yet. Jay On Mon, Aug 10, 2015 at 2:35 PM, Matthias Felleisen <matth...@ccs.neu.edu> wrote: > > 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. -- Jay McCarthy http://jeapostrophe.github.io "Wherefore, be not weary in well-doing, for ye are laying the foundation of a great work. And out of small things proceedeth that which is great." - D&C 64:33 -- 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.
