John Carmack writes: > The performance problems were related to the larger scrolling worlds. The > H2DP versions got slower the more clouds were in the maps.
If the background is basically static but scrolling, you might get a substantial performance improvement by (define background (freeze <big-expression-that-builds-the-background>)) and using that variable henceforth. (The “freeze” function renders an image expression to a bitmap once and for all, trading memory for time.) If not the WHOLE background is basically static, but you have a lot of repeated elements (say, a bunch of identical clouds), you can (define cloud (freeze <big-expression-that-builds-a-cloud>)) and use that variable instead of the big expression henceforth. There’s no harm in doing both, e.g. (define background (freeze … cloud … cloud … cloud … )) although this won’t buy you any additional performance. > The idea that you functionally compose images like this: > ... > Which draws image1 on top of image2 on top of image 3, which is backwards > from the "painters order" that would draw image 3, then image 2, then image 1. > > This imperative, side-effect-ing code is a little less clear to a beginner > with the OOP and DC concepts, but It better represents what actually happens, > and it is much easier to modify the code without worrying about the nesting. It’s not clear to me that the imperative style “better represents what actually happens,” nor that this matters. However, there is a big win associated with the functional approach: it forces model-view separation from the beginning. Model-view separation is how almost all GUI programs are written, and failures to follow it cause a lot of the display bugs in GUI programs. Students who learn an imperative-first approach to GUI invariably end up writing display handlers that modify the model, or mouse handlers that draw to the display, causing the aforementioned display bugs. Stephen Bloch sbloch1...@gmail.com -- 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
