[Featured][Beta] API - Why hasn't this been done yet?!

benryves · **Posted:** Mon 23 Jan, 2006 10:41 am

Timendus; why use $FF as a hard return? We already have \n, and it seems silly to have to remap our assembler to substitute $FF for \n..?

Timendus · **Posted:** Mon 23 Jan, 2006 2:12 pm

Two very good questions indeed

tr1p1ea wrote:

What happens if you need $FF in your matrix? Perhaps you could have <width>,<height> at the start?

Good idea, I'll change it to that!

benryves wrote:

Timendus; why use $FF as a hard return? We already have \n, and it seems silly to have to remap our assembler to substitute $FF for \n..?

I tried using \n, but Brass wouldn't do ld a,'\n' and I was too lazy to figure out what value you used for it. Also, how would TASM handle it? Would that compile \n to the same value?

benryves · **Posted:** Mon 23 Jan, 2006 2:14 pm

Timendus wrote:

benryves wrote:

Timendus; why use $FF as a hard return? We already have \n, and it seems silly to have to remap our assembler to substitute $FF for \n..?

I tried using \n, but Brass wouldn't do ld a,'\n' and I was too lazy to figure out what value you used for it. Also, how would TASM handle it? Would that compile \n to the same value?

That's a bug in Brass. Whoops. In all cases, it should assemble to $0A. I'll look into that, well spotted.

EDIT: Yep, you're right. .db '\n' doesn't work, but .db "\n" does (but "..." only works for .db-esque directives, and is a special extension of the expression parser). I've noted it as a required fix.

Even the TIOS uses the character $0A as a newline; if you display it it draws a ":" then moves the cursor down a row.

Timendus · **Posted:** Mon 23 Jan, 2006 2:32 pm

benryves wrote:

Even the TIOS uses the character $0A as a newline; if you display it it draws a ":" then moves the cursor down a row.

Really? That's interesting. I'll take a look at it, wait for the bugfix, and change $FF to \n

By the way, I use $FE as a soft return. They can't be the same value. Any good suggestions on what value I should use for that? Not that it really matters much

benryves · **Posted:** Mon 23 Jan, 2006 3:31 pm

\n (Line Feed) doesn't mean "return" anyway, it just means "move the cursor down one line". To move it back to column 1 as well, you need \r (Carriage Return) - which is why on Windows you should use CRLF (\r\n), not just \n...

I'm not entirely sure what a "soft return" versus a "hard return" is..?

Timendus · **Posted:** Mon 23 Jan, 2006 4:01 pm

So, does \r also do something on a calc? Can TASM/Brass compile that to something useful too?

I use two types of returns in my routines, because there's a difference between a newline that a user wishes to have in a string ($FF or the future \n) and newlines that are inserted by the word wrap routine before displaying ($FE). The wrap routine doesn't copy the string, because that would require some safe ram that I don't want to spoil on this. So it changes the given string and adds "soft returns". The next time the wrap routine is called those soft returns are removed first, and then added again (possibly at different locations). If I used the same byte for both hard and soft returns, that step would remove all newlines.

benryves · **Posted:** Mon 23 Jan, 2006 4:18 pm

http://home.comcast.net/~tasm/tasmman.htm -- TASM supports \r, as should Brass (Brass supports all of those escape sequences apart from \000, ignoring the aforementioned bug that '\n' no longer works).

Timendus · **Posted:** Tue 24 Jan, 2006 2:41 pm

I added about 20 new routines to the API, including some new keyboard routines, draw.square and draw.horizLine (though these still have a bug), string.makeWrap and most of the GUI routines. I didn't do this because they are finished, or because I wanted to show them to anyone, but because I couldn't keep track of them on my harddrive in different files with different notations. So I organized them in the website.

If you find any bugs in the API as a whole, please let me know as soon as possible (the rest of the API shouldn't suffer under my tests), if you find bugs in the new routines I'm probably working on it, but let me know anyway

The API currently has 93 routines and a little under 8000 lines of code in an include file of 144kb

Timendus · **Posted:** Mon 24 Jul, 2006 11:13 pm

Small update:

I made a new stable snapshot of the API (now with 66 routines) and added two nifty things to the Latenite Tools package. The first being a project template that makes it even easier to get started with the API and the second being an XML file for the MC AutoUpdater. If I'm not mistaken that makes the API the first project to actually use that thing

Liazon · **Joined:** Thu 27 Oct, 2005 8:28 pm **Posts:** 962

cool. So is the API more like a compatible include with Latenite now?

Timendus · **Posted:** Tue 25 Jul, 2006 12:08 am

In a way, yes

But it's probably the most complex and the largest include the Ti scene has ever seen, and you don't NEED Latenite to use it. It's just that I prefer to develop with/for Latenite because it finally gives us a stable, dependable compile environment.

kv83 · **Posted:** Tue 25 Jul, 2006 7:59 am

Quote:

If I'm not mistaken that makes the API the first project to actually use that thing

Yeah, you've beaten me apparently. But my next release will use it too

Timendus · **Posted:** Tue 25 Jul, 2006 11:00 am

God damn spambots are filling up my idea box

I guess I'll filter messages with [ib-tags] out...

Edit: There, that should keep them out for a while...

Liazon · **Joined:** Thu 27 Oct, 2005 8:28 pm **Posts:** 962

For some reason when I originally tried to use it by itself, and then w/ Latenite, it generated a lot of errors. I hope this succeeds.

Timendus · **Posted:** Tue 25 Jul, 2006 2:53 pm

Then you probably didn't include it properly

The template should fix that for you though, because the include statements are already in it.

MaxCoderz

[Featured][Beta] API - Why hasn't this been done yet?!

Who is online