Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: willrandship on June 04, 2010, 02:44:55 pm
-
I've been trying to wrap my head around it, but the documentation doesn't mention much. I can do 3-level fine, manually, but do dispgraphr and dispgraphrr work? Cross-hatching patterns, Evolving backgrounds? I'm so confused!
Any help on this?
-
That's the technical details. You only need to concern yourself with how you use it.
For greyscale, both the buffer and back-buffer contain data used for drawing to the screen.
For 3-level:
00 - white
01 - grey
1x - black
For 4-level:
00 - white
01 - light grey
10 - dark grey
11 - black
where the first bit is what's present in the buffer and the second for what's in the back-buffer.
Cross-hatching and evolving backgrounds refer to the techniques to reduce flicker.
-
Aaah, so One sprite gets written to the backbuffer, one to front?
That makes a little more sense.
-
yeah, where each sprite contains part of the data, as shown above.
-
The method Axe uses for grayscale is nice because it makes it much easier to create sprites. Making xLIB/Celtic III grayscale sprites is a major PITA because you need to draw each interlaced frames manually or using an app by Nitacku x.x
-
Manual interlacing sounds awful and editing them sounds even worse...
Thankfully, Axe does this automatically. :)
-
it is. Just a tile with the first two rows of 8 pixels black, the next two dark gray, the next two light gray and the rest white took 5 minutes to draw x.x. It's trial and error. Now imagine with tree sprites, for example. Nitacku program helps a lot for that. It does the job for you. THe only issue is that sprites takes more space than in ASM since it uses 3 or 4 layers instead of 2
-
So, now Im having another issue.
When I try 4-level grey I see a checkerboard-ish pattern. It happens on my nspire and my sis's 84+.
Here's the code:
.GREY
DiagnosticOff
SetUpEditor
ClrDraw
ClrDrawr
[FFFFFF000000FFFF]->Pic1
[FFFFFFFFFFFF0000]->Pic2
0->G
For(G,1,500)
Pt-Off(0,0,Pic2)r
Pt-Off(0,0,Pic1)
dispGraphrr
end
I'm expecting:
Black Bar
Light Grey Bar
Dark Grey Bar
and I get them, but there is a distinct checkerboarding that doesn't occur when I do 3-level. Any help here?
-
move the pt-offs before the loop, that should fix it
-
Also, the 4-level grayscale routine itself was kind of slow. I have changed that now for the next update and also the 3 level routine so they are much faster and better looking than before. I even managed to get 3 color gameboy gray (completely flickerless) with more than a few things happening at once.
-
wow nice :D
Will they still require 6 MHz mode when ran?
-
Absolutely. Also, the 4 level is more convenient since you no longer use the "Setup" command, it is automatically initialized if it detects it has not yet been initialized just like the 3 level.
-
Oooh nice, seems better this way, because I forsee people forgetting to add the setup command in the future x.x
-
Well, I put the for( after the pt-offs, but I'm still getting the checkerboarding. I also tried pt-on instead, but it looks exactly the same. It does flicker less though, so it seems it's running faster.
If it helps, here's the source file.
-
the only way to reduce the checkerboard effect is to maybe add a Pause command after the grayscale or add more Dispgraphrr after the one you got to change the speed at which the grayscale is updated. Pause 9 through Pause 12 usually works. Keep in mind this can slow down your game a bit, though.
-
So, It's caused by the screen updating too fast? Wow. I'd assume that, if that's true, the time for the pause probably decreases. Is that right?
-
4-level grayscale? I still don't even get 3-level. ;D
I've tried something like this:
ClrDraw
ClrDrawr
DrawInvr
Repeat getKey
DispGraphr
End
It doesn't really produce a gray. The screen just seems to be clear. Is this also because it's updating too fast?
Also, should I use Repeat getKey or Repeat getKey(0) in this situation? Does it matter?
Sorry for taking advantage of your thread, willrandship.
-
did you get that to compile? i think you meant clrdraw and clrdraw^r, not clrhome. also, it does work, but since the whole screen is being drawn gray, you perceive it as if the contrast had been changed darker. try this:
.GRAY
ClrHome
ClrDraw
ClrDraw^R //clear buffers
[FFFFFFFFFFFFFFFF->Pic1 //16 F's. a black square. which we will make.. gray (:
0->X->Y // coordinates
Repeat getKey(15)
Pt-Change(X,Y,Pic1 // draw the black square
Pt-Change(X+8,Y,Pic1)^r // draw a black square on the back buffer 8 pixels to the right
DispGraph^r // draw buffer (with black square) and draw the square on the back buffer with a checkerboard pattern
Pt-Change(X,Y,Pic1 // to create grayscale
Pt-Change(X+8,Y,Pic1)^r
X+getKey(3)-getKey(2)->X
Y+getKey(1)-getKey(4)->Y // Movement code
End
it just makes a rectangle, one half of it is black and the other half gray so you can see the difference. and, you can move it.
-
did you get that to compile? i think you meant clrdraw and clrdraw^r, not clrhome.
Whoops, typo.
And that program is a perfect example for me. Thanks.
Except for one thing: I still can't understand why the second set of Pt-Change(s is needed. I tried it without them, and it didn't work, but I can't figure out how.
-
basically the second set of pt-change( 's turn off the sprites so there's no left over residue from movement. i'll try to show you visually.. pardon me if this fails spectacularly. i'm just going to do this in black/white so i can use paint to show you.
1 is a black pixel. 0 is a white pixel. pretend the screen is a grid 3x3 pixels
010
111
010
for example, this would be a cross.
pretend your sprite is:
11
11
or a black rectangle. now, let's jump to the code.
after the first two pt-change('s, your little black rectangle is on the buffer. then it's displayed:
110
110
000
now look what happens without the next two pt-change's. the movement code comes. let's say the user moved the black rectangle one to the right.
101
101
000
what just happened? think about it.
what should've happen was this:
011
011
000
however, since the buffer already has this painted onto it:
110
110
000
and it's inverting the pixels at the new position:
1|10|
1|10|
000
you get...
101
101
000
with the two pt-change's after the dispgraph, it prevents this from happening since the buffer doesn't have any sprite residue left over. hopefully this made sense. and sorry for the long post i tried to be as thorough as possible
-
Well I think it is actually erasing the path that would be left behind (or turning those pixels off so it can be done again). I don't know though. I haven't tested that yet.
Edit: Ninja'd :P
But I think it is kind of like in TI-BASIC when you are doing a basic sprite moving routine on the homescreen and you move the character over and you have a left over character in the path. So you use the "_" (space) token to erase that. Hope that makes sense.
-
Oh, I see. Thanks!
-
yeah it's kind of hard to understand. i don't even want to start to understand what would happen without the pt-change's in my grayscale example. it works, that's all i need to know lol. it's one of those situations where a computer does exactly what you tell it to do, and the only way to understand it would be to go step by step through as if you were a computer :P
-
@nemo
Was my explanation correct?
-
yes, it is. except unlike using the space character in basic, which updates the screen automatically, in axe you have to manually turn off the sprite on the buffer after displaying the buffer... if that makes sense. but yes, you're correct.
-
Ok, ya. Couldn't you technically use a blank ([0000000000000000]) sprite to erase it on the buffer? Or not while doing grayscale?
-
yes, but a sprite is 8x8, right? so if you use a blank 8x8 sprite it'll also erase anything close to the sprite on the buffer. pt-change ONLY changes the black pixels of the sprite to white, which makes it perfect to use. also, if you wanted to, you could use pt-off, which would do the same thing. pt-off clears the 8x8 area.
-
yes, but a sprite is 8x8, right? so if you use a blank 8x8 sprite it'll also erase anything close to the sprite on the buffer. pt-change ONLY changes the black pixels of the sprite to white, which makes it perfect to use. also, if you wanted to, you could use pt-off, which would do the same thing. pt-off clears the 8x8 area.
Actually, pt-off is Replace logic, where the 8x8 sprite replaces whatever is under it.
-
Oh, so you're talking about like when you would have a map underneath the sprite?
-
Drawing Sprite A...
| Over White | Over Black | Over Sprite B |
| Pt-On | A | Black | A OR B |
| Pt-Change | A | A Invert | A XOR B |
| Pt-Off | A | A | A |
Also, xoring twice is the same as removing since (A xor B) xor B = A
-
Drawing Sprite A...
| Over White | Over Black | Over Sprite B |
| Pt-On | A | Black | A OR B |
| Pt-Change | A | A Invert | A XOR B |
| Pt-Off | A | A | A |
Also, xoring twice is the same as removing since (A xor B) xor B = A
So Pt-Off is the same as clearing an 8x8 square first, then drawing the sprite?
-
yes, that is right exactly. If you want more control over what is cleared, use masking.
-
yep, it erases a 8x8 square then draws a sprite.
I wonder if it's slower than Pt-On? I mean, for example, would ClrDraw then Pt-On('ing 96 sprites be faster than Pt-Off('ing 96 sprites? (assuming they need to be displayed every frame)
-
yep, it erases a 8x8 square then draws a sprite.
I wonder if it's slower than Pt-On? I mean, for example, would ClrDraw then Pt-On('ing 96 sprites be faster than Pt-Off('ing 96 sprites? (assuming they need to be displayed every frame)
I think if the sprite is aligned, Pt-Off would be faster. If unaligned, Pt-On would be faster.
-
I would think it would be slower, for while ClrDraw is just a single event, it happens for each Pt-Off, with the added fun of sprite drawing. I'd test it to make sure though. (Use an 84+(SE) and a BASIC program enveloping it)