| Author |
Message |
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
 Posted: 07 Apr 2008 05:13:48 pm Post subject: |
|
|
vuurrobin wrote: how will we be able to check and chanse the error modes, so the programs don't gives an unexpected output because the user chanced the modes.
[post="122269"]<{POST_SNAPBACK}>[/post]
Well. The user really doesn't change those modes. These modes will be accessible from a special command that'll allow direct editing of Celtic III settings. Instructions on how to use this command will become available when I actually figure out how it'll work, but basically, it would go along the lines of such:
Code:
det(22,function,mode#,[newnumber])
Where if function = 0, it would read off the setting for the currently selected mode.
If function = 1, it would write newnumber to the specified mode.
Each "mode" will have a code. For example, error return mode for the det() token would be 1, identity() would be 2, etc.
For values to write to the "modes", I can assign numbers to each of what Celtic III should do. For example, 0=ErrorSupress, 1=RealOutput, 2=StringOutput, 3=TypeMatchOutput, 4=TIOSErr, etc.
As the project expands and changes a bit more, additional "modes" will be placed and documented.
------
This sound like a good plan ?
------
EDIT: I may also change around a few things involving the error system that may increase application size, but by a relatively small degree. This change will allow me to catch ALL the locations of hook exit such that I can draw up a table that includes these exit points (addresses) and associate an "error" to it. It may be a little slower, but this'll guarantee that every exit that does not complete the function will be accounted for and then possibly output.
How's that sound?
Last edited by Guest on 07 Apr 2008 05:33:22 pm; edited 1 time in total |
|
| Back to top |
|
|
Zaphod Beeblebrox
Member
Joined: 02 Jul 2007
Posts: 119
|
| Posted: 01 May 2008 03:14:30 pm Post subject: |
|
|
Here's an idea for a feature that would be hopefully easy to implement and not take up a lot of space: A function that determines whether a program is coded in basic of assembly. Because that would be extremely useful for validating and inputted program. Perhaps something like this:
Code:
det(X,Prgm_Name
returns 1 if basic
returns 0 if asm
... or however it would be reasonable. Perhaps tying it in with det(0) command? I don't know how, but I think this would be very useful. |
|
| Back to top |
|
|
DarkerLine
ceci n'est pas une |
Super Elite (Last Title)
Joined: 04 Nov 2003
Posts: 8328
|
| Posted: 01 May 2008 03:18:37 pm Post subject: |
|
|
I haven't been keeping up to date with Celtic commands, but I'm sure one of them can already be used to check this. Assembly commands begin with the AsmPrgm token (BB 6C) or its compiled version (BB 6D), Basic programs don't.
Edit: I downloaded the last version and checked this: det(14,"FILENAME",0,2 will read the first two bytes, which you'll want to compare to the hex values above.
Last edited by Guest on 02 Aug 2010 01:47:41 am; edited 1 time in total |
|
| Back to top |
|
|
vuurrobin
Advanced Member
Joined: 09 Aug 2006
Posts: 428
|
| Posted: 09 May 2008 01:09:18 pm Post subject: |
|
|
for the string tilemapper, can there be an option to display only a part of the map instead of displaying it over the entire screen. this would be usefull for people who want to use a part of the screen for stats or to restore the background when the character moves.
also can there be an option to scroll the map up by 4 pixels before its written to the graph buffer/screen. I can't use the scroll screen function since this will also scroll whats already drawn on the buffer/screen.
I really need this for a project of mine. |
|
| Back to top |
|
|
Zaphod Beeblebrox
Member
Joined: 02 Jul 2007
Posts: 119
|
| Posted: 09 May 2008 02:04:55 pm Post subject: |
|
|
| I don't know if this is possible via some hex command that I don't understand already, but did you remove the old theta == 3 command from Celtic 2? The one that returned a string containing the quote and store symbols? Because once this is released I need that function for the program I'm writing. |
|
| Back to top |
|
|
vuurrobin
Advanced Member
Joined: 09 Aug 2006
Posts: 428
|
| Posted: 09 May 2008 02:18:20 pm Post subject: |
|
|
| you can get that using the hex to bin command. |
|
| Back to top |
|
|
Zaphod Beeblebrox
Member
Joined: 02 Jul 2007
Posts: 119
|
| Posted: 09 May 2008 02:44:38 pm Post subject: |
|
|
| How? I don't have all that great knowledge of hex, and that command really doesn't make sense to me. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 09 May 2008 11:37:56 pm Post subject: |
|
|
If you read the token table that's included (or at least *should* be included) with the package, you can get a fairly good idea of what the hex to bin command can spit out.
For your purposes, you can do the following to output what you want:
Code:
;2A=tString , 04=tStore
det(17,"2A") // outputs the quotes
det(17,"04") // outputs the sto symbol
det(17,"2A04") // outputs the quotes and the sto symbol in that order
The hex to bin command is far more flexible and is also the reason why I removed the StringToken command from the list after changing what you mentioned about the string output command. |
|
| Back to top |
|
|
elfprince13
Retired
Super Elite (Last Title)
Joined: 11 Apr 2005
Posts: 3500
|
| Posted: 12 May 2008 10:23:02 pm Post subject: |
|
|
a pet peeve of mine with xLib is that data must be stored in pics and matrices. any chance we could get access to the graphics routines through Strings? (i.e. hex strings for sprite data, and using wrapped Strings to store tilemap data)
the advantage of strings over pics is that Strings can be stored inline in a program improving the installation experience, and the advantage over matrices is that matrices are really wasteful of space for a simple tilemap
Last edited by Guest on 12 May 2008 10:24:28 pm; edited 1 time in total |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 13 May 2008 08:31:00 pm Post subject: |
|
|
elfprince13 wrote: a pet peeve of mine with xLib is that data must be stored in pics and matrices. any chance we could get access to the graphics routines through Strings? (i.e. hex strings for sprite data, and using wrapped Strings to store tilemap data)
the advantage of strings over pics is that Strings can be stored inline in a program improving the installation experience, and the advantage over matrices is that matrices are really wasteful of space for a simple tilemap
[post="123597"]<{POST_SNAPBACK}>[/post]
It's currently not tested since I'm trying (and failing) to get xLIB compatibility working, but the PicArc extension has what you're talking about, at least for the tilemap part. I wouldn't consider changing Pics to strings since *that* is quite wasteful if kept to hex, and downright unreliable if kept in binary.
The PicArc extensions includes commands that makes installation of Pic files easier for the user. You ought to read up on them and maybe that might ease some fears that one may have. But if that's not possible, then maybe I might consider the string to pic thing, but first take a look at the command set relating to identity().
You'll lose the 16-bit tile index, but I'm sure you can live with only 256 tiles at a time, right ?
------
For a sprite routine, converting between hex and binary for sprite data might not exactly be the best thing, since you'll most certainly take a performance hit for it. Which isn't to say that it cannot be done. In fact, I can do it quite easily. All I have to do is link a new PicArc command that performs conversions and data manipulation and then passes said data to the xLIB function responsible for drawing the sprite to the screen.
Actually, something like that might be so easy to do... I may just do it right now  |
|
| Back to top |
|
|
vuurrobin
Advanced Member
Joined: 09 Aug 2006
Posts: 428
|
| Posted: 14 May 2008 06:15:44 pm Post subject: |
|
|
IMHO, I don't think there is need for a sprite function that takes the data from a string instead of a pic file. thanks to the picarc thingy, we can store it to a program and then possebly convert it to a appvar or store the code from that program in a string.
as for a tilemapper that uses strings instead of matrices, it is already included. although it would be better/more usefull if it had the functions I said some post above.
fixing the store pics compressed function would also help. |
|
| Back to top |
|
|
trevmeister66
Advanced Newbie
Joined: 17 Jan 2007
Posts: 69
|
| Posted: 14 May 2008 07:37:17 pm Post subject: |
|
|
| Actually I agree that there should be a sprite routine that uses a Hex string instead of a pic. I think it would be easier and more memory effective (depending on size and quantity) than using a pic. What if you only want just a few sprites? A whole 767 (or whatever it is) bytes is not worth the few sprites that you require. |
|
| Back to top |
|
|
elfprince13
Retired
Super Elite (Last Title)
Joined: 11 Apr 2005
Posts: 3500
|
| Posted: 14 May 2008 07:51:08 pm Post subject: |
|
|
Iambian wrote: I wouldn't consider changing Pics to strings since *that* is quite wasteful if kept to hex, and downright unreliable if kept in binary.
....
For a sprite routine, converting between hex and binary for sprite data might not exactly be the best thing, since you'll most certainly take a performance hit for it. Which isn't to say that it cannot be done. In fact, I can do it quite easily. All I have to do is link a new PicArc command that performs conversions and data manipulation and then passes said data to the xLIB function responsible for drawing the sprite to the screen.
I'm not saying ditch Pics, just add capability for strings. another idea, would be to allow the programmer to compile hex data into a Pic (or just a locked program containing binary data) at installation or run time.
Iambian wrote: You'll lose the 16-bit tile index, but I'm sure you can live with only 256 tiles at a time, right ?
of course, although one of my tricks when tilemapping in basic is to use tokens for map data, and then have one string that uses the index of a token inside itself to get a sprite number. be creative and implement it as you see fit, I'm just find matrices to be wasteful of memory. |
|
| Back to top |
|
|
DJ Omnimaga
http://i-lost-the-ga.me
Calc Guru
Joined: 14 Nov 2003
Posts: 1196
|
| Posted: 14 May 2008 08:41:07 pm Post subject: |
|
|
elfprince, I wouldn,t remove matrice support though. If he is gonna add string support, then let matrice in too, to keep xLIB backward compatibility
As for strings over pic, I think Stri9ngs would be too much wasteful of memory, unless you managed to find a compression routine in ASM to reduce their size from 4000+ bytes to under 800. Else, a game with a movie sequence will not even fit on a regular 83+.
Also With string stuff, make sure it is fast enough too 
Last edited by Guest on 14 May 2008 08:44:14 pm; edited 1 time in total |
|
| Back to top |
|
|
Liazon
title goes here
Bandwidth Hog
Joined: 01 Nov 2005
Posts: 2007
|
| Posted: 15 May 2008 12:19:19 am Post subject: |
|
|
| so how much space is left on the APP page for string support? |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 15 May 2008 11:23:28 am Post subject: |
|
|
Liazon wrote: so how much space is left on the APP page for string support?
[post="123685"]<{POST_SNAPBACK}>[/post]
Quite a bit, actually. Most of the routines that has to deal with hex and strings are already there, so it'll be just a minimal bit of code to support just about anything else.
The changes I made since I last posted include: Replacement of the broken sprite routine in PicArc with one that will take hex strings for input (43 bytes), addition of a command pair that allows indexed lookup of file data (200-ish bytes?), a bit of code cleanup, and several documentation updates/revisions.
For the really curious, at the time of this post, I am at 2629 bytes less the faulty app signature. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 10 Jun 2008 12:10:04 am Post subject: |
|
|
For version o (not released as of this post yet), I have a command that will tile an 8*8 sprite across the screen and shift it as you wish in order to ease the burden of creating a scrolling tiled background.
Other than linking, I'm still looking for a way to fill up about 2.5KB.
Note that I will not deal with sound, ray casting, or 3D engines.
Suggestions, other than bug fixes ? |
|
| Back to top |
|
|
luby
I want to go back to Philmont!!
Calc Guru
Joined: 23 Apr 2006
Posts: 1477
|
| Posted: 10 Jun 2008 07:38:56 am Post subject: |
|
|
Just a few minor utilities:
*Variable to String
*Animation Sprite (you give it a sprite {through pic, x,y...}, and a list of x moves and y moves and a refresh speed, and then Celtic moves the sprite according to the x and y moves and when it's done, it goes on to the next command. This would save a lot of repetitive code.)
*Base Conversion |
|
| Back to top |
|
|
vuurrobin
Advanced Member
Joined: 09 Aug 2006
Posts: 428
|
| Posted: 10 Jun 2008 06:31:24 pm Post subject: |
|
|
online functions so we can create MMORPG's and internet browsers ect 
j/k
there are actually some functions needed regarding the string tilemapper. lets say that you have a tile map of 2 by 1 (yes a very small map, I know) and you use tile 60 and 240 for this. you would get the hexstring "3CF0". after using det(17,... (hex to bin) you would get " or ^". now lets say that you forgot what number the first tile is. you can use sub( to get the first token, use det(18,... to get the hex number of it and then you can calculate the number used for the tile.
now lets say you have 187 and 84 as tiles. changing it to hex gets "BB54" and using det(17 would then get "delvar". and now we have a problem, seeing as 1 token is used to represent 2 tiles. we can't use sub( to get 1 tile.
so what we need is a function that returns the number of a tile. something like this:
det(xx,"delvar ",1) returns 187
det(xx,"delvar ",2) returns 84
det(xx,"devar or ^",4) returns 240
what also would be usefull is a function like length( that returns the length of a string, but with counting 2 byte tokens as a lenght of 2.
you can also look at the current functions and see if there is some way to improve them.
and you can also reread this topic for suggestions that are already posted, like superspeler asking for a fast random number generator:
Quote: 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.
or the stuff I asked for the string tilemapper:
Quote: for the string tilemapper, can there be an option to display only a part of the map instead of displaying it over the entire screen. this would be usefull for people who want to use a part of the screen for stats or to restore the background when the character moves.
also can there be an option to scroll the map up by 4 pixels before its written to the graph buffer/screen. I can't use the scroll screen function since this will also scroll whats already drawn on the buffer/screen.
or the stuff you posted about the handling errors and changing the error mode.
maybe a function for 4/5 level flickerless grayscale titlescreens....
thats all I can think of now. if I can think of something else, I'll post it.
/me mumbles something about bad signature falling under bug fixes.
edit: is C3 compatable with the non cas nspire + the 84+ keybord?
Last edited by Guest on 02 Aug 2010 01:47:22 am; edited 1 time in total |
|
| Back to top |
|
|
vuurrobin
Advanced Member
Joined: 09 Aug 2006
Posts: 428
|
| Posted: 19 Jun 2008 08:17:56 am Post subject: |
|
|
| I thought of another function, a function that compresses strings using something like RLE. I'm not sure if its doable, but it would be usefull. |
|
| Back to top |
|
|
|
Celtic III => Your Projects
