### Author Topic: Axe Parser Grayscale  (Read 421 times)

0 Members and 1 Guest are viewing this topic.

#### Nathonion

• LV1 Newcomer (Next: 20)
• Posts: 18
• Rating: +0/-0
##### Axe Parser Grayscale
« on: January 01, 2017, 10:36:48 pm »
So I want to make a game in grayscale. I found a tutorial for it: https://www.omnimaga.org/axe-language/axe-greyscale-tutorial/, but when I tried it, it came out as black, light gray with dots in it, and white. I think dark gray came out as light gray (as mentioned before), and light gray came out as black. Could someone please tell me what I'm doing wrong?

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2284
• Rating: +636/-31
##### Re: Axe Parser Grayscale
« Reply #1 on: January 02, 2017, 12:50:20 am »
Could you upload the program and provide a link, or paste the relevant part?

Making a guess, though, the second issue you described could be a combination of two individual issues: drawing the two parts of each sprite to the wrong (inverted) buffers, and calling DispGraphr (meant for 3-level grayscale) instead of DispGraphrr (meant for 4-level grayscale).

As for the first issue, if the "dots" aren't horrendously prominent, then that's probably just a side effect of updating the screen out of sync with its refresh rate. The closer it is to about 60Hz, which is very roughly the refresh rate of the calculator screen, generally the better the grayscale looks. You can achieve (nearly) perfect grayscale with GrayLib, but that may be overly complex if you're still just becoming familiar with the language.

#### Nathonion

• LV1 Newcomer (Next: 20)
• Posts: 18
• Rating: +0/-0
##### Re: Axe Parser Grayscale
« Reply #2 on: January 02, 2017, 04:06:45 pm »
Here's the source code for it:
:
Code: [Select]
.TEST::[FFFFFFFF00000000]→Pic1:[F0F0F0F0F0F0F0F0]→Pic2::Repeat getKey(15):Pt-On(0,0,Pic1)r:Pt-On(0,0,Pic2):DispGraphrr:ClrDraw:ClrDrawr:End
It was just meant to be a test to see how it worked. It was just suppose to draw a black square, a dark gray square, and a light gray square. The funny thing is, I got it to work a long time ago, but I forgot how I did it and the code got deleted.

As for GrayLib, I think I'll check it out.

#### E37

• Posts: 217
• Rating: +11/-0
• I own two game consoles- a ti- 83 and a ti- 84!
##### Re: Axe Parser Grayscale
« Reply #3 on: January 03, 2017, 01:48:01 pm »
Here's the source code for it:
:
Code: [Select]
.TEST::[FFFFFFFF00000000]→Pic1:[F0F0F0F0F0F0F0F0]→Pic2::Repeat getKey(15):Pt-On(0,0,Pic1)r:Pt-On(0,0,Pic2):DispGraphrr:ClrDraw:ClrDrawr:End
It was just meant to be a test to see how it worked. It was just suppose to draw a black square, a dark gray square, and a light gray square. The funny thing is, I got it to work a long time ago, but I forgot how I did it and the code got deleted.

As for GrayLib, I think I'll check it out.
I switched pic1 and pic2 and it worked fine for me.
You can replace DispGraphrr:ClrDrawr:ClrDraw with :DispGraphClrDrawrr
ClrDrawrr also works
« Last Edit: January 03, 2017, 02:00:02 pm by E37 »
Good things come in bags marked "SWAG"

#### Nathonion

• LV1 Newcomer (Next: 20)
• Posts: 18
• Rating: +0/-0
##### Re: Axe Parser Grayscale
« Reply #4 on: January 03, 2017, 02:58:25 pm »
Quote
I switched pic1 and pic2 and it worked fine for me.
You can replace DispGraphrr:ClrDrawr:ClrDraw with :DispGraphClrDrawrr
Thanks for the advice E37! That fixed the colors in the wrong places. However, I noticed that the dark gray wasn't well defined from the black, so I did some screwing around and found that if you do :DispGraphClrDrawrr after pic1 and after pic2, It's perfect! Problem solved. I'm sure to implement this into some game down the line. Thanks for the help!

#### E37

• Posts: 217
• Rating: +11/-0
• I own two game consoles- a ti- 83 and a ti- 84!
##### Re: Axe Parser Grayscale
« Reply #5 on: January 03, 2017, 03:22:13 pm »
Quote
I switched pic1 and pic2 and it worked fine for me.
You can replace DispGraphrr:ClrDrawr:ClrDraw with :DispGraphClrDrawrr
Thanks for the advice E37! That fixed the colors in the wrong places. However, I noticed that the dark gray wasn't well defined from the black, so I did some screwing around and found that if you do :DispGraphClrDrawrr after pic1 and after pic2, It's perfect! Problem solved. I'm sure to implement this into some game down the line. Thanks for the help!
I don't know why that fixed the grey problem. It should look exactly the same. (are you calling it multiple times in the loop?) Try adjusting your contrast, that should make the dark grey more distinct. If you didn't already know, you can do that with the Shade(EXP) command. Shade(Shade()) will return the contrast to what it was before the program started.
If you haven't already tried it, interrupts work very well with greyscale.
Good things come in bags marked "SWAG"

#### Nathonion

• LV1 Newcomer (Next: 20)
• Posts: 18
• Rating: +0/-0
##### Re: Axe Parser Grayscale
« Reply #6 on: January 03, 2017, 04:45:00 pm »
Do you have a suggestion for a shade value I could use? I tried using it, and it made my screen blank.

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2284
• Rating: +636/-31
##### Re: Axe Parser Grayscale
« Reply #7 on: January 03, 2017, 05:34:54 pm »
The appearance of different contrast (shade) values varies from calculator to calculator. There's no fixed good number. Many programs/games just rely on the user to set a good contrast value beforehand in the OS.

Some may also implement a tuner in their program that allows the user to adjust the contrast for their program, distinct from the OS. GrayLib provides such functionality with the GTune() function. If you're going to use this part of GrayLib, though, you should probably consider just using the whole thing.

#### Nathonion

• LV1 Newcomer (Next: 20)
• Posts: 18
• Rating: +0/-0
##### Re: Axe Parser Grayscale
« Reply #8 on: January 03, 2017, 07:16:47 pm »
The appearance of different contrast (shade) values varies from calculator to calculator. There's no fixed good number. Many programs/games just rely on the user to set a good contrast value beforehand in the OS.

Some may also implement a tuner in their program that allows the user to adjust the contrast for their program, distinct from the OS. GrayLib provides such functionality with the GTune() function. If you're going to use this part of GrayLib, though, you should probably consider just using the whole thing.
I'm having too much trouble understanding GrayLib, so I think I'll just stick with doing it manually. Thanks anyway! Also, thank you for the help overall! You've been a lot of help!

EDIT:
While I'm talking to Runner112, I might as well ask, whatever happened to that program you were making that upscaled a sprite, rotated it, then downscaled it again? Did you finish it? Because it'd be really helpful for this one game I want to make. I couldn't find it when I was reading the forum you talked about it on.
« Last Edit: January 03, 2017, 08:07:07 pm by Nathonion »

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2284
• Rating: +636/-31
##### Re: Axe Parser Grayscale
« Reply #9 on: January 04, 2017, 12:42:41 pm »
While I'm talking to Runner112, I might as well ask, whatever happened to that program you were making that upscaled a sprite, rotated it, then downscaled it again? Did you finish it? Because it'd be really helpful for this one game I want to make. I couldn't find it when I was reading the forum you talked about it on.

I vaguely remember trying something like that, but I don't believe it panned out. If you're looking to create rotated versions of sprites, I would recommend doing so ahead of time on a computer with a tool like RotSprite.

EDIT: For those wondering, I believe I found the thread in question where my failed attempt lives: [AC] rotating sprites.
« Last Edit: January 04, 2017, 12:48:20 pm by Runer112 »

#### Nathonion

• LV1 Newcomer (Next: 20)
• Posts: 18
• Rating: +0/-0
##### Re: Axe Parser Grayscale
« Reply #10 on: January 04, 2017, 03:07:31 pm »
The reason I ask is that I want to make a top-down shooter game, where if you press left and right, the player rotates. I have two options: one, use a LOT of sprites, and two, use math to draw it in any direction. In the first option, it takes up a lot of memory but I don't have to do much math, and in the second option it uses a lot of math that I'm not good at, but it would take less space, and generally be cleaner. (This is why I made that other subject, for rotating points around an axis) Which do you think would work better? Or maybe I should make a new subject primarily about this.

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2284
• Rating: +636/-31
##### Re: Axe Parser Grayscale
« Reply #11 on: January 04, 2017, 05:42:12 pm »
Very small, pixel art images generally don't look good when geometrically transformed, which includes rotation (by a non-right angle). I would recommend using a tool like RotSprite to generate rotated sprites at even intervals up to 90 degrees and touch them up by hand, and then these can be rotated by right angles in the program using the rotC() and rotCC commands to fill out the three missing quadrants of rotation from the one you have.

#### Nathonion

• LV1 Newcomer (Next: 20)
• Posts: 18
• Rating: +0/-0
##### Re: Axe Parser Grayscale
« Reply #12 on: January 04, 2017, 06:30:55 pm »
Ok, well then I'll go with the first option. Thanks for the advice! Though it is a shame that I won't use vector rotation, as a game engine like that would be helpful for other people's games. Maybe I'll figure that out making it look good to rotate a sprite when I know more math in the future. Either way, I'm exited to finish this game, and really appreciate the help!