Progress...

[Iambian]

The old "current progress" topic has seriously strayed from what it originally talked about : Progress of the ASM program version of Celtic III. So what I've done is unpinned the previous "Current Progress" and locked it down so that it can no longer be used to discuss the progress of the project, as this topic will serve that purpose... at least until I do the same thing to this.

As everyone might have guessed, the ASM version of Celtic III has been frozen until further notice. I did this because I fully believe that the APP version of Celtic III is far more worth it to develop than an ASM program that can be cumbersome to edit just to include only the functions that you want, among other things.

The FlashAPP version, as of this posting, is at version 3.09o. This version from the previous version fixes quite a few bugs but still doesn't seem to correct the more important ones. You'll just have to try it out for yourself to understand what I mean.

I've also added string manipulation commands found near the bottom of the det() commands, namely one that works a bit like sub() except that it takes a binary string and outputs hex digits of it. The other two commands after that tries to make sense of that by switching between decimal and hexadecimal.

Celtic III version 3.09o : Major changes
- Hook chaining capability was completely removed in favor of faster program execution.
- Added functions. See ReadME.


Celtic III version 3.09o : Known issues
- det(10) UNGROUPFILE has been known to not like groups with mixed variable types.
- det(22) MODECHANGE has not been linked to anything as of yet.
- det(24) LOOKUPINDEX does not strip the trailing newline character.
- det(25) ERRORHANDLE does not work at all. It doesn't seem to cause problems, tho
- identity(1) DBQUERY1 has not been tested yet, but compression shouldn't work yet.
- identity(4) STRINGTILE is not yet fully implemented.
- identity(7) DRAWBOX shares same problem with real(12)
- identity(9) COPYBOX has no code written for it.
- real(1) DrawSprite does not implement sprite clipping correctly for sprites over 64 pixles wide. If it's aligned, it doesn't seem to implement clipping at all.
- real(2) DrawTileMap Does not have bounds correctly coded. Hopefully this'll be fixed soon.
- real(3) RecallPic doesn't like archived entries for an unknown reason. It might be fixed by now.
- real(12) DrawShape does not seem to like to draw lines. It also doesn't seem to like to draw boxes smaller than 8 pixels wide, but your mileage may vary depending on where it's placed.
- Not nSpire compatible due to a single instance of the sll instruction located in the bugged box drawing routine.
- Bad app signature. Might be fixed by version p.

Celtic III version 3.09 o : Fixed
- Documentation (except error codes). Read it.
- det() and identity() now accepts negative numbers as input.

------------------
"Known Bugs" is just a list of all the stuff I remember off the top of my head.

Comments and (educated) criticism welcome.

------------------
For those that don't know what Celtic III, this is quote from the ReadME of revision ®.

[TheStorm]

IT seems like you have some repeat routines in there, why is that, if xlib has a similar fuction just leave it as that don't have duplicates that aren't needed.

[luby]

Hey, what if you really want to find the determinant of a matrix?

[vuurrobin]

if the matrix isn't 1*1 it would just work as if celtic isn't installed.

nice to see a new topic, and a list of things that needs to be done.

[DJ Omnimaga]

[vuurrobin]

I think he is talking about functions like fastcopy/update lcd (det(19) and real(6)) and shift screen (identity(6,.. and real(4,..)

[TheStorm]

I meant the shape and box comands I know one is celtics and one is xlibs but since there are no celtic games that he needs to be backwards compatible with you really don't need the celtic one.

[Iambian]

There are two different box routines in Celtic III because there are some box combinations that xLIB does not allow for. The Celtic III version is supposed to grant its user access to all of them, but come to think about it, I haven't really added anything like that yet, even though I said I would. As far as box routines being different, they aren't really. This time around, it's xLIB's command that calls PicArc's boxdrawing routine. The bugged code is in "_PFN.z80", About 2/3rds to the bottom.

As far as extending box combinations, if I really were to remove that function from identity, should I make it the user's responsibility to come up with those kinds of boxes, or should I just append them to the real(12 such that the old stuff still works but if you try to go above the last shape, you'd be accessing the special ones.

The fastcopy / lcd update commands will stay where they are. If I were to bother taking them out and screwing up the commandlist because of its absence, I'd only be saving literally two bytes. Two bytes is not worth that.

And an answer to a previous question, if you wanted to find the determinant of a matrix, then you'd use the det() token as it is normally intended for. Celtic III is smart enough to know whether or not it's being used legit.

[Iambian]

Not all of my promises have been fulfilled yet for this upcoming release, so I haven't bothered posting any binaries yet. What I am going to post about is the progress I've been making with the project since I last said something.

I've fixed the DBQUERY1 command so that it functions as it is supposed to do under many circumstances. Image compression now works well, though I haven't implemented vertical RLE. Once I do implement it, I'll also post what you can do to convert an old PicArc database to its newer Celtic III PicArc database format. It actually isn't much different, which makes it easy enough to do using just a couple of Celtic III commands.

Somebody will need to test the DrawTilemap command since I looked at the source and the problem seems to have already been addressed. Speaking of drawing, the drawshape command has been fixed with regards to not correctly rendering thin boxes. Along with fixing that routine, the application should now run when used with an nSpire's TI-84 emulation.

Someone will also need to test the recallpic command when the pic files are archived. I haven't been able to reproduce the errors on the emulator.

Also, the STRINGTILE command has been edited to now work exactly like the xLIB's tilemapper, except that you replace the matrix with a string. There's also another mode on that command that lets you specify that your string consists of words, not bytes, so you can have 16-bit tile indexes too. Bacially, anything xLIB's tilemapper can do, this command can do.

With that, I added in two more commands. One to edit a string two bytes at a time instead of just one. The second command lets you perform a bitwise logical operation between two numbers. These numbers are converted to 16-bit numbers and then the operation is carried out in order to maintain simplicity. Example?

[vuurrobin]

nice progress

about the readme:

under the part about checking for instalation inside a program, you may want to include an example code.

[nitacku]

nah, you can check to see if Celtic is installed the same way you would with xLIB
Celtic implements the real(0 command, so all that's needed to test the installation is:

1
real(0
If not(Ans
Then
Disp "Install Celtic"
Return
End

[vuurrobin]

that wont work if the user has xlib installed when you are using celtic.

besides, it is specificly created for it, then why not use it?

[Iambian]

Celtic III has not progressed very much lately, but I can say that some of the bugs that was mentioned has been fixed. My problem is that I haven't been able to sign the application properly so the problem about bad signatures still exists. For this reason, I will not attach the build to this post. Instead, I ask that you send me a PM indicating that you want the most recent build.

In (at most) a few days, you'll receive a PM with an attachment containing only the .8xk file and the readme. If you want the source as well, I will also cram them into the .zip file.

--
If you try to build the application yourself, please know that there's a bunch of dead code in there, since I've declared this release before I finished with the box scrolling routine. I still might not finish it between now and the time someone asks for a copy since I still don't know what I ought to be doing with the code.

[vuurrobin]

any luck signing the app?

[Iambian]

No luck with signing the app. I might just end up having to pass the .hex file to someone else so they can sign it for me, since I can't verify anything I sign.

Apart from that, I've started adding in a function that will return a list of programs given an incomplete name, as opposed to searching for its starting contents. I've also edited the readme file to include a BASIC code example of checking for a Celtic III installation.

Other than that, not much progress has been seen. I'm down to 1.5KB of space, so... start suggesting important stuff, like linking

[Art_of_camelot]

How about a simple on calc help function that describes syntax and usage for celtics function?

[vuurrobin]

that can easily be done in basic and IMO not worth the apps space.


how about linking between 2 calcs :biggrin:

[cjgone]

Wait, is their a function that like converts a string to a matrix of x and y height? thatd be useful for storing large maps and processing them quickly for the tilemap routine.

[vuurrobin]

or you use the string tilemapper so that you don't even need to convert it to a matrix

[sumurai8]

Perhaps you can implement 'OnBlock'. Just to block 'On' from killing your prog... Perhaps you can make something, so you can use 'on' to perform actions in your prog.....

Don't ask me how to do it, but your knowledge of asm is good enough to make a code... perhaps i can post the code or prog of onblock...