Author Topic: Features Wishlist (Read 687149 times)

squidgetx · « **Reply #930 on:** July 13, 2010, 04:29:40 pm »

mrmrmmmrmrmm not really relevant to the current conversation, but I would like circle()r and line()r for drawing on the back buffer..

Quigibo · « **Reply #931 on:** July 13, 2010, 05:43:11 pm »

DJ, I'm confused. How would you be able to tell if a BASIC variable was created in Axe or not? For instance, my music generator creates a BASIC program that can be imported into Axe but suppose someone ran out of room so just left that program in memory and read it from the main program to play the music. That would be non-Axe generated file but definitely Axe compatible. Or what if you typed your data file in the TI-BASIC editor and it had a similar format to TI-BASIC for whatever reason? That would have to be allowed since its data.

The main problem with this is that Axe can generate ANY file with ANY combination of characters inside so technically all files are "Axe Created" and everyone will claim that they are. It is extremely easy since you can just fill the Data() command with all the tokens you need and then Copy() them into the program. I think what you're worried about most is that people will find a way to make a BASIC hybrid program somehow. But let me reassure you this is impossible due to rule #1 since Axe will not support any commands to run BASIC programs or Assembly programs during the duration of the contest (other than the Asm() command which is forbidden).

DJ Omnimaga · « **Reply #932 on:** July 13, 2010, 05:59:53 pm »

If someone's data program looks like this for example:

PRGM:A
[[0,0,0,0,0,0][0,1,1,1,1,1][0,1,1,1,1,1][0,1,1,1,1,0]]

This is how you store a matrix in Ans, in BASIC. Axe data looks much different than that.

I guess you might be right that it shouldn't be a big problem, though. I just get worried because in the past, people tried to figure out loopholes in my rules (in that case, to run ASM code without using Asm()) to use hybrid code, and I don't want something similar to happen again. I also try to take precautions in advance so when the contest ends, I don't have to disqualify full of entries because people thought they were allowed to do something.

Anyway, I noticed lately that I am getting harder and harder to be understood (including on IRC). I am not too sure why, but I am starting to question myself about my ability to communicate. I wonder if it wouldn't be best that I leave Axe help/features-related topics alone from now on?

Magic Banana · « **Reply #933 on:** July 13, 2010, 06:12:22 pm »

I've got a feature request: Sprite Transformations. Not the complex things like warping or skewing, but flipping and rotating tiles. I'm working on some maps, and I would like to save space by flipping tiles rather than create a whole new tile just for it. There doesn't seem to be any easy way to go about doing these things, so yeah.

DJ Omnimaga · « **Reply #934 on:** July 13, 2010, 06:21:01 pm »

Another feature request would be the ability to use Copy the following way, for example:

Conj(L1,L3+300)r

Instead of being forced to use pointers without any offset (like the +300), if you get what I mean.

Just an example.

The code above gives a BAD SYMBOL error, btw.EDIT nvm, I forgot to define the size

, my bad

jnesselr · « **Reply #935 on:** July 13, 2010, 06:21:22 pm »

The only problem with that, would be that it would most likely increase the length of the sprite routine. I would just do another sprite. It gives you more options that way.

[EDIT] @DJ What exactly would that do?

DJ Omnimaga · « **Reply #936 on:** July 13, 2010, 06:27:36 pm »

Nvm my post above, I forgot to define the size, which is why I got an error. my bad

_player1537 · « **Reply #937 on:** July 13, 2010, 08:16:27 pm »

I seem to recall something on cemetech doing this... I'll check real quick (in asm)

Edit: http://www.cemetech.net/forum/viewtopic.php?t=4264&sid=0d23df6917b27ead9b7f1052003327a1
Wasn't exactly what I thought it was (reverses HL, not just L) ... but meh

Quigibo · « **Reply #938 on:** July 13, 2010, 09:11:16 pm »

@DJ, no you are being clear, I think it is me who is not being clear. In the example you posted, if someone wants to format their data like that then that's their decision (although kind of a stupid one given you can get much higher efficiencies with your own formats). My point was that you can't ban certain data layouts just because they resemble BASIC.

Sprite rotation is actually much trickier than flipping, those are both on the wishlist already.

Something I was wondering though, would anyone be interested in specialty sprite routines? Sprite routines which are designed for very specific applications. Some ideas I had were:

3 level grayscale compact masking for 8x8 sprites. I used this in Pyoro, it basically allows you to use the unused bit combination as an extra transparency layer so you can have automatic grayscale masking without needing an extra mask layer. 00=transparent 01=white 10=gray 11=black
16x16 aligned sprite drawing. Its a super fast and small way to draw 16x16 sprites when they're aligned horizontally and also using a more convenient array for the sprite data than trying to make 4 8x8 sprites.
Unclipped unsafe 8x8 sprite drawing. Speeds up sprite drawing significantly for sprites that are always drawn completely on-screen for applications where speed really matters. But it would crash/corrupt data for sprites drawn partly or fully off-screen

Would anyone be interested in any of these? I would probably use the Plot1() - Plot3() tokens.

jnesselr · « **Reply #939 on:** July 13, 2010, 09:13:53 pm »

Can you explain the first one a little better? I don't quite understand it.

Quigibo · « **Reply #940 on:** July 13, 2010, 09:25:21 pm »

Here is the fruit sprite in Pyoro.

Layer 1 is 0 and Layer 2 is 0: Transparent, these pixels will be ignored when the sprite is drawn.
Layer 1 is 0 and Layer 2 is 1: A white pixel will be drawn here.
Layer 1 is 1 and Layer 2 is 0: A gray pixel will be drawn here.
Layer 1 is 1 and Layer 2 is 1: A black pixel will be drawn here.

Layer 1:
01110000
10001110
11100001
00010101
00111011
01101000
01111000
00110000
Layer 2:
01110000
11111110
11111111
00011111
00111011
01111000
01111000
00110000

jnesselr · « **Reply #941 on:** July 13, 2010, 09:28:40 pm »

So would you still need to use the buffer and back-buffer? If so, I thought this was already implemented.

Quigibo · « **Reply #942 on:** July 13, 2010, 09:30:54 pm »

No, currently a 3 level grayscale sprite is drawn like this:
00 = White
01 = Gray
10 = Black
11 = Black

and there is no way to do transparency without adding an extra sprite layer.

jnesselr · « **Reply #943 on:** July 13, 2010, 09:37:06 pm »

So no buffer/back buffer, and transparancy. Oh yes, please implement that! I don't know about aligned 16x16 sprites, but unaligned would work. I really don't think unclipped sprites is a good idea, because I will probably be the first one to corrupt something.

DJ Omnimaga · « **Reply #944 on:** July 13, 2010, 10:06:51 pm »

Quote from: Quigibo on July 13, 2010, 09:11:16 pm

@DJ, no you are being clear, I think it is me who is not being clear.

Aaah ok, well I wondered because in the recent few weeks, there were often people being confused at stuff I said on IRC, so I wondered if something wrong was going on with me or something

. Maybe I am just a bit tired and not double-checking my stuff well enough.

3 level gs compact masking seems cool, btw. Idk about the others, though, because I expect to mostly use unaligned stuff most of the time, like in Supersonic Ball

Author Topic: Features Wishlist (Read 687149 times)

squidgetx

Re: Features Wishlist

Quigibo

Re: Features Wishlist

DJ Omnimaga

Re: Features Wishlist

Magic Banana

Re: Features Wishlist

DJ Omnimaga

Re: Features Wishlist

jnesselr

Re: Features Wishlist

DJ Omnimaga

Re: Features Wishlist

_player1537

Re: Features Wishlist

Quigibo

Re: Features Wishlist

jnesselr

Re: Features Wishlist

Quigibo

Re: Features Wishlist

jnesselr

Re: Features Wishlist

Quigibo

Re: Features Wishlist

jnesselr

Re: Features Wishlist

DJ Omnimaga

Re: Features Wishlist