Author Topic: Features Wishlist (Read 702977 times)

C0deH4cker · « **Reply #2940 on:** January 24, 2012, 05:59:20 pm »

I think that he just wants to draw a white line, not remove an existing line. Like this:

###### ###### ###### ######

to this:

# #### ## ### ### ## #### #

thydowulays · « **Reply #2941 on:** January 24, 2012, 08:01:01 pm »

Oh I see....
Hmm..... well I can't really help you there.

squidgetx · « **Reply #2942 on:** January 25, 2012, 03:14:46 pm »

Request:
Option to turn off the progress bar and just show percentages like in old versions for faster compiling, or alternatively have it be off by default for zoomed compiles

C0deH4cker · « **Reply #2943 on:** January 25, 2012, 05:21:44 pm »

Request: bit shifting

Builderboy · « **Reply #2944 on:** January 25, 2012, 06:20:28 pm »

It can be done by using *2 to shift to the left and /2 to shift to the right.

C0deH4cker · « **Reply #2945 on:** January 25, 2012, 07:29:51 pm »

Okay, nevermind. isnt that slower than just using the bit shift instructions though?

Builderboy · « **Reply #2946 on:** January 25, 2012, 07:54:29 pm »

It uses the bitshifting instructions as an optimization, so it's exactly the same

Quigibo · « **Reply #2947 on:** January 25, 2012, 10:07:22 pm »

Quote from: squidgetx on January 25, 2012, 03:14:46 pm

Request:
Option to turn off the progress bar and just show percentages like in old versions for faster compiling, or alternatively have it be off by default for zoomed compiles

Its essentially the same speed, it takes almost the same amount of time to display the percentage bar as it did just displaying the percent. However, this can be sped up by maybe 15% if I display nothing at all, but that's a bad experience for the end user since they feel like it freezes. It wouldn't be that much faster anyway, its not like its double the speed or anything.

I am still considering adding a white line command but there is no token for it. Adding an extra argument is unoptimized and I don't want to invent some obscure syntax for it either. I would probably end up overwriting the Plot3() token instead. The routine is large though, just as large as the black line drawing, so only use it if you absolutely have to and need more speed than the DrawInv method. Of course, if you decide to use the experimental Axe Framework, this is never an issue

.

Darl181 · « **Reply #2948 on:** January 25, 2012, 10:20:04 pm »

Would it be unreasonable to watch for a Xor-ing line command as well?

Quigibo · « **Reply #2949 on:** January 25, 2012, 10:23:05 pm »

Well... I could do what I did for the Rect() command in that there are only options for "Black" and "Invert". You would just have to draw both of them to get white. That's probably what I'd do.

But even more important than that, what I really REALLY want is line clipping. I have yet to find an algorithm simple enough to implement efficiently in z80 but I challenge anyone to write a routine for it

Runer112 · « **Reply #2950 on:** January 25, 2012, 10:31:13 pm »

Just wondering, why is something like Line(X1,Y1,X2,Y2,MODE) not possible? I would imagine that, since you do have complete control to do whatever you want in the parser, you could have special-case parsing like this.

Builderboy · « **Reply #2951 on:** January 25, 2012, 10:59:46 pm »

As long as it isn't variable based mode select, I think the 5th argument should be a valid option, but the problems arise when variables are introduced

Freyaday · « **Reply #2952 on:** January 25, 2012, 11:19:06 pm »

But the variables are what make it fun!

Quigibo · « **Reply #2953 on:** January 26, 2012, 12:21:04 am »

There is already an optional buffer argument, I can't use that spot for mode unless you're talking about an optional 6th argument but its a weird syntax since the 0 or 1 is part of the syntax rather than a variable.

Runer112 · « **Reply #2954 on:** January 26, 2012, 12:35:06 am »

Hmm I didn't think about the buffer argument... But making it an optional 6th argument would definitely work. However, I think it would also be nice if it were allowed to be an optional 5th argument and let the parser intelligently decide if the 5th argument is a buffer or mode. If it's a constant less than the total number of modes, treat it as a mode argument and direct the parser to the appropriate-colored routine. Otherwise, treat it as a buffer argument, because you shouldn't have a constant buffer argument that's any less than 32768 anyways. If this were possible, it would probably also be nice to apply this to the Bitmap() command, and possibly a new syntax for Rect() that allows for a mode argument. That could also solve the issue of white rectangles being bloated/slow, as you could add a white rectangle routine as a mode for Rect().

~~And I'm not sure what you mean about the optional 0 or 1 (or a 2 perhaps for xor) argument being a weird syntax, so I can't address that.~~
Just kidding, I just figured out what you meant. I don't see why it's that weird, the user doesn't need to know that it's really a constant that gets special-cased by the parser. It would probably seem just like the mode argument for Bitmap(), albeit possibly with different codes. And it would be pretty much exactly like how Line() works in TI-BASIC, so it should be very easy to pick up.

Author Topic: Features Wishlist (Read 702977 times)

C0deH4cker

Re: Features Wishlist

thydowulays

Re: Features Wishlist

squidgetx

Re: Features Wishlist

C0deH4cker

Re: Features Wishlist

Builderboy

Re: Features Wishlist

C0deH4cker

Re: Features Wishlist

Builderboy

Re: Features Wishlist

Quigibo

Re: Features Wishlist

Darl181

Re: Features Wishlist

Quigibo

Re: Features Wishlist

Runer112

Re: Features Wishlist

Builderboy

Re: Features Wishlist

Freyaday

Re: Features Wishlist

Quigibo

Re: Features Wishlist

Runer112

Re: Features Wishlist