MaxCoderz

This project is now featured. Congrats Tim.

Congratulations Timendus! Good stuff on making the featured section .

Cool, thanks Vince

I have a question for you all. What should be added to the API before I upload a stable version with some demos to Ticalc.org? What functionality would blow people's socks off in terms of coolness?

You should take a game and a utility of meaningful sizes and recreate them using the API for nearly everything other than main logic. This would also give you an idea what might be missing.

You've got a point, but that would be a lot of work It almost sounds like a new project to recreate a game or a program, and I can't really afford to work on this for more than a few hours a week... Also, if I recreate something that already exists, I fear that people will compare it's filesize rather than the complexity and maintainability of it's source. And I think the API could lose that battle...

Anyway, I have a few more ideas of things that I want to implement, but I have to finish/polish the current routines and the GUI stuff first. It would be nice if someone would pick up the idea of open development and optimize or improve my routines

But anyway, after I'm done polishing routines, and when I've added the GUI stuff, what should get priority so this can be released on Ticalc.org? The link port routines? Other data structures (I've been thinking about some kind of pointerlist that you can index, sort, etc)? Some routines to make logic easier? File/String variable reading/writing (even though I said I wouldn't be coding that myself)?

Do you have (de)compression already?

Nope, good idea. But at the moment I have other things to worry about.

Edit: I'm going to follow CoBB's advice to test and expand the GUI part, and add matrix routines. I'll leave it up to you to guess what I'll be making

I don't know if this has been commented on before... but the API makes it _extremely_ easy for those inexperienced at assembly (like me) to write their own assembly libs for use in Basic programs, because of the read and write user var routines. I realize of course that this is a disgusting bastardization of assembly, but in my opinion what counts is writing better programs, not how difficult it was to write them.

well, he did take the best of the best routines of each kind.

dysfunction wrote:I realize of course that this is a disgusting bastardization of assembly, but in my opinion what counts is writing better programs, not how difficult it was to write them.

I agree There's nothing disgusting about making good programs, and everyone should be able to do just that in their own preferred way. In fact, I wrote those var.write and var.read routines a while ago to do just that, to easily make asm libs for other people's basic programs

I wrote a few nice matrix routines (matrix.get and matrix.store are done, working on a really fancy matrix.toString) and the gui stuff is constantly improving. I rewrote the word wrap routine for about the fifth time, this time as a standalone routine that adds "soft returns" to a string, that can be used by the gui print string routine. It's pretty cool, because you can now do something like this:


$FF is a hard return, and the wrapping routine that gets invoked by gui.textField inserts the proper soft returns. This seems to be the same thing as what the number guess demo does, but there are important differences. The old routine would display every character and compare the new cursor position, removing the character if it didn't fit on the line. The new routine calculates the width of a line independantly without having to display it, so nothing that doesn't fit gets erased, and the string can theoretically be used with different outputting routines.

Also, textfields use a pointer to a string, and "live" wrapping, so I can now make a textfield with changing content and still use one routine to rebuild the screen. You couldn't see in the screenshot, because I didn't show it, but in the number guess demo the text in the left panel would be erased when you picked "About" and closed the popup. Closing the popup would redraw the screen, as you could see in the code, with an empty left panel.

I tried making a pt(x,y) = 256*x+y macro, but Brass wouldn't parse a macro within a macro; something like putSprite(pt(5,10)) doesn't compile. I don't know what TASM does, so if that turns out to work I'll ask Ben to make a few changes to Brass. But TASM keeps crashing or giving 1263 errors whenever I try to compile something unless I manually invoke it from a command line

The other option would be to define my macro's like this:
#define putSprite(x,y) ld hl,pt(x,y) \ call putsprite
But I'd rather have fewer than more arguments because it gets messy, and besides it wouldn't work with the load() macro.

Looks nice timendus, once I get finished with a few of my projects I will give it a try.

dysfunction wrote:I don't know if this has been commented on before... but the API makes it _extremely_ easy for those inexperienced at assembly (like me) to write their own assembly libs for use in Basic programs, because of the read and write user var routines. I realize of course that this is a disgusting bastardization of assembly, but in my opinion what counts is writing better programs, not how difficult it was to write them.

To a greater extent, it's a disgusting bastardization of Basic. Oh well, as long as there's a reasonably good chance I can still write equally good programs without libs, I don't mind.

Wow, a routine like matrix.toString would be really useful.

I suppose I should add that as always I mean matrix in the sense of the data structure, not the Ti-OS variable

I have defined matrices as follows:

.db <width n>
.db <data1>,<data2>,...,<datan>
.db ...
.db <terminator>

With terminator being $FF or 255. So this would be a valid 4x2 matrix:

.db 4
.db 1,2,3,4
.db 5,6,7,8
.db 255

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