From: groepaz (groepaz_at_gmx.net)
Date: 2001-08-15 17:32:00
Hello Mark, Wednesday, August 15, 2001, 5:20:01 PM, you wrote: KM> Hi, >> however, IMHO "real" blitter functionality (as in amiga-blitter) would >> be handy -no doubt- but unfortunatly be very inefficient considering >> we are aiming for a portable library approach. KM> <2 cents mode> KM> Is 'library' the wrong word here? Shouldn't this be 'interface'? KM> This allows portability but it doesn't imply that the implementation KM> has to be the same for the different platforms. Therefore I'd go for KM> the approach where Assembler routines do the low level work with a KM> 'common' API interface through 'C' calls. KM> Like it was mentioned before, calling 'SetPixel'/'Plot' (whatever) KM> has overheads of the parameter handling and so you wouldn't KM> implement Bresenham's in 'C' ;-) However, the SetPixel code would KM> be implemented with 2 entry points, one from C and one from ASM. KM> Hence a LineDraw function could internally use the ASM call to SetPixel. KM> As for blitting I would like to see it in the 'transform' sense, KM> i.e. supporting AND/OR/XOR operations between source and destination. KM> (Good for software sprites 'a la' Draconus/Zybex on the Atari :-) KM> Something like the Windoze GDI BitBlt function springs to mind. KM> </2 cents mode> uhm well yeah probably i choosed the wrong words here.... i ofcoz mean the same thing as you say..... i was referring to the fact that an optimised blitter-routine would only work for one specific resolution (or, gfx-mode) so the application using our library can only work at that specific resolution aswell when using the blitter functions.... oh well.... probably having seperate blitter-funcs for each mode (that includes AND/OR/XOR blitting aswell as different gfx mode with different resolution) is the way to go then. -- Best regards, groepaz mailto:groepaz_at_gmx.net ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:41 CET