| Author |
Message |
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
 Posted: 23 Mar 2009 05:33:01 pm Post subject: |
|
|
Awesome! I just tried it out, an on top of it working with decimals there's a sizable speed increase over xLIB's real(2 command.
Great work :biggrin: |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
| Posted: 24 Mar 2009 01:10:08 pm Post subject: |
|
|
I was reading the readme...
In the routine like the Omnicalc ExecAsm() why don't see Omnicalc source to do exactly as it does?
In the ungrouping try to see GroupTool source. It is an nifty tool that handles everything (that I know) in groups. May come handy.
Good to see bugs fixed! |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 24 Mar 2009 07:02:22 pm Post subject: |
|
|
Galandros wrote: I was reading the readme...
In the routine like the Omnicalc ExecAsm() why don't see Omnicalc source to do exactly as it does?
In the ungrouping try to see GroupTool source. It is an nifty tool that handles everything (that I know) in groups. May come handy.
Good to see bugs fixed!
The "source" that the two added Omnimcalc functions use are grouped with the xLIB source file, found in _XFN.z80. The source found there makes cross-references to the sprite rendering routine found later in _XFN.z80, and the ExecAsm() command links directly to Celtic III's version of that command in _CFN.z80. The link to it is found in the hook handling source, _HKH.z80.
Also, thanks for mentioning GroupTool. The source... looks almost as unreadable as the old Celtic II code. I'm quite unsure as how this would help me, since Celtic III already supports group handling commands. I may be missing the point of referencing to GroupTool, but please tell me why. Can't fix Celtic III without specifics. |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
| Posted: 25 Mar 2009 10:54:04 am Post subject: |
|
|
Iambian wrote: The "source" that the two added Omnimcalc functions use are grouped with the xLIB source file, found in _XFN.z80. The source found there makes cross-references to the sprite rendering routine found later in _XFN.z80, and the ExecAsm() command links directly to Celtic III's version of that command in _CFN.z80. The link to it is found in the hook handling source, _HKH.z80.
Also, thanks for mentioning GroupTool. The source... looks almost as unreadable as the old Celtic II code. I'm quite unsure as how this would help me, since Celtic III already supports group handling commands. I may be missing the point of referencing to GroupTool, but please tell me why. Can't fix Celtic III without specifics. I could be more explicit...
In the documentation:
"routines that are supported by Omnicalc won't be correctly executed in Celtic III. We'll find out eventually."
You could use Omnicalc code to avoid any code potentially unsupported by CelticIII... But reading again I got your idea. We can skip this.
"| UNGROUPFILE | Fully ungroups files using an experimental routine designed
| | to overcome the OS version @ | > 1.13 limit.Buggy, but
| | should still work for program-type-only group files."
Grouptool maybe could solve this? This is what made me post about GroupTool...
Although rarely get a bug that cannot ungroup all, but not sure what causes... At the time I didn't understand much but from what I remember still does the trick for all kinds of variables (lists, pictures, etc..)
I haven't played much with groups because Tilp doesn't like them and I have my prog menu filled of my BASIC math things...
I will try to understand Hooks and memorize b_calls someday to help CelticIII. I wanted to learn assembly to also do a basic lib but CelticIII achieved my expectations so no need to do myself. Still I can help.
One question which I could discover with trying: do you can still use normally det( and real(?
Getting away: if we hadn't GrouptTool we could make a basic program with CelticIII to manage groups! Yet I hadn't idea of all the CelticIII functions.
ExecHEX.txt could be updated with http://tibasicdev.wikidot.com/hexcodes ? I haven't payed much attention checking in depth. |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 25 Mar 2009 02:16:20 pm Post subject: |
|
|
Quote: One question which I could discover with trying: do you can still use normally det( and real(?
For the identity( and det( commands, you can use them normally. For det(, the usual input is a matrix, and since the first argument of all of Celtic III's det( commands is a real number, the hook routine can differentiate between legitimate arguments and Celtic III stuff. With identity(, it takes a single real number and all of Celtic III's identity( commands are at least two arguments. Unfortunately, real( takes a real argument, and there are xLIB commands that only have one argument, so there's no way to tell.
Quote:
I think those are just examples, so it doesn't have to be comprehensive. |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
| Posted: 25 Mar 2009 04:27:33 pm Post subject: |
|
|
simplethinker wrote: Quote:
I think those are just examples, so it doesn't have to be comprehensive.
Either way it could be updated... |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 25 Mar 2009 06:02:01 pm Post subject: |
|
|
There exists a problem revolving around groups that just can't be fixed. Sometimes, the TI-OS will fail to properly construct the group and straight from the git-go, the group is corrupted. Those kinds of things I can't properly predict, though I should include something that will check the integrity of the group in question. That should be a start.
Apart from that, I'll look over the routines used to ungroup the file and I'll go ahead and make changes where I see fit. Be reminded that those changes will affect current and future use of some of the already implemented commands, so ... just have to make you aware of it.
After I iron out the ungrouping commands... well. That's for a different topic. |
|
| Back to top |
|
|
Graphmastur
Advanced Member
Joined: 25 Mar 2009
Posts: 360
|
| Posted: 25 Mar 2009 06:04:05 pm Post subject: |
|
|
| Can you also still make a version that I compile using basicbuilder that I can run at the start of my app, and have it work like the Celtic 3 app was on my calc? |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 25 Mar 2009 07:21:54 pm Post subject: |
|
|
Graphmastur wrote: Can you also still make a version that I compile using basicbuilder that I can run at the start of my app, and have it work like the Celtic 3 app was on my calc?
Celtic III takes up nearly 15kb (14914 bytes, which is ~1.4kb short of a full page), and it's not even done being built yet. Basicbuilder can't make anything larger than one flash page, so unless you confined your program to a few hundred bytes it's useless.
Last edited by Guest on 25 Mar 2009 07:27:02 pm; edited 1 time in total |
|
| Back to top |
|
|
Graphmastur
Advanced Member
Joined: 25 Mar 2009
Posts: 360
|
| Posted: 25 Mar 2009 09:18:02 pm Post subject: |
|
|
| What if I where to only need, say 3 routines? |
|
| Back to top |
|
|
ticalcnoah
Member
Joined: 28 Oct 2007
Posts: 153
|
| Posted: 25 Mar 2009 09:54:08 pm Post subject: |
|
|
| Well you could go through the source file included and compile it yourself. |
|
| Back to top |
|
|
Graphmastur
Advanced Member
Joined: 25 Mar 2009
Posts: 360
|
| Posted: 26 Mar 2009 10:20:24 am Post subject: |
|
|
ticalcnoah wrote: Well you could go through the source file included and compile it yourself.
I would, but I don't know asm... well, not enough to be able to take out only the code I need, and then turn it into an asm program instead of an app. |
|
| Back to top |
|
|
ZagorNBK
Newbie
Joined: 29 May 2008
Posts: 36
|
| Posted: 04 Apr 2009 02:25:12 pm Post subject: |
|
|
tribal wrote: Don't know why, but the xLIB demo that comes with xLIB doesn't work with CelticIII, nor does OTBP Assembler++...
I think for xLIB there is a clipping problem with the matrix map data. As for OTBP Assembler++... I have no idea. Those are my thoughts, not completely sure and all... :ninja:
You should really use the normal OTBP assembler, the ++ edition is too buggy in my opinion, plus the commands arn't the normal ones, they are shortened to save space. |
|
| Back to top |
|
|
Mapar007
Advanced Member
Joined: 04 Oct 2008
Posts: 365
|
| Posted: 06 Apr 2009 01:31:33 am Post subject: |
|
|
Iambian wrote: There exists a problem revolving around groups that just can't be fixed. Sometimes, the TI-OS will fail to properly construct the group and straight from the git-go, the group is corrupted. Those kinds of things I can't properly predict, though I should include something that will check the integrity of the group in question. That should be a start.
Apart from that, I'll look over the routines used to ungroup the file and I'll go ahead and make changes where I see fit. Be reminded that those changes will affect current and future use of some of the already implemented commands, so ... just have to make you aware of it.
After I iron out the ungrouping commands... well. That's for a different topic.
Have you taken a look at brandonw's grouptool? I know it can handle groups that usually throw a "version error" without any trouble. (TI sometimes sets the version byte to $FF without any apparent reason?) |
|
| Back to top |
|
|
Graphmastur
Advanced Member
Joined: 25 Mar 2009
Posts: 360
|
| Posted: 15 Jun 2009 06:20:15 pm Post subject: |
|
|
| Well, I was thinking, and have an idea. Maybe have an extra function, to do tilemaps, like, being able to specify a program, and have some way for it to draw the tilemap. Just an idea, but it would allow you to create tilemaps of multiple tiles, instead of just one. |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 15 Jun 2009 06:22:53 pm Post subject: |
|
|
Graphmastur wrote: Well, I was thinking, and have an idea. Maybe have an extra function, to do tilemaps, like, being able to specify a program, and have some way for it to draw the tilemap. Just an idea, but it would allow you to create tilemaps of multiple tiles, instead of just one.
What would be in the program and what do you mean by "create tilemaps of multiple tiles, instead of just one"? |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 30 Jul 2009 07:36:19 pm Post subject: |
|
|
Project's not dead. Getting just a little more work done on it. Most importantly, I'm going to revise the ReadME file. It seems that telling people to RTFM just isn't enough. Is it really that hard to find stuff in that file?
I can't remember what I've done for the project, so when version ® is released, I'm going to restart the bug reports thread with a slightly different set of guidelines.
Most recent thing I'm adding is this feature that lets you draw text to the graph buffer without updating the screen. It seemed like this was a big problem for some people, so I intend on fixing this. |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 30 Jul 2009 08:44:24 pm Post subject: |
|
|
Iambian wrote: Project's not dead. Getting just a little more work done on it. Most importantly, I'm going to revise the ReadME file. It seems that telling people to RTFM just isn't enough. Is it really that hard to find stuff in that file?
I can't remember what I've done for the project, so when version ® is released, I'm going to restart the bug reports thread with a slightly different set of guidelines.
Most recent thing I'm adding is this feature that lets you draw text to the graph buffer without updating the screen. It seemed like this was a big problem for some people, so I intend on fixing this.
Since that means you only have to update the screen once, would this allow text to pop up that much faster? |
|
| Back to top |
|
|
Graphmastur
Advanced Member
Joined: 25 Mar 2009
Posts: 360
|
| Posted: 30 Jul 2009 09:17:11 pm Post subject: |
|
|
metagross111 wrote: Iambian wrote: Project's not dead. Getting just a little more work done on it. Most importantly, I'm going to revise the ReadME file. It seems that telling people to RTFM just isn't enough. Is it really that hard to find stuff in that file?
I can't remember what I've done for the project, so when version ® is released, I'm going to restart the bug reports thread with a slightly different set of guidelines.
Most recent thing I'm adding is this feature that lets you draw text to the graph buffer without updating the screen. It seemed like this was a big problem for some people, so I intend on fixing this.
Since that means you only have to update the screen once, would this allow text to pop up that much faster?
I don't know about making it faster, but I have had some issues with outputting stuff directly to the screen, before. If I had something loading, I didn't want to have to load text, too, otherwise it would update and flash it on the screen.
EDIT: Oh, and I Read the Manual. Oh well, but it was kinda long, and I would've enjoyed seeing a pdf file.
Last edited by Guest on 30 Jul 2009 09:19:05 pm; edited 1 time in total |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 30 Jul 2009 10:05:38 pm Post subject: |
|
|
Graphmastur wrote: metagross111 wrote: Iambian wrote: Project's not dead. Getting just a little more work done on it. Most importantly, I'm going to revise the ReadME file. It seems that telling people to RTFM just isn't enough. Is it really that hard to find stuff in that file?
I can't remember what I've done for the project, so when version ® is released, I'm going to restart the bug reports thread with a slightly different set of guidelines.
Most recent thing I'm adding is this feature that lets you draw text to the graph buffer without updating the screen. It seemed like this was a big problem for some people, so I intend on fixing this.
Since that means you only have to update the screen once, would this allow text to pop up that much faster?
I don't know about making it faster, but I have had some issues with outputting stuff directly to the screen, before. If I had something loading, I didn't want to have to load text, too, otherwise it would update and flash it on the screen.
EDIT: Oh, and I Read the Manual. Oh well, but it was kinda long, and I would've enjoyed seeing a pdf file.
but...... it WOULD be faster, right? |
|
| Back to top |
|
|
|
Celtic III => Your Projects
