[s1mp3-dev] LCD API
csbluechip at gmail.com
Sat Jun 3 20:28:20 CDT 2006
> >XORing video data is, or rather was, a very special thing ...I do not
> >think that AND and OR are really relevant here.
>Ok, but wait, isnt just a matter of op-code?
But ANDing and ORing data into video RAM
> >><sine.h> if you want to draw wavy things. The sine table is there, and
> >>only your program gets bigger. That's the deal.
> >OK - but of course this will not be a kernel feature, but compiled
> >into each and every app that uses it.
> >Perhaps we need runtime loadable libraries?
>:-) that's the beast we were handling on the wiki. Have a read down
>there if you wish. Let's collect all the possible features, then we'll
>split them into modules where needed. Without falling on "featuritis" of
>course ;) Ok, I am exaggerting with neologisms
"neologisms" nice word :)
I think that *IF* we go with the DLL (or whatever) idea, that would
should merely CONSIDER it when writing the core. At the speed we're
working at, I'm estimating about 4 months to write the API
spec. After that we get to spend some time writing a coding
spec. Then we get to start coding. Then testing and debugging. I'm
worried if all these great ideas mayt be discussed in place of things
which are relevant NOW ...and just HOW long will it be before we
write these highly complex chunks of code ...and will the person who
wanted it still be around to code it when the time comes?
So, let's just discuss whether we need loadable libs or not, and sort
out the fine print on this later :)
> >>I suggest:
> >>textout(string); // and DOES NOT advance x/y
> >>print(string); // DOES advance x/y understanding newlines
> >>and the macro variants
> >Yes, that seems fair :)
>Let's try to think what the programmers will need. We won't see
>programmers until next ICE age, but I am sure they will find something
subtle - lol
> >> Legolas
More information about the s1mp3-dev