[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