Menu
▾
▴
Re: [Syllable-developer] ORC entry point API
|
From: <dem...@ne...> - 2008-06-26 16:39:53
|
The best part of it all is that no one will be using this API unless they are adding new drawing functionality to the AppServer itself.? This API allows a bit of leeway in allowing more functionality than we currently need.? Who knows, perhaps Kaj's additions will take advantage of the new commands.? It all seems as though this wouldn't matter, since I'm the only one who's really going to even be thinking about this code for a while.? But eventually, someone else will end up maintaining this part of the AppServer.? I would rather it not be a chore for someone else to take over.? Though, I am surprised that you're the only one to respond so far.... Dee Sharpe -----Original Message----- From: Jonas Jarvoll <jon...@sy...> To: syl...@li... Sent: Thu, 26 Jun 2008 11:03 am Subject: Re: [Syllable-developer] ORC entry point API sorry, I thought you were going to allow sending several commands in one go so to say. That also explains why you are considering splitting the prototypes. Hm, in way it would be easier with just one prototyp: The user will not need to know what prototype to use for what command. But then again the number of prototypes seems very few so I say go with your propsal. /Jonas ----- Original Message ----- From: "Dee Sharpe" <dem...@ne...> To: <syl...@li...> Sent: Thursday, June 26, 2008 5:21 PM Subject: Re: [Syllable-developer] ORC entry point API > There should only be one header for ORC, I need this to have as small > of a header footprint as possible. > > For lines, I'm going to modify the commands to specify between > connected lines & disjointed lines. For connected lines, every point > in the array adds a new endpoint to the segments. For disjointed > lines, every 2 points makes a new line. This is similar to how opengl > does it. Each new command requires new array setup & a new draw command. > > Dee Sharpe > > Sent from my iPhone > > On Jun 26, 2008, at 9:30 AM, jon...@sy... wrote: > >>> It's written in C++, however, you have to keep in mind that it's a >>> pass-through to the userspace video driver. As such, it's main >>> task is to >>> pass data to the video drivers after the appropriate manipulation. >>> This >>> is what allows us to draw primitives such as triangles & groups of >>> objects. >> >> OK, I understand. >> >>> When I consider the API to be bloated, I'm thinking from the point >>> of view >>> of looking at the headers. If there are tons of commands, then it >>> may >>> take a while before you find out which commands are actually >>> executing & >>> which ones just change state. Sometimes, there are just too many >>> functions. Consider Apple's Quicktime; there are hundreds of >>> function >>> prototypes, but how often are they all used? How many are there >>> taking up >>> space & only used for fringe case uses? For the most part, most of >>> those >>> prototypes are useless. >> >> Hehe, I think we on the same side here. What I mean is that an API >> is not >> per automatic bloated because it has many prototypes if you can >> motivate >> each and every one. However if you add prototypes which are rarely >> used >> just because someone someday might use it, yes, then I would >> consider the >> API bloated (like perhaps they have done in Quicktime). Im also >> trying to >> say that reducing the number of prototypes and adding several more >> parameters to the existing prototypes is not always the right way to >> reduce the bloatness in a API. On the contrary, it can make it even >> harder >> for the user of the API to understand it. >> >>> Actually, the single command is where I was headed, but before I >>> took that >>> step, I wanted to get some sort of concensus. Otherwise, all of my >>> prototypes would look exactly alike. At this point, the only >>> reason to >>> keep some of them seperate is to allow anyone who's reading the >>> header to >>> know with a glance what the functionality of that header is. >> >> well, I dont know how you are going to split the headers for ORC. Do >> you >> need to do that? >> >>> So far, I haven't needed to count how many entries are in the >>> arrays. In >>> earlier prototypes, this was needed. However, I find that I gain >>> speed by >>> having one less argument to decode. The actual implementation knows, >>> based off of the command argument, where to route the rest of the >>> data, >>> because it knows what kind of drawing is being done. However, if I >>> need >>> to add a counting variable, the solution is to add it as one of the >>> indexes in the array. Currently, the first index is always the >>> command. >>> It just might be prudent of me to make the second index the count of >>> arguments listed, excluding the command & the count variable. For >>> example, an array with 8 elements will have a count of 6. >> >> But in my example below how do ORC knows that it will be 7 line >> commands >> in a row and not 3 if you do not add some kind of count-variable? >> Cannot >> you mix commands, like sending two line commands followed by a >> triangle >> command? >> >>> OBJ_Obj_t aLines[7]; >>> m_pcBitmap->m_pcObjectRenderer->Draw( aLines, 7 ); >>> >>> OBJ_Obj_t aLine; >>> m_pcBitmap->m_pcObjectRenderer->Draw( &aLine, 1 ); >> >> >> >> >> --- >> ---------------------------------------------------------------------- >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services for >> just about anything Open Source. >> http://sourceforge.net/services/buy/index.php >> _______________________________________________ >> Syllable-developer mailing list >> Syl...@li... >> https://lists.sourceforge.net/lists/listinfo/syllable-developer > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > Syllable-developer mailing list > Syl...@li... > https://lists.sourceforge.net/lists/listinfo/syllable-developer ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Syllable-developer mailing list Syl...@li... https://lists.sourceforge.net/lists/listinfo/syllable-developer |