EDIT:

Quote from: Runer112 on March 20, 2011, 07:11:10 pm

Code: [Select]

◄


When do you use that?

Pretty much never. But it's a valid character/token. ASCII CFh, token BBEDh.

I think I just spent a long time searching around http://www.fileformat.info/info/unicode/index.htm. I ended up compiling a file with a bunch of useful calculator symbols:

→
˪
L₁
L₂
L₃
L₄
L₅
L₆
r₁
r₂
r₃
r₄
r₅
r₆
Y₁
Y₂
Y₃
Y₄
Y₅
Y₆
Y₇
Y₈
Y₉
Y₀
°
∆List(
≤
≥
≠
·
﹢
□
⁻¹
²
³
√(
³√(
ˣ√
ᴇ
ᵀ
ʳ
►Dec
►Frac
►Char
►DMS
►Tok
θ
α
β
γ
Δ
δ
ε
λ
μ
π
ρ
Σ
Φ
Ω
ṗ
χ
σ
τ
…
∠
⁄
ß
ˣ
ᴛ
◄
↑
↓
×
∫
√
ȳ
⋱


Happybobjr, I think your best bet for storing the names of Pokemon would be to make each name a constant size. As far as I can see, the names of Pokemon in the Generation I games were limited to 10 characters, so you could make each name be 10 bytes long. To display the names, you would have to copy the 10 bytes to another location in RAM where you can add an 11th byte, a zero in case the name was 10 characters long and didn't have a terminating zero already.

Oh, you mean a 3-character static pointer. Yeah, you can use them. And the name of a static pointer contributes nothing to the compiled program size. The only quirk about static pointers is that, when adding a pointer to string data in the form of:
:"String here"→Str___A zero byte is added to the end of the data automatically.

APD only works in situations when the OS is in control, so you can't just insert APD into an assembly program. If the assembly program calls a bcall that waits though, like _getkey or _GetStringInput, APD can activate during that.

Hi. I don't think this has ever been properly addressed, so I would like to formally address the matter of crediting others when it comes to programming works. Although everything that follows is only my opinion and you do not need to agree with it, I would like to state it. Feel free to post responses agreeing or disagreeing with me. The first paragraph will deal with what I would deem to be general etiquette. The second paragraph will be focused on Axe.

When making a project, you may often turn to others for help. Whether it's requesting sprites, using a routine somebody created, or simply letting someone optimize some parts of it, I feel that it is courteous to recognize their help in some form. In some cases, like in the case of minor code changes or optimizations by another person, a simple thank you would suffice for their aid. If you want, you can give them a small credit in the readme for your finished program. Or if you learned some stuff about coding from a help post somebody made, you may want to shoot them a quick thanks for the guidance, but it isn't necessary to cite small amounts general programming help. But I believe that if someone contributed specific help that your game relies on, like sprites or an important routine, it is fitting to cite who contributed that important part of your finished product. No need to put their name in your program's splash screen, or necessarily in the program at all. But a thanks at the bottom of a readme, no matter how small, can mean a lot. It means the efforts this person made to help you were really helpful after all. It means the time they put aside to help, no matter how much, was time spent well and worth spending again to help others.

When it comes to Axe projects, in a lot of cases the programmer will release the Axe source with their finished work. Sometimes he or she will say that their project is an Axe project but will want to keep the source protected, which is completely fine. But what can irk me a bit is seeing programmers produce something with Axe and fail to report is as being an Axe project. On one hand, I find it a little unsettling that it isn't mentioned, possibly as if they want others to think that they wrote it in assembly. But a possible slight deception is not what I find most unsettling. What I find unsettling is that failing to recognize it as an Axe project means failing to recognize perhaps the most important part of your project's existence: Kevin Horowitz. As I stated earlier, I believe it is proper to give credit in a final product to someone who may have provided you with some graphics or some code. But what about Quigibo? He provided every routine your program uses. He provided bug fixes for problems you might have run into. He provided a documentation and command information which likely taught you a lot of the concepts and commands you know. And most importantly, he provided his time. More than a year of it, so your program could exist. And I think the least any one of us can do to repay that is give a few seconds of thanks and recognition in return.


~~~

I can never focus on one project at once and have thus never really finished and published any projects, or the readmes to go along with them. I have never had the chance to give thanks in any published projects. But I have still programmed in Axe and enjoyed it for countless hours. So I would like to be the first to officially say:

Kevin Horowitz, thank you for the work you have done. Your helpfulness and commitment to Axe have known no bounds, and neither do my thanks to you.

Using an optimized assembly routine, I guess I could make a routine for clearing both buffers at once. ClrDraw \ ClrDraw^r would take 34592 cycles by my calculation. The following routine (including the call) would take 25405 cycles, so about 1/3 faster.

p_ClearBothBuffers:
ld hl,plotSScreen
ld de,appBackUpScreen
ld bc,768
xor a
__ClearBothBuffersLoop:
ld (hl),a
ldi
jp pe,__ClearBothBuffersLoop
ret


In connection with this, I've always thought it would be nice if the inData() routine returned 0 instead of the position of the terminator when the byte to search for is 0. As in the example I cited, we currently have to navigate around this problem by tagging +1's onto everything. Unless you have a reason for preferring the way the current routine treats 0 inputs, can this be changed?


And if you want to change it, I'll make things even easier. After a bit of playing around I have come up with a routine that should implement this change. It is the same size as the current routine and about the same speed; the amount of overhead cycles isn't vastly different, and it only takes 4 cycles more per iteration. Anyway, here it is:

p_InData:
.db __InDataEnd-$-1
ex de,hl
xor a
ld h,a
ld l,a
__InDataLoop:
cp c
ret z
ld a,(de)
inc de
inc hl
or a
jr nz,__InDataLoop
ld h,a
ld l,a
ret
__InDataEnd:




EDIT: Also, because I'm sure I'm not the only one wondering about this, I'll go ahead and ask it:

Nested libraries would be nice.

Nested libraries?