[s1mp3-dev] Video API
csbluechip at gmail.com
Fri Jun 30 10:20:34 CDT 2006
At 14:21 30/06/2006, you wrote:
>I am writing this so i can get your help. It would be nice if we
>could finish the api definitions and start working on it, at least
>on parts of it, so i think we should start doing it.
>For the video API, there is some things to be decided, so i will
>point them out in this post, and ask all the users, and specially
>the ones with experience in graphics programming to coment on this
>topics so we can finally decide on them.
>All of this items come from reviewing the LCD API thread from the mail list.
>Thanks Legolas for commenting on the wiki.
>For reference, the api wiki page is:
>So, the things that are left hanging are:
>-line(tlx,tly,blx,bly) - blits a vectorial line of pixels, probable
>parameters will be width, color and (at higher levels) edges policy
> Should we add color, width and edges policy?
>I think we should add just a color parameter, for horizontal and
>vertical lines with width we can use the box function or similar,
>and i am note sure if there is much use in drawing a line with
>width.I lack of experience here. Opinions?
"blit" means BLock Image Transfer ...not sure you can "blit" a line
...think you "draw" a line.
Lines do not generally have a "top left" and "bottom left" ...they
tend to have "x1,y1" and "x2,y2"
(ignore all that if you don't care)
I think the last chat ended up with stating colour in the line() command
>-Should we take out ellipse and circle functions from the api and
>putting them apart since they are time consuming/memory consuming?
>I vote Yes.
Visual trig in an embedded mp3 kernel seems a chunk overkill.
I vote yes.
>-Box and fill functions: Is fill redundant as we define the box
>function?. In think it becomes redundant in hardware with simple lcd
>displays, as most of the fill needs can be covered with the box
>function, and implementing an irregular shape fill function could be
>tough. But i dont know for devices with more advanced displays. The
>processor is the same, so implementing it will be hard too, but
>could be of more use. What do you all think?
rectangular boxes which can be filled emptied or inverted
advanced graphics libs for games NOT in kernel
>-void blit(ui8 *bitmap, ui16 x, ui16 y, pen_t pen) - copy a certain
>bitmap to a certain position on the display using the specified pen
>Is this function redundant as we are going to define blit functions
>later in the api? I think it is, Please refer to the api.
What is the "pen" ...if it's "what colour" then realise you have just
crippled all your blits to monochrome
for now, implement BMP or PNG and drop the pen
>print(string); - This function Prints on screen a text determined by
>string, and advance x/y coordinates
>Somewhere in the road there were a discussion about having multiple
>definitions of this function until a more final release of the api
>is done. I thin we should start with just one, but if someone doesnt
>agree, it would be good to have some more declarations proposed.
There was a good solution for this last time - i remember liking it,
but dont remember what is was.
>-cls(color); - This function clears the screen, and fills it with a
>color determined by color.
>Should this function changes the color of the lcd backlight in the
>case of backlight colored LCDs? I think it would be nice, but either
>case, we should define a separate function to change the
>lcd_backlight alone. Thoughts?
clearscreen() does NOT control the backlight()
>void blit(u8 *source, u8 *dest,int x1, int y1, int x2, int y2,int
>area_w, int area_h,int pitch1, int pitch2 ); - This function draws a
>custom area of pixels , performing double buffering.
>This functiong appears to to be redundant with the ones defined
>above it. Please refer to the api, and comment if you think it
>should be removed. I think it should.
>-Someone thinks we should declare transparency entries to implement
>it later? Someone have proposition to make about this? I dont have
>the slightest idea...
alpha is simple enough
>-Are we going to use lcd prefix or video prefix? I vote for video.
lcd ...its quick and easy to type and anybody with an IQ over 50 will
>-Are we implementing video data ORing and ANDing? What do you think
Seems I utterly failed to explain this last time.
Answer me this ...What is ORing and ANDing (in this context) and what
is it's purpose
XOR is the only bitwise operation which makes sense in the context of
>That was the last one. I will be reviewing the STDIO api shortly, I
>will let you know when it is done.
STDIO is defined by the C programming language ...don't write or
review it ...just implement it.
>Thanks for your Help.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the s1mp3-dev