Feature Requests

[Iambian]

Well, the error system for the original Celtic III was built on the basis that the user could reassemble the source to provide the needed length of these error codes, but the APP version is slightly different. I don't expect anyone to reassemble that thing to achieve a slightly different output, though I will consider putting that as part of the "options".

Now, the question I want to ask is this: Should I have another version of the error system such that it would actually trip the TI-OS's error system? I mean, the strings used would be far more descriptive but there'd be no graceful error handling if that was the case. Should I put it in there anyway?

I might try to make one of 'em a joke, like

[Harrierfalcon]

No, I think the other way might be a bit cleaner. What happens if we have to try to read from a program to see if it exists? ;)

Admittedly, that error would be a great trick to pull on someone .

[Iambian]

Along with settings, I would try to include a command to let the BASIC program edit Celtic III's settings, so would it be okay to include these TI-OS errors if one were able to switch them on and off at will?

[Harrierfalcon]

What about, instead of doing that, you included an option for that in the Enable/Disable menu?

[Iambian]

Well, I *do* want the BASIC program to be able to toggle these features at-will, especially if dealing with a distribution problem where the user doesn't bother reading the ReadMe to set Celtic III to the appropriate configuration.

I will, however, provide that option on the options menu, whenever I get around to getting that working.

[Iambian]

As something quick, I'd like to say that I might be adding in a few of Codex's functions to the Celtic III APP. For the ASM program version, I'd like to say "just use Codex."

The following will then apply:
1. Adding in screen shifting in any direction. Will also add in by how much the screen should scroll.
2. Some of the more common functions, like enabling/disabling: reverse text, alpha lock, lowercase text.
3. More common features, like turning the LCD off, quick graph display blackout or clear, adjusting the contrast whether by inputting a number or by incrementing/decrementing the preexisting value, retrieving free RAM/ROM, and turning the run indicator on/off
4. Output of rectangles (boxes). Will use custom-built routine so I'll need input as to what kind of boxes I should support.
5. Sprite output. Tell me what would be most convenient for you regarding where your sprite data is and how it should be output onto the graph buffer.

In addition to all that, I'll support a tilemapper. I may need to write down specifications for that, but would the tilemap be okay if it was in a string as opposed to a matrix?

Oh. And... *bump*

[Demon]

Will it be as fast as xLIB or faster even?

Oh, and I "gots" some ideas:

- You could add ERRH - Benjamin Moody's error handler - handler to Celtic so you could run BASIC code in Ans or whatever string you're using for input stuff like that (and it'll handle the errors too by putting the type of error in X like ERRH does).

- If no one has suggested this yet, a function to run ASM progs in hex in whatever input string you're using.

- The Copy-to-RAM routine from xLIB -- [font="Courier"]real(10,x[,y])

[Harrierfalcon]

You do know that, by adding a complex list (such as "{i}") as the last argument of a Circle(, it acts as though the fast circle flag were enabled for that circle, right?

[Demon]

I know... but it's still slow.

Maybe it could have an accuracy setting so you could change the accuracy (and therefore the speed) of drawing the circle? Then if you need nearly instant circles, but don't care so much about how accurate it is, then you could do that.

[Weregoose]

360/ScumSum(binomcdf(S,0→Y
X+Wcos(Ans°→X
Y+Hsin(LY°→Y

Draws an S-sided polygon at (X,Y) with aspect ratio W/H.

S would be your accuracy setting in this case.

This is fastest when used with Stat Plots.

[DarkerLine]

See http://mpl.unitedti.org/?p=13 for another fast circle routine. I believe it's faster because it does not require recalculating the sines and cosines every time you draw a circle (but on the flip side, it requires a setup routine to calculate the sines once). It also uses pixel coordinates which I think is a plus, although other people might see it differently.

[vuurrobin]

I wouldn't include some of the functions you mentioned (yet*). some of the functions like runindicator on/off can easely be used as hex code. I would rather see a hex executer like demon said, than those functions. it would be smaller and people could use functions that were otherwise not included.
you can find some hexcodes here

*: after the other functions are ready and you have some space left, you could consider these functions.


when you are using functions from other librarys, make sure that you eather don't take to much functions or take all the (usefull) functions. it would be annoying if people had to use codex just for 1 function. also remember that some functions are also used in a separated program, like xlib copy program to ram function, which can be replaced by resource and thus doesn't have to be included in celtic3 app.


if you want some more ideas, you could look in some other library topics like the xlib forum on maxcoders.


about the tilemapper, YES make it use strings. IMO strings are way easier to use than matrixes and they are way smaller.

[Demon]

Problem is, it takes longer to change elements in a string then it does in a matrix, so games or programs (PyroMap for example) that dynamically modify tilemaps would run slower.

Maybe you could make two tilemap systems - one that uses strings and one that uses matrices. Then you could en-/disable the ones you want to and recompile.

[Super Speler]

A great String tilemapper/sprite displayer is something that is highly needed by top level basic game makers today. If you were to make this, it would guarantee Celtic III as a standard in Basic Libs. Basically, look at the graphical features in xLib and and make string equivalents of them.

I don't know if this is already planned, but the ability to store line X (or X through Y) only of a program in archive to a temporary program in RAM, this would make level storage much easier (though maybe a little difficult to plan) and save a lot of memory.

It would be incredibly useful (for me at least) to have a faster random list generator (of dim(X)). The current one is way to slow to be useful in games.

Good luck!

[Iambian]

[vuurrobin]

for the string tilemapper, how about a 2 token hex value ("1A" would be 28 (I think)). this way, we can have 256 tiles (I think xlib also allows this many tiles)

for the inputs, you can look at xlibs tilemap function. just make sure you include support for all pics and strings and stuf like update lcd and display method (overwrite, AND, OR, XOR)


also we need a way to check if celtic3 is installed. I'm not sure if that will be possible if you use det(

[Iambian]

For detecting if Celtic III is installed, perhaps I could do something like intercept a 1x1 matrix containing a predetermined value, and if it does not match up with the expected value, then it will be your cue that Celtic III is installed.

On my TI-84 Plus SE, I can do det([[x]]) and it will return whatever x was without any modification. I do not know if this is the command's expected output, but I'd like others to try this. With that being said, what I could do is make it return "i" (imaginary 1 with no real part) so that you'd be able to do something like:

[Zaphod Beeblebrox]

I think that the feature to recall a variable into a string would be VERY useful. Particularly for my current project.

[vuurrobin]

the if not(det([[1 would works good enough, but make sure it only works with a matrix of 1*1 containing a 1


I don't think that 32 tiles is enough, some projects just require more tiles (like with scrolling maps)


yes, if you want the 26th tile, you would use the hex number of 26 (1A)


I don't know what you mean with keeping tiles in a string. do you mean that instead of having the tiles in a pic file, people would translate that in hex and put it in a string?


a pic to string and back would be usefull tho. that way, we can put the strings in a program or appvar. usefull for when you have to send it to somebody else.


I wouldn't support matrices, if somebody wants to use that, they can use xlib for that (together with the celtic program)

[Demon]

It would save RAM if BASIC programs could be directly executed out of archive instead of having to copy them, and also if you could read part of a program directly from archive without having it copied to RAM first. I want to make PyroEdit use Celtic to be able to do this so that I can pack all of PyroEdit's BASIC subroutines into one program and read and execute parts from it without the whole program having to be copied to RAM at all and the user doesn't have to have over forty subroutines installed on their calc (the UNIX philosophy doesn't fare too well on calcs, does it? )