| Author |
Message |
|
Graphmastur
Advanced Member
Joined: 25 Mar 2009
Posts: 360
|
 Posted: 31 Jul 2009 08:27:52 am Post subject: |
|
|
| I don't know about it being faster, for things like text sprites, maybe. |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 31 Jul 2009 11:06:35 am Post subject: |
|
|
Graphmastur wrote: I don't know about it being faster, for things like text sprites, maybe.
That's why I'm asking Iambian. Maybe he would know, since he's writing it and all. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 31 Jul 2009 09:16:32 pm Post subject: |
|
|
Drawing the text straight to the buffer might not be that much faster since I don't know how the routine is coded in the TI-OS, but I do know that it will appear to be faster since the text appears all on the graphscreen at once.
I was thinking about going about this two ways, each with interchangeable options. One would be to just render the text as it would appear with the Text( command and the other would require the user to put in hex codes to display straight from the font map. Doing it the former way would allow easy editing but doing it the latter way would gain you access to characters that you simply cannot access any other way.
Doing it the former way is giving me a little trouble, but I should have no problem with the latter method. I'll work on the program until both ways are implemented. |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 01 Aug 2009 09:57:10 am Post subject: |
|
|
Iambian wrote: Doing it the former way would allow easy editing but doing it the latter way would gain you access to characters that you simply cannot access any other way.
In case anyone's wondering, the character set (and their codes) are here, and the characters that aren't accessible any other way are: 0F, 24, D1-D4, DE-E2, E4-F1, and F3. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 03 Aug 2009 03:42:23 pm Post subject: |
|
|
New release of Celtic III. I don't quite remember what is or isn't fixed other than the most obvious problems.
This version adds identity(10...) which allows you to draw the text to the buffer without it being updated. Gives you all sorts of options like inverting the text, using large text, extending the character one line past the bottom so the inverted text would look good, and being able to use a hex string in place of actual text in order to draw text directly off of the font map.
Later on, I might go ahead and attach said font map so that there would be a quick reference available. For the time being, use the reference found in "Asm in 28 Days". |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 03 Aug 2009 11:21:23 pm Post subject: |
|
|
| woo! |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 04 Aug 2009 07:57:02 pm Post subject: |
|
|
| Start looking for them bugs! They aren't gonna find themselves. Sorta. |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 07 Aug 2009 06:40:56 pm Post subject: |
|
|
On it, Iambian! But I need you to do something for me. Can you right a command that appends a character to the beginning or end of a string?
Here's a for-example:
I want to append a "0" to the beginning of "12" until the string is 4 characters long.
det(35, "S", "C", CF, L, PF
S = string to append to
C = data of character to append
CF = whether C is the character or the hex of the character ( 0 for character, 1 for hex )
L = length of output string ( can't be less than input string )
PF = Where to append ( 0 for beginning, 1 for end )
so det(35,"12","0",0,4,0) would yield "0012"
can that be done? I think it would be useful.
Last edited by Guest on 07 Aug 2009 06:41:17 pm; edited 1 time in total |
|
| Back to top |
|
|
Builderboy2005
Advanced Newbie
Joined: 19 Apr 2009
Posts: 51
|
| Posted: 07 Aug 2009 07:58:16 pm Post subject: |
|
|
metagross111 wrote: On it, Iambian! But I need you to do something for me. Can you right a command that appends a character to the beginning or end of a string?
Um, this can be done quite easily in basic.  Unless there's something I'm missing? This seems like a really specific request.
Code:
C
For(F,length(S)+2,L
C + Ans
End
S + C -> S
or
Code:
C
For(F,length(S)+2,L
C + Ans
End
C + S -> S
I tried to optimize for speed, so instead of storing to S every itteration, it just stores to Ans. Adding on 100 characters only takes less than a second. |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 07 Aug 2009 08:20:24 pm Post subject: |
|
|
| I think this is VERY important to have, if you need strings that are the same size. Iambian only has it enabled for hex. |
|
| Back to top |
|
|
Builderboy2005
Advanced Newbie
Joined: 19 Apr 2009
Posts: 51
|
| Posted: 07 Aug 2009 08:44:22 pm Post subject: |
|
|
metagross111 wrote: I think this is VERY important to have, if you need strings that are the same size. Iambian only has it enabled for hex.
Ok, its very important. Can't it still be done in Basic? |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 07 Aug 2009 09:18:37 pm Post subject: |
|
|
| makes more sense and uses less variables, and takes lees time. just because you can doesn't mean that you should. |
|
| Back to top |
|
|
magicdanw
pcGuru()
Calc Guru
Joined: 14 Feb 2007
Posts: 1110
|
| Posted: 07 Aug 2009 10:29:38 pm Post subject: |
|
|
metagross111 wrote: makes more sense and uses less variables, and takes lees time. just because you can doesn't mean that you should.
Celtic's primary purpose is to allow Basic programs to do things that they cannot do at all in pure Basic. Adding in features like specific loops, which can already be implemented in Basic, wastes space in the Celtic app, and are not very beneficial to everyone. IMO |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 07 Aug 2009 10:58:14 pm Post subject: |
|
|
 |
|
| Back to top |
|
|
Builderboy2005
Advanced Newbie
Joined: 19 Apr 2009
Posts: 51
|
| Posted: 08 Aug 2009 12:18:50 am Post subject: |
|
|
magicdanw wrote: Celtic's primary purpose is to allow Basic programs to do things that they cannot do at all in pure Basic. Adding in features like specific loops, which can already be implemented in Basic, wastes space in the Celtic app, and are not very beneficial to everyone. IMO
Exactly, well said. This is a very specific request, and CelticIII needs to be filled with useful functions that are also widely used, so as not to waste space that could be used defining more general functions. Is this a request for a specific circumstance in a game or program? |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 18 Aug 2009 08:43:44 pm Post subject: |
|
|
A version of Celtic III has been released to address the problems found in the "DRAWTEXT" and "LOOKUPINDEX" commands. I also added a flag to the DRAWTEXT command that allows updating to the LCD. See the readme about that.
metagross111 wrote: I think this is VERY important to have, if you need strings that are the same size. Iambian only has it enabled for hex.
You're probably thinking along the line of the "DECTOHEX" function that optionally pads its output to 4 characters. The code doesn't actually "pad" those zeros, but instead, skips the code used to remove those leading zeros. I probably should've said something like that, but I thought it would be a little more confusing if I said it like I did in this post. |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
| Posted: 19 Aug 2009 03:59:22 pm Post subject: |
|
|
Iambian wrote: Drawing the text straight to the buffer might not be that much faster since I don't know how the routine is coded in the TI-OS, but I do know that it will appear to be faster since the text appears all on the graphscreen at once.
I think it is because it writes more directly to lcd. And in 6x8 fonts uses the 6-bit mode in lcd.
Not the write to buffer and copy all buffer to lcd. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 31 Aug 2009 03:23:32 pm Post subject: |
|
|
Galandros wrote: Iambian wrote: Drawing the text straight to the buffer might not be that much faster since I don't know how the routine is coded in the TI-OS, but I do know that it will appear to be faster since the text appears all on the graphscreen at once.
I think it is because it writes more directly to lcd. And in 6x8 fonts uses the 6-bit mode in lcd.
Not the write to buffer and copy all buffer to lcd.
I was talking more about the routine by itself, since I know the TI-OS tends to do silly things internally which may or may not make it run faster by the addition of a flag that makes the TI-OS write out to buffer-only. If it was the routine trying to handle the logic by itself, I'd certainly say that writing to the buffer alone then updating the whole screen would be faster, but then again, I don't know whether or not the TI-OS does something wonky that makes it almost as slow as the version that writes to the screen.
Someone with more knowledge of how these routines are coded would be needed to verify the speed issues, but I don't think anyone would take the time to do so since it's just that and not anything more worthy of their time, like how the USB interrupts are handled or something. |
|
| Back to top |
|
|
JoeYoung
Advanced Member
Joined: 15 Nov 2008
Posts: 316
|
| Posted: 02 Sep 2009 11:34:21 pm Post subject: |
|
|
Code:
-----------------------------------------------------------------------------
|09 | identity(9,x,y,w,h,Dir,Type,Repeat,LCD_update)
| | ***NOT FULLY IMPLEMENTED YET***
| BOXSHIFT | This command shifts or rotates within a box-shaped area on
| | the screen (and may be the whole screen if you want).
| |
| | x = top-left corner x, 0 thru 11. (each 8 pixels is a byte)
| | y = top-left corner y, 0 thru 63.
| | w = width of box object, 1 thru 12. Specifies byte widths.
| | h = height of box object, 1 thru 64
| |
| | Dir : Each will have a basic direction followed by
| | what you must add to it in order to perform
| | a different type of shift.
| | left = 1
| | right = 2
| | up = 4
| | up-left = 5
| | up-right = 6
| | down = 8
| | down-left = 9
| | down-right = 10
| |
| | Type: Determines what type of shifting is to take place
| | 0 = Keep bit being shifted in
| | 1 = Shift in a black bit (for black backgrounds)
| | 2 = Shift in a white bit (for white backgrounds)
| | 3 = Let bit that shifts out reappar on other side
| | (for scrolling backgrounds)
| |
| | Repeat: A number that repeats the shift operation as
| | many times as specified. Cannot be zero.
| |
| | LCD_update: If it is a number other than zero, the screen
| | is updated with the results.
| |
| | Notes: The routine does not perform clipping. All
| | coordinates and dimensions must remain onscreen.
| |
| | Tips: If you don't update the LCD, this command is real
| | useful for dynamically editing tilemaps by loading
| | them to the buffer, using this command to edit them,
| | then store them back to the pic file, all without the
| | buffer ever being updated. The procedure is fast
| | enough to be dismissed as a slight slowdown due to
| | the BASIC parser.
-----------------------------------------------------------------------------
What isn't implemented by this command?
Also, will we see the update for enabling COPYBOX soon?  |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 28 Jun 2010 09:26:59 pm Post subject: |
|
|
Disregarding all previous posts, I've gotta say that I haven't been working on Celtic III very much in the past. Recently, though, I've started working on it bits and pieces at a time. The reason?
Kerm Martian is integrating Celtic III in his upcoming iteration of his (I assume) well known shell, DoorsCS. In doing so, he's fixing known bugs. To that end, I'm (sorta) collaborating with him to fix bugs that plague C3 that were fixed between version 3.09s and the development version.
By the time DoorsCS7 is expected to be released, I'll have 3.09t ready to download. If I'm perfectly happy with how Celtic III is going, I'm going to set the version at 3.10 and discontinue development. It'll be another month or two before this happens. |
|
| Back to top |
|
|
|
Celtic III => Your Projects
