[s1mp3-dev] LCD API
Legolas
legolas558 at email.it
Fri Jun 2 04:24:04 CDT 2006
Bluechip ha scritto:
>The problem is that if you call plot() lots of times, you are
>increasing your internal data load by 50% !
>
>
A function to draw a custom area of pixels into another area and a
function ("plot()") to draw a single pixel. A real application will use
only the former.
void blit(
// source and destination buffers, in the case we have double buffering
or we want to perform image assembly
u8 *source, u8 *dest,
// relative offsets
int x1, int y1, int x2, int y2,
// size of the are that will be copied
int area_w, int area_h,
// did you guess them?
int pitch1, int pitch2 );
This is not API but more likely the core routine that will draw "pieces"
of images. The relative offsets must be implemented through macro (e.g.
to be added on the source/dest pointers) In the case we do not have
double buffering the above does not have 'dest' and directly blits to
the hardware.
>
>
>>Otherwise XOR could be a colour or another flag.
>>
>>
>
>If XOR does not perform manipulation of paper/ink colours, then I
>think it is anomolous and should be removed altogether.
>
>
Why don't we have 'XOR' 'AND' 'OR' ... as constants which are the
op-codes themselves and the different macro-defined functions pass the
opcode as a parameter? Then the function gets patched at runtime with
the opcode (only one location identified by a label). Okay, too hacky...
>
>
>>It might be needed for ellipse though (forgot highschool
>>math, I was busy flipping the LCD filter of my calculator).
>>
>>
>
>LOL
>Yes, circles (and their squished variants) need a sine table or sine
>generator, one is big, the other is slow (respectively).
>
>
<sine.h> if you want to draw wavy things. The sine table is there, and
only your program gets bigger. That's the deal.
>
>
>>>box(tlx,tly, brx,bry)
>>>
>>>? How do we specify whether the box be OUTLINE, FILLED or XOR'ed?
>>>
>>>
>>Separate routines.
>>
>>
>
>Not to disagree with you, just that thinking about my response to you
>I had another idea.
>box(tlx,tly, brx,bry, mode)
>if mode is a UI8, we can use 1 bit per feature and have:
>// OUTLINE
>#define TOP 0x01
>#define BOTTOM 0x02
>#define RIGHT 0x04
>#define LEFT 0x08
>// CONTENT
>#define FILL 0x10
>#define INVERT 0x20 // NEEDS STATEFUL PEN AND INK?
>
>still think seperate routines are better? (straight question, no sarcasm!)
>
>
Flags way is the best.
>
>
>>>print(x,y,string)
>>>
>>>? do we:
>>>printat(x,y, string)
>>>or
>>>cursor(x,y); print(string)
>>>
>>>
>>Former.
>>
>>
>
>I agreed with you until legolas said:
>
>"if we have seperate routines, we can make a macro to combine them"
>so
>#define printat(x,y,s) do { cursor(x,y); print(s); } while(0)
>
>
I suggest:
gotoxy(x,y);
textout(string); // and DOES NOT advance x/y
print(string); // DOES advance x/y understanding newlines
and the macro variants
--
Legolas
More information about the s1mp3-dev
mailing list