On 9/28/06, Luís Oliveira luismbo@gmail.com wrote:
Send us a link. I'll put them in the cl-opengl tree.
Here they are, the website isn't yet but the link should still work. I still have some work to do, like putting back the comments for each line etc. Will I be able to use darcs to submit patches once it's up there? Also I sidestepped the whole image loading issue by putting all the image data (64x64x24 bits) into a lisp file. I'm open to suggestions.
http://charlie.burrows.googlepages.com/nehe.tar.gz
Enjoy! Charlie
p.s. sorry for double sending Luís; I just can trust gmail to dwim.
"Charlie Burrows" charlie.burrows@gmail.com writes:
Also I sidestepped the whole image loading issue by putting all the image data (64x64x24 bits) into a lisp file. I'm open to suggestions.
One idea that might be worth looking into is loading the data into an array at compile time using EVAL-WHEN. You can find the texture relative to the source file by using *COMPILE-FILE-PATHNAME* (perhaps falling back to *LOAD-PATHNAME* when loading the source).
This makes it easy to distribute textures as normal files but also doesn't require the texture file when delivering an executable.
James
On 9/28/06, James Bielman jamesjb@jamesjb.com wrote:
"Charlie Burrows" charlie.burrows@gmail.com writes:
Also I sidestepped the whole image loading issue by putting all the image data (64x64x24 bits) into a lisp file. I'm open to suggestions.
One idea that might be worth looking into is loading the data into an array at compile time using EVAL-WHEN. You can find the texture relative to the source file by using *COMPILE-FILE-PATHNAME* (perhaps falling back to *LOAD-PATHNAME* when loading the source).
This makes it easy to distribute textures as normal files but also doesn't require the texture file when delivering an executable.
James
Cool I will give that a try tomorrow. I've been using cl for ~4 years now and I still feel like I'm just scratching the surface. I like that!
Cheers, Charlie
cl-opengl-devel@common-lisp.net
-
Charlie Burrows -
James Bielman