Show Posts

226

TI Z80 / Re: [AXE LIBRARY] GrayLib: (nearly) perfect grayscale

« on: April 20, 2015, 07:13:11 am »

I have several things:
1) Can you replace all the lower case letters with uppercase ones in the commented version? they take up a lot of MEM. (lowercase letters are two bytes right?)
2)If i don't know weather my user is using a ti83 or a ti84 then how do i compile? Should i just fallback upon the ti83 method? Is there a way for greylib, when run, to automatically choose the correct setting?
3) Can i strip out every thing i don't need to just leave the timer/inturupt stuff.
4)Is there any advantage of using the Crystal timer (84 method) verses just using interrupts?
5)Doest using the Crystal timer (84 method) mess with the cpu speed?
AND LAST BUT NOT LEAST:
Your library can render text with all shades of back/fore ground. And yet when i asked about the ti84 and the location of the sprite sheets, you "At least, I hope that information's correct. I haven't tried any of this, but this would be my best guess as to doing it correctly." (https://www.omnimaga.org/general-calculator-help/where-does-ti-(84)-os-store-the-sprite-sheets-for-chars/msg399940/#msg399940). So how exactly do you render text? ("performs magic" is not a good enoufe explanation for me

)

227

Axe / Re: Why does axe greyscale look so bad at very high speeds?

« on: April 20, 2015, 06:50:59 am »

I have looked into greylib, and i actually have two questions/concerns about it

EDIT: i have posted a reply on the greylib page, pls read.

228

Axe / Re: Why does axe greyscale look so bad at very high speeds?

« on: April 18, 2015, 06:12:19 pm »

O well ok then. So pretty much it's just "screen tear"

229

Axe / Re: Why does axe greyscale look so bad at very high speeds?

« on: April 18, 2015, 06:07:09 pm »

Yes I know that, but I want to know why this is happening in the first place. I always thought that the faster the buffers are displayed, the "greyer" the greyscale is.

230

Axe / Why does axe greyscale look so bad at very high speeds?

« on: April 18, 2015, 05:50:08 pm »

So this has been bugging me fore some time so I desised to ask about it. As I've mentioned in title, at very fast speeds greyscale looks like greyscale would look at very slow speeds. Can someone explain what couses this and how axe implements greyscale in the first place? Also why can't you just render the 1st and 2nd buffer in rapid succession, instead of doing this weird diagonal line thing axe does now?

231

Axe / Re: Help with greyscale tile engine?

« on: April 18, 2015, 08:20:34 am »

@pimathbrainiac I cant do that (now) because when a key is pressed i have to shift the buffers, and redraw part of a screen. $:-\$
@Sorunome Ive started using L1 and L4-415 as the second pair of buffers (if the number are not correct, just ignore 'couse i am writing this from memory). The biggest "un-optimized" problem i thought of is that ile have to do:

Code: [Select]

Buff(768)->str1B1 
Buff(768)->str1B2

,but my fear proved irrational.

232

Axe / Re: Help with greyscale tile engine?

« on: April 16, 2015, 06:31:54 am »

Well, ok, then. I have that about using anther pair of buffers, but to me that seemed unoptimized(is unoptimized not in the English language?(i get a red line )). If it is the standard and best way, then ok thanks.

233

Axe / Help with greyscale tile engine?

« on: April 09, 2015, 11:34:33 am »

So i was working in a grayscale tile engine, and i finished to the point where it works. Having made tiloe enginges in java before it was not even that hard. The problem is it is just to slow. So i have the code here:

Code: [Select]

Repeat getKey(41)
If getKey(1)
Y++
End
If getKey(2)
x--
End
if getkey(3)
x++
End
if getkey(4)
y--
End
RENDER()
DispGraph^RR
End
Return
Lbl Render
cLrDraw^RR
0->G 
For(E,0,H
for(D,0,w
Pt-Mask(D-x,E-y.{G+str1MAP}*16+Pic1TILES 
D+7->D
G++
End
E+7->E
End
Return

Now as ive said before, it works, but it is to slow for a platformer i had in mind, and the gray scale also looks bad. Is there any way i can speed it up? I have consired using Verticle and Horisontal to shift the buffer left/right/up/down when the player moves, but there is the problem that another entity could move while the player stands still. Any suggestions?

234

The Axe Parser Project / Re: Bug Reports

« on: March 13, 2015, 10:27:35 pm »

Quote from: Runer112 on March 13, 2015, 10:18:04 pm

I looked at the source of that command and confirmed that it performs no port modulation if the second argument is less than the first. You might just be picking up on noise.

Does not sound like just random noise, unless the OS sends stuff out of the port automatically when you press the keys 2nd - sto (going down) which just happen to be the keys i happen to be using for my calc-a-phon

But lie look into it. (tomorrow)

PS I am using axe v1.2.2

235

The Axe Parser Project / Re: Bug Reports

« on: March 13, 2015, 10:00:30 pm »

This isn't really a bug, and I would personally want a you to do nothing about it, but you can actually play a sound using the freq() command with a time of zero. So I can do:

Code: [Select]

freq(260,0)

and it will whatever note has the wavelength of 260. The catch is that it plays it releay softly, and I have to use my guitar amp to hear it. So mabey change the documentacions to say "time should be greater then wavelength or else the sound will have to be amplified in order to hear it"

236

Axe / Re: Routines

« on: March 11, 2015, 04:41:47 pm »

I made a Flood Fill algorithm here: https://www.omnimaga.org/axe-language/my-axe-flood-fill-algorithm/msg399980/#msg399980 .

237

Axe / My Axe flood fill algorithm. [tutorial WIP]

« on: March 10, 2015, 10:03:06 pm »

This was originally intended as a tutorial, but it never worked out like a tutorial so lie just post the code and comment on what it does.

So i was bored in math class and decided to implement a flood fill algorithm. It was actually much easier then i though
This is probably not the most efficient flood fill out there, as i thought of it myself . So yea: (ps the algorithm requires a second 768 (786?) byte buffer.) (pps i thought of the algorithm my self but it may be pretty standard $:-\$ )
It seems pretty fast to me, but i don't know how fast it is compared to others. Ile try to post pics soon. So here is the code:

Code: [Select]

.FloodFill
.PROGRAM START, CALLS FLOOD FILL ON CORDS 48,32
DiagnosticOff
Full
ClrDraw^rr
FLOODFILL(48,32)
DispGraph
Text(0,0,"Over"
Repeat getKey
End
Return
Lbl FLOODFILL
r1->X
r2->Y
0->D+1->Z
Pxl-On(X,Y)
Pxl-On(X,Y)^r
Repeat getKey(1)
If HIT(Z)
TURN()->Z
!If Z
JUMP()
!If Z
Return
End 
End
End
MOVEX()->X
MOVEY()->Y
D+1^1024-D
!If D
DispGraph
End
End
Return
Lbl JUMP
For(F,0,95)
For(G,0,63)
If pal-Test(F,G)^r
F->X
G->Y
TURN()->Z
if Z
Return
End
End
End
End
0->Z
Return
Lbl TURN
For(T,1,4
!If HIT(T)
T
Return
End
End
0
Return
Lbl HIW
MOVEX(r1)->I
MOVEY(r1)->J
If pxl-Test(I,J)??I<0??I>95??J<0??J>63
1
Return
End
0
Return
Lbl MOVEX
If r1=1
x+1
Return
ElseIf r1=3
X-1
Return
End
x
Return
Lbl MOVEY
if r1=2
Y-1
Return
ElseIf r1=4
Y+1
Return
End
Y
Return