Welcome to the second instalment in The ExeSoft ExeSketch Explanation Series of Presently Undefined Length. This particular informational outpouring concerns the item of code positioned directly adjacent to the EventHandler in the chronological stream of linear storytelling. That is to say, it was the next thing I wrote. (I'm endeavouring to eschew bombastic grandiloquence. Aagh, dammit.)
This is another class whose inspiration stems from difficulties I faced implementing requested features into CurveDraw's code. The problem with CurveDraw was that the view was completely static - if something went off-screen unintentionally, it was effectively lost. The edges of the screen served as that point in a sofa where the seat-cushions meet the back-cushions, except in CurveDraw there was a bottomless pit underneath, and the cushions were sewn on meaning that any attempt at catching something was rendered impossible. And the sofa was made of spikes. Probably. Similarly, editing a curve of more than moderate intricacy would be a case of pressing your face right against the screen, magnifying glass in hand, moving the mouse as accurately as possible with both hands so as not to drag the wrong point or make a mess of the curve handles. (EDIT: Yes, I know I just filled three hands. Get a friend to hold the magnifying glass or something.) The obvious void to be found in its existing feature set was one which might have been comfortably filled by zoom and pan features; unfortunately, to code such a thing was a concept standing quite without the realms of possibility.
The issue was that points in objects were stored as pixel co-ordinates instead of co-ordinates in arbitrary 2D space, and pan/zoom would involve adding appropriate variables to the code for offset and scale and then setting up transformation functions for each object's individual points and for object centres, all of which would amount to a lot of messy coding and awkward global variable usage.
These issues are resolved in ExeSketch by defining all points in arbitrary 2D space (referred to in ExeSketch as real co-ordinates), as suggested above. Each object has a centre point defined in real co-ordinates, and the object's points are defined relative to that centre point (in local co-ordinates). When it comes to drawing, a single redraw command is sent from the main program through to the display class, ObjectDisplay, which sets up an OpenGL transformation matrix using variables it stores for the camera offset and the zoom factor. It then simply sends a redraw call to each object registered with it, and Bob's your teapot.
Another advantage of having this class to handle the display camera is that zoom and pan can be handled by event handling functions within the class, thus clearing potential clutter from the main file. (That's the reason for the EventHandler having a reference to the display object, as mentioned in the previous post explaining the event system.)
And that, as far as I can tell, is pretty much all there is to know about the display. You may have noticed I'm not going into much detail about the code that makes this stuff happen in this series; it's simply an explanation of how the myriad classes interact and why. For those interested in the code itself, the project is of course open-source; ye who seek it shall be rewarded, should you incline your browsing hither. And once again, my (transient few) readers, I bid thee goodbye.
No comments:
Post a Comment