Author Topic: Routines (Read 314168 times)

SirCmpwn · « **Reply #240 on:** April 06, 2010, 07:27:01 pm »

Please clarify what you mean by "place"

Builderboy · « **Reply #241 on:** April 06, 2010, 07:31:17 pm »

Like, in Base 10 we have the 1s place, the 10s place, the 100s place.

in 1234 the 3 is in the 10s place. The 2 is in the 100s place.

With Other bases, its just the same, like in hex you have the 1s place, the 16s place, the 256s place, ect...

meishe91 · « **Reply #242 on:** April 06, 2010, 07:35:45 pm »

Ya, sorry. I meant the exponent spot, I guess. I don't know the technical term, but what Builderboy said is what I meant.

Ex:
Decimal: 1000, 100, 10, 1
Binary: 32, 16, 8, 4, 2, 1
Octal: 4096, 512, 64, 8, 1 (I believe)

SirCmpwn · « **Reply #243 on:** April 06, 2010, 07:39:37 pm »

Quote from: meishe91 on April 06, 2010, 07:35:45 pm

Binary: 32, 16, 8, 4, 2, 1

I'm not entirely sure what your example is, but this cannot possibly be binary. Binary is base 2, with ones and zeroes. Not 3s, 2s, 6s, 8s, and 4s.

Builderboy · « **Reply #244 on:** April 06, 2010, 07:42:36 pm »

He's talking about the decimal places. In binary, the 2nd decimal place has an exponent of 2, the 3rd with an exponent of 4, the 4th with 8 and so on. Just like how in Base 10 the 2nd decimal place has an exponent of 10, the 3rd with 100 and so on...

SirCmpwn · « **Reply #245 on:** April 06, 2010, 07:43:15 pm »

Oh, okay. Oops again.

Juju · « **Reply #246 on:** April 06, 2010, 07:59:23 pm »

A table can be useful:
1b = 1d
10b = 2d
100b = 4d
1000b = 8d
10000b = 16d
etc.

So, if you want to convert, say, 11000, you may want to do 11000b = 10000b + 1000b = 16d + 8d = 24d
It's so simple.

calc84maniac · « **Reply #247 on:** April 06, 2010, 08:04:13 pm »

Also, it is easy to convert between hexadecimal and binary. Each hex digit corresponds to 4 binary digits.

meishe91 · « **Reply #248 on:** April 06, 2010, 08:14:30 pm »

Sorry about the confussion, SirCmpwn. Thanks, guys.

DJ Omnimaga · « **Reply #249 on:** April 06, 2010, 11:07:32 pm »

My only issue with hex is when you have to convert 500 numbers to it, it takes so friggin long

I feel more enlightened about L6 now, though. However, question: does changing a byte in L6 automatically update the LCD or will you need to update the graph buffer? Also I assume updating the screen from L6 is considerably faster than pt-on/pxl-on, right?

calc84maniac · « **Reply #250 on:** April 06, 2010, 11:12:33 pm »

Quote from: DJ Omnimaga on April 06, 2010, 11:07:32 pm

My only issue with hex is when you have to convert 500 numbers to it, it takes so friggin long

I feel more enlightened about L6 now, though. However, question: does changing a byte in L6 automatically update the LCD or will you need to update the graph buffer? Also I assume updating the screen from L6 is considerably faster than pt-on/pxl-on, right?

Well, L6 is the graph buffer. You will need to update the screen manually though. And speed-wise, in theory this would be faster, but since we are comparing Axe code with optimized Asm routines, it's hard to tell.

SirCmpwn · « **Reply #251 on:** April 06, 2010, 11:16:08 pm »

Well, I think there may be some confusion here. The screen is 95x63 pixels in size. That is a total of 5985 pixels. The graph buffer is not 5989 bytes long. It is 748 bytes long. This works because it is monochrome (black and white). A pixel is only ever on, or off. Because of that, you can use binary. There are 8 bits to a single byte, so if you wanted a dotted line, you could write 01010101b to the graph buffer.
Why this matters is that you can't just write a 1 to the graph buffer and expect a single pixel to change. From what I know of Axe, it would be very hard indeed to manually change each pixel.

calc84maniac · « **Reply #252 on:** April 06, 2010, 11:27:08 pm »

Quote from: SirCmpwn on April 06, 2010, 11:16:08 pm

Well, I think there may be some confusion here. The screen is 95x63 pixels in size. That is a total of 5985 pixels. The graph buffer is not 5989 bytes long. It is 748 bytes long. This works because it is monochrome (black and white). A pixel is only ever on, or off. Because of that, you can use binary. There are 8 bits to a single byte, so if you wanted a dotted line, you could write 01010101b to the graph buffer.
Why this matters is that you can't just write a 1 to the graph buffer and expect a single pixel to change. From what I know of Axe, it would be very hard indeed to manually change each pixel.

It is 96x64 actually, and 768 bytes

Builderboy · « **Reply #253 on:** April 06, 2010, 11:37:34 pm »

96x64 but i know what you mean. Yeah writing directly to the buffer is faster in some cases, like filling with paterns or doing other sort of drawing, but when doing pixel by pixel the math required to find the masks is a slower if you are filling large regions.

On a different note, in photo today i played around with greyscale. The program below contains a sub that draws a colored pixel into the two buffers, dithering when necessary. The colors range from 0 to 2 where 0 is white, 1 is grey, and 2 is black. With that i wrote a small greyscale paint program to play around with

The bitmasking required to write pixels was a bit weird, and im not sure if im finding the masks in the most efficient way possible, but it works

EDIT: oh and its [2nd] for black, [ALPHA] for grey, [CLEAR] for white, and + to exit. Arrow keys to move of course

DJ Omnimaga · « **Reply #254 on:** April 06, 2010, 11:42:50 pm »

Quote from: SirCmpwn on April 06, 2010, 11:16:08 pm

Well, I think there may be some confusion here. The screen is 95x63 pixels in size. That is a total of 5985 pixels. The graph buffer is not 5989 bytes long. It is 748 bytes long. This works because it is monochrome (black and white). A pixel is only ever on, or off. Because of that, you can use binary. There are 8 bits to a single byte, so if you wanted a dotted line, you could write 01010101b to the graph buffer.
Why this matters is that you can't just write a 1 to the graph buffer and expect a single pixel to change. From what I know of Axe, it would be very hard indeed to manually change each pixel.

oh wait I forgot about each pixels being one bit, not one byte

, sorry for confusing both.

I guess for each string of 8 pixels, what pixel would change would depend of the hex value for that string of 8 pixel, right?

But yeah I remember a month or two ago Quigibo telling me updating the screen buffer directly was much faster than updating it with pxl-on commands. Example: my screen pixelating routine, which I think is on page 3 of this thread.

AND WOW BUILDERBOY! Nice

Author Topic: Routines (Read 314168 times)

SirCmpwn

Re: Routines

Builderboy

Re: Routines

meishe91

Re: Routines

SirCmpwn

Re: Routines

Builderboy

Re: Routines

SirCmpwn

Re: Routines

Juju

Re: Routines

calc84maniac

Re: Routines

meishe91

Re: Routines

DJ Omnimaga

Re: Routines

calc84maniac

Re: Routines

SirCmpwn

Re: Routines

calc84maniac

Re: Routines

Builderboy

Re: Routines

DJ Omnimaga

Re: Routines