Hi, >> * cgetc() tries to manualy remove the cursor from the screen. this causes some >> pixels to be inverted when the function is called. > This can be easily fixed by switching off the cursor using "cursor (0);" after > establishing graphics mode. At least, if cgetc is implemented correctly Of course, how come I couldn't think of it? :) > As discussed a few days ago. LINE must not clip. This should be done (but is > currently not) in the wrapper code, so coordinates passed to LINE are always > valid. I saw the discussion and I reviewed some clipping algorithms. But even the simplest ones need signed integer divisions, which is not an area where 6502 shines. But, then again, if we can assume that clipping is already done, the LINE routines can be greatly optimized. Most clipping algos will not spend much time if the coords are already in range. So it may be reasonable to make out-of-range calls pay but let the in-range calls get away with little overhead. But since the wrapper does not implement clipping, for the time being, I can't replace the LINE routine. Because assuming valid parameters when it's not the case would wipe out random memory locations. Regards, Fatih. ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sun Oct 25 02:19:13 2009
This archive was generated by hypermail 2.1.8 : 2009-10-25 02:19:15 CET