Coding again
Bwain| April 17th, 2007Going to FINALLY start coding again. Just finished spiderman 3, ordered NEW GEAR, all new mac stuff to finally replace this poor Dell computer that I think I bought sometime in 2000 or so. 7 years old, I’m glad it made it this far. The Mac stuff should arrive within a week, so that should hopefully be enough time to put it together.
I just looked at the old ‘todo.txt’ in spa/app/spaExe, and I’m hoping that this blog will do a much better job of keeping track of shit than a single text file.
So the last thing I was working on was the grammer for the shading language. Lets see if I can get something decent compiled. I was working on lcc. I’m trying to get a simple example working that will produce the same output as the simd assembly that I hand coded. The problem (now that my memory is coming back to me) is that I was trying to find a way to generalize the compiler to handle geometry, images, everything possible. It would be kinda wasteful to try and figure out all generalizations now, I should just work on getting this example working for images. I just have to define some default variables (like size and position) and it should work.
Ah… also the default scalar flag I was thinking about. I realized that depending on context, we want scalar values to default to either doubles or float. I’m putting that in now… Done.. that was simple.
Now faced with the way to defined I/O variables. We *could* compile them into the compiler, but that’s definitely not the way to go. We want to have header files to define these variables. But then that brings up the problem of generalizing ‘include’ paths and using the c pre-processor. We’re not going to do that… I’ll hand code the global variables for now, we’ll try using the c-preprocessor later.
Added a globals keyword, so we can declare global variables. This will turn out to be more flexible than renderman or mantra. We will be able to declare user defined globals at compile time. The user will have to know what the expected I/O variable names are, but they can also keep some globals handy for computational/signalling purposes.
One aspect that I have to start dealing with is the whole varying/non varying temp variable initialization. With a little overhead, I can have user defined temp variables default as non-varying, and have them mutate to varying as needed. Keeps the overhead at a minimum as well. I was going to handle this on the fly, but on second hand, I think it might be easier to do as an operation in a 2nd pass. There are too many things to add and take care of.
GOT IT WORKING.
The parser can suck in the full shader file that duplicates the assembly file test. Next is spitting out assembly code. Maybe by tomorrow??? YES


