Author Topic: Features Wishlist (Read 690220 times)

Magic Banana · « **Reply #945 on:** July 14, 2010, 01:36:13 am »

All of those sprite features sound amazing! The 16x16 would definitely help for the bigger sprites, and the unclipped sprites sounds awesome for getting that extra speed. The clipping would also help and save space for making grayscale masking. Man, all of those sound great.

squidgetx · « **Reply #946 on:** July 14, 2010, 10:57:57 am »

Unaligned sprites i think would be nice as long as they use a different command so then ppl who need to draw stuff offscreen don't get messed up w/ it.

LordConiupiter · « **Reply #947 on:** July 14, 2010, 11:10:24 am »

I prefer the first, and the others I won't use very often I guess, but when it doesn't take too much time, they could also be very helpfull in certain circumstances, like you said.

BTW, how are you going to implement linking? Are you giving us the possibility to write to the linking ports like they where memory? Or will we get only the option of sending a variable item and then waiting while it is being send?

I was thinking by myself of using Send() for just writing data to the linkport, which would be usefull for music or selfmade things,
and Get() for requesting data from an other calculator, which should be in some Pause-mode or something with the command Rect(), which could be changed to React()

FinaleTI · « **Reply #948 on:** July 14, 2010, 11:15:01 am »

The special sprite routines sound awesome! I would love to see them implemented.

Quigibo · « **Reply #949 on:** July 14, 2010, 01:14:08 pm »

Ok, I think I'll just stick to the compact masking routine and not the others. The second one is easy to make with the Axe language itself and the third is probably unnecessary. But I did think of ANOTHER Dispgraph routine I might add. I have too many ^r modifiers so it might be an ^o modifier but it would use the extra clock cycles, which are normally wasted, to clear the buffer at the same time as drawing to the screen so you never need a ClrDraw. It would speed up programs using that a lot probably because ClrDraw is a slow OS routine.

Linking can work 2 ways. You can either do manual linking; setting the individual lines high and low and writing the link routine yourself, or automatic linking; using my own assembly routines. So I assume you are asking about my built in routine. The way it works is that it is mostly controlled by the sender. It is up to the receiver to check the linkport constantly to see if a byte is trying to be sent, if no byte is being sent, the linker proceeds as normal and does not wait. The sender however will wait for the receiver to confirm that it got the message that it needs to receive the byte. You will specify a timeout for the Send() routine so that the calculator doesn't freeze if you disconnect the other calculator. The sending command will return a 1 or 0 depending on whether it was able to send the byte. The receiver will return a -1 if no bytes were sent or the byte itself if one was. I will explain it better when I actually have the commands added.

Builderboy · « **Reply #950 on:** July 14, 2010, 02:19:32 pm »

ClrDraw is slow? Isnt it just a matter of 0->{L6}:Fill(L6,768)?

And automatic linking sounds like an excellent idea

Kind of like a 1-up of Omnicalcs Linking features.

LordConiupiter · « **Reply #951 on:** July 14, 2010, 04:33:20 pm »

Could u please change the Line() command to behave the same as the BASIC Line() command? I am namely converting my BASIC data to the Axe format, and I use the Line() command with it.

with 'behave', I mean which pixel is turned on when u draw Line(0,1,2,0) for example; pixel (1,0) or (1,1)
In BASIC this is just a little bit different, and therefore some of my converted graphics look ugly.

in BASIC the pixel which is nearest to the left top of the screen is set, so in my example BASIC would choose for (1,0), but Axe chooses (1,1)

Magic Banana · « **Reply #952 on:** July 14, 2010, 05:37:54 pm »

For the inverted Line, it' s a little tedious, but you can do:

Code: [Select]

DrawInv
Line(X1,Y1,X2,Y2
DrawInv

Or you can just do DrawInv once, draw all of your white lines, then use DrawInv again.

nemo · « **Reply #953 on:** July 14, 2010, 08:13:51 pm »

the three sprite routines quigibo posted earlier sound great. i would love to see them implemented.
also, someone spoke about rotating/flipping sprites as a built in command. instead of that, could we have a pxl-swap() command? the syntax would be something like pxl-swap(x1,y1,x2,y2). so if (0,0) is a black pixel and (0,1) is a white pixel, pxl-swap(0,0,0,1) would make (0,0) white and (0,1) black. i think this would greatly simplify the process of rotating and flipping sprites 90° can be implemented with some linear algebra and a pxl-swap() command.

Magic Banana · « **Reply #954 on:** July 14, 2010, 08:56:06 pm »

Quote from: nemo on July 14, 2010, 08:13:51 pm

the three sprite routines quigibo posted earlier sound great. i would love to see them implemented.
also, someone spoke about rotating/flipping sprites as a built in command. instead of that, could we have a pxl-swap() command? the syntax would be something like pxl-swap(x1,y1,x2,y2). so if (0,0) is a black pixel and (0,1) is a white pixel, pxl-swap(0,0,0,1) would make (0,0) white and (0,1) black. i think this would greatly simplify the process of rotating and flipping sprites 90° can be implemented with some linear algebra and a pxl-swap() command.

Eh, Pxl-Change?

nemo · « **Reply #955 on:** July 14, 2010, 09:04:13 pm »

it already has a use, so it may be a bit confusing to use. i'm not sure what token would be used, just thought it seemed like a relatively simple operation. i imagine you could do this with the exch() command and some very tricky modular arithmetic in the free RAM area L6, if anyone wants to try... i'll probably attempt later.

Quigibo · « **Reply #956 on:** July 14, 2010, 09:07:14 pm »

Not inverting, swapping separate locations. Although you can already write your own routine for that, its relatively slow and not suitable for a rotation command.

LordConiupiter, I don't do it the BASIC way because I like to do it the faster way. I'm thinking of rewriting the line routine in the future to make it faster but for now, I can't really change it.

By the way, the reason I can't draw the circle or line to the backbuffer is that the routines are hardwired into the primary buffer and are not possible hijack like my other routines. For instance, the sprite drawing routine defines what buffer it will draw to in the very beginning of the routine so all I have to do is define a different buffer before calling it and then call the routine a little further down than it's normally called, skipping the part about the regular buffer, to hijack it with the new buffer. This isn't possible with the circle or line since the buffer is defined in the middle. I would have to write entirely separate routines since they can't share and it would inflate the code.

LordConiupiter · « **Reply #957 on:** July 15, 2010, 01:36:48 am »

Well, I guess I will have to write my own Line() command. I'll do this in Axe as a sub, but I've no ID how to draw a line in a buffer? could u please give a very nbasic way a drawing a line? (i do not mean with Pxl-On() etc, just with writing bytes to the buffer, because I want to be able to write to custom buffers)

If you want to draw something to the backbuffer, u just can do this:

Code: (Axe) [Select]

Exch(L3,L6,768)
Line(0,0,96,64)
Exch(L3,L6,768)

I think that would be the fastest way at this moment. When I finish my linedrawing sub for Axe. I'll post it in Routines, so u can use it for any buffer.

squidgetx · « **Reply #958 on:** July 17, 2010, 08:32:19 pm »

Quote from: Quigibo on July 14, 2010, 09:07:14 pm

Not inverting, swapping separate locations. Although you can already write your own routine for that, its relatively slow and not suitable for a rotation command.

LordConiupiter, I don't do it the BASIC way because I like to do it the faster way. I'm thinking of rewriting the line routine in the future to make it faster but for now, I can't really change it.

By the way, the reason I can't draw the circle or line to the backbuffer is that the routines are hardwired into the primary buffer and are not possible hijack like my other routines. For instance, the sprite drawing routine defines what buffer it will draw to in the very beginning of the routine so all I have to do is define a different buffer before calling it and then call the routine a little further down than it's normally called, skipping the part about the regular buffer, to hijack it with the new buffer. This isn't possible with the circle or line since the buffer is defined in the middle. I would have to write entirely separate routines since they can't share and it would inflate the code.

Damn.

Quote from: LordConiupiter on July 15, 2010, 01:36:48 am

Well, I guess I will have to write my own Line() command. I'll do this in Axe as a sub, but I've no ID how to draw a line in a buffer? could u please give a very nbasic way a drawing a line? (i do not mean with Pxl-On() etc, just with writing bytes to the buffer, because I want to be able to write to custom buffers)

If you want to draw something to the backbuffer, u just can do this:
Code: (Axe) [Select]
Exch(L3,L6,768) Line(0,0,96,64) Exch(L3,L6,768)I think that would be the fastest way at this moment. When I finish my linedrawing sub for Axe. I'll post it in Routines, so u can use it for any buffer.

ummmm i guess...(a little sleepy right now)

Magic Banana · « **Reply #959 on:** July 18, 2010, 02:19:11 am »

I've always wondered, why does grayscale work on 6mhz, but not 15? It would seem like it would be so much better running on 15mhz, probably flickerless, but it just doesn't. Can anyone explain how that works? Since I'm here I guess I can request 15mhz grayscale if possible.

Author Topic: Features Wishlist (Read 690220 times)

Magic Banana

Re: Features Wishlist

squidgetx

Re: Features Wishlist

LordConiupiter

Re: Features Wishlist

FinaleTI

Re: Features Wishlist

Quigibo

Re: Features Wishlist

Builderboy

Re: Features Wishlist

LordConiupiter

Re: Features Wishlist

Magic Banana

Re: Features Wishlist

nemo

Re: Features Wishlist

Magic Banana

Re: Features Wishlist

nemo

Re: Features Wishlist

Quigibo

Re: Features Wishlist

LordConiupiter

Re: Features Wishlist

squidgetx

Re: Features Wishlist

Magic Banana

Re: Features Wishlist