Author Topic: Features Wishlist (Read 683517 times)

Deep Toaster · « **Reply #2715 on:** November 06, 2011, 08:33:51 pm »

Nope, use bitmasking (and, or, xor) for that.

Freyaday · « **Reply #2716 on:** November 11, 2011, 11:51:25 pm »

White rectangles and (why hasn't this been implemented yet) white lines. Also, inverted lines.

Keoni29 · « **Reply #2717 on:** November 12, 2011, 04:23:30 am »

Quote from: Freyaday on November 11, 2011, 11:51:25 pm

White rectangles and (why hasn't this been implemented yet) white lines. Also, inverted lines.

Use drawinv ... drawinv for that

Hayleia · « **Reply #2718 on:** November 12, 2011, 06:50:21 am »

Quote from: Keoni29 on November 12, 2011, 04:23:30 am

Quote from: Freyaday on November 11, 2011, 11:51:25 pm
White rectangles and (why hasn't this been implemented yet) white lines. Also, inverted lines.
Use drawinv ... drawinv for that

This will not work for inverted lines, only for white objects

But for a white rectangle, you also can do Rect(...) RectI(...)

Freyaday · « **Reply #2719 on:** November 12, 2011, 10:28:13 am »

Those are both much slower than a RectW() would be.

Happybobjr · « **Reply #2720 on:** November 12, 2011, 12:09:18 pm »

* Request: Rectangles that accept negative values in a reasonable manner

For so that the initial point could be the bottom left pixel

LincolnB · « **Reply #2721 on:** November 12, 2011, 04:30:13 pm »

the thing with using lots of DrawInv statements is that it's slow. I agree with Freyaday.

Also, have you considered my past idea? It was being able to absorb appvars into executables, the way you can with TI-OS pictures by going like this: [Pic1]->Pic1 . It would be awesome to be able to go like this: [appvBLAH]->GDB1

parserp · « **Reply #2722 on:** November 12, 2011, 05:41:20 pm »

Quote from: buttsfredkin on November 12, 2011, 04:30:13 pm

Also, have you considered my past idea? It was being able to absorb appvars into executables, the way you can with TI-OS pictures by going like this: [Pic1]->Pic1 . It would be awesome to be able to go like this: [appvBLAH]->GDB1

ooh that would be an AWESOME thing to have...

C0deH4cker · « **Reply #2723 on:** November 12, 2011, 10:36:42 pm »

Well, appvars cant be easily edited oncalc, so maybe we could do [prgmNAME]->GDB1.
In this case, the program should not be parsed as axe code. Another possibility is string vars.
[Str1]->Str1

Deep Toaster · « **Reply #2724 on:** November 13, 2011, 11:33:32 am »

I don't like the idea of importing programs because program variables generally store, well, program code, and you can import them with the prgm command. As for strings, I think that makes sense, but unfortunately strings in the TI-OS are token strings, while Axe and ASM strings are character strings, which are different except for the uppercase letters, digits, and theta.

shmibs · « **Reply #2725 on:** November 13, 2011, 12:11:40 pm »

Quote from: buttsfredkin on November 12, 2011, 04:30:13 pm

the thing with using lots of DrawInv statements is that it's slow. I agree with Freyaday.

Also, have you considered my past idea? It was being able to absorb appvars into executables, the way you can with TI-OS pictures by going like this: [Pic1]->Pic1 . It would be awesome to be able to go like this: [appvBLAH]->GDB1

what, exactly, would be the point of that? appvars are supposed to be variables, which can be modified during runtime and used to store data, but that takes effect only during compilation.

Quigibo · « **Reply #2726 on:** November 13, 2011, 07:14:02 pm »

I thought I already added this... oh well, I'll add it soon then. One use of this is computer generated data (For instance music, large pictures, levels, and more). Those can export to an appvar format and then you don't need to have tons of extra space taken up in your source code in hex form.

parserp · « **Reply #2727 on:** November 13, 2011, 07:18:10 pm »

Quote from: shmibs on November 13, 2011, 12:11:40 pm

Quote from: buttsfredkin on November 12, 2011, 04:30:13 pm
the thing with using lots of DrawInv statements is that it's slow. I agree with Freyaday.

Also, have you considered my past idea? It was being able to absorb appvars into executables, the way you can with TI-OS pictures by going like this: [Pic1]->Pic1 . It would be awesome to be able to go like this: [appvBLAH]->GDB1

what, exactly, would be the point of that? appvars are supposed to be variables, which can be modified during runtime and used to store data, but that takes effect only during compilation.

he means for levels and stuff that you don't change, they are just there for the picture, therefore all you would need is the executable and not all of the appvars

ztrumpet · « **Reply #2728 on:** November 13, 2011, 07:26:23 pm »

I'd love to be able to include AppVars in the source. That was one of the issues that plagued me in trying to put out the Cube Droid demo fast enough for the contest.

Freyaday · « **Reply #2729 on:** November 14, 2011, 12:12:33 pm »

Perhaps the absorbing syntax could be just having appvAPPVAR->constant on a line, similar to how it is with programs.

Author Topic: Features Wishlist (Read 683517 times)

Deep Toaster

Re: Features Wishlist

Freyaday

Re: Features Wishlist

Keoni29

Re: Features Wishlist

Hayleia

Re: Features Wishlist

Freyaday

Re: Features Wishlist

Happybobjr

Re: Features Wishlist

LincolnB

Re: Features Wishlist

parserp

Re: Features Wishlist

C0deH4cker

Re: Features Wishlist

Deep Toaster

Re: Features Wishlist

shmibs

Re: Features Wishlist

Quigibo

Re: Features Wishlist

parserp

Re: Features Wishlist

ztrumpet

Re: Features Wishlist

Freyaday

Re: Features Wishlist