On Fri, Mar 02, 2007 at 02:48:48PM -0700, Shawn Rutledge wrote: > I was hoping the same words would often reoccur on the display at the > same time. There would be a caching scheme, LRU or some such. Just > an idea, not sure if it's really better or not.
First off, noone would probably care if you rebind the texture for every letter, it isn't like there is a bad speed penalty for such small textures--especially for human reading speeds. Second, you could make one big texture will all of the letters on it, and use sub coordinates to pick the letters out as you render them. Depending on the resolution you want, some cards might not be able to load the texture, but these days, a 256x256 texture is probably more than enough. Unicode might be more difficult, but just load more font pages for what font you'd like to use. Third, if you wanted individual textures per letter, then you could sort the letters by frequency, load the first texture and draw all the letters in the right places on the screen, then bind the next texture. Seeing on how this is just text that a human reads, and that premature optimization is the root of all evil, I'd say do option one. Also, since you have the full bore of a 3d lighted texture mapping engine behind you, the IDE could be something fantasical to behold. Like undo buffers could go "into" the screen towards some vanishing point and you can select your mouse on undo regions to undo certain things whenver. It'd be sort of a visualization of vim's undo stacks behind the text, all dimmed down until you need to see it. Next idea. Ever see the dock on the new macosx? Suppose you have some code like this: file1.scm: (define foobar (thingy 1 2 3)) file2.scm: (define thingy (x y z) (+ x y z)) Then when editing file1.scm, if you drag your mouse over "foobar" in context (hell, might as well use chords on the keyboard and add a stroke interface), then the text all pushes to the sides (in a nice fluid manner) and the definition for (only) "thingy" fades in enditable form). You could then edit the definition of thingy (with all aspects of the editor available to you here), hit the "back" button or whatever, and go back to the original place you were. It's be like mixing ctags and hyperlinks. Debugging could be the same deal, "drilling" down into variables and stack frames and structures with hyperlink-like mouse clicks would make debugging stuff very awesome and fast. Then, if you'd like, you can save the entire drill down session as a virtual workspace on some big texture and move to something else.... the posibilities are endless. You'd make eclipse look like ed. Also, the one awesome thing about writing a scheme editor that can do all of this is that scheme is already in the ast form. You don't really have to write a serious parser to understand and catagorize everything like you do for java or C++. Doing stuff like refactoring on the fly in those languages is painful. In scheme, it could be much easier. You just walk the source and fix it in place. Parse errors can just be corrected to the next valid form and you'd probably get it right 99% of the time. Then, if someone ever invents a fundamental debugging specification format for scheme (think dwarf2 or stabs), then your debugger/editor can load it and present all sorts of awesome visual markup information for you. Highlighted scheme froms and bouncing parenthesis are so 1975. To bad that all IDEs _even today_ still basically do that (except type popups and context completion showed up in the early 90's, but when you conthink about it, it really only is an incremental evolution) and haven't even really *began* to touch the code/debugging visualization realms that only exist in programmer's heads. If you make this, don't copy what is already done, make something to behold! -pete _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
