Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
That should do the trick. I used that successfully in this demo (the real(5,0,X is hiding in the middle of that code).
Thanks for the link. I will examine your code into details soon.
Could you possibly port over the Celtic II CE function "ToString" (det(13)) to DCSE? It would be an enormously helpful command. It'd definitely speed up saving a Sorcery of Uvutu file, for example. Now, it takes about 5 seconds to save. It may not sound like much, but check out any recent screenshot where I saved, and it is an awkwardly long time. Converting a number to a string in the old TI-Basic way is the only way (as far as I know) to save data into an AppVar using only Hybrid-Basic. As AppVars are extremely useful and versatile variables, it would be beneficial to make saving to them faster. Thanks either way!
123outerme wrote:
Could you possibly port over the Celtic II CE function "ToString" (det(13)) to DCSE? It would be an enormously helpful command. It'd definitely speed up saving a Sorcery of Uvutu file, for example. Now, it takes about 5 seconds to save. It may not sound like much, but check out any recent screenshot where I saved, and it is an awkwardly long time. Converting a number to a string in the old TI-Basic way is the only way (as far as I know) to save data into an AppVar using only Hybrid-Basic. As AppVars are extremely useful and versatile variables, it would be beneficial to make saving to them faster. Thanks either way!

I think those might have already been implemented, however, a few weeks back, not sure what that was about, but we got a little teaser of some possible upcoming ti-basic commands after t^3 this year, which included toString, so from what I understood, there is a good chance that 5.2 includes toString, which of course would mean that you wouldn't need libs at all for it.
How big are the numbers that you want to convert?

I say this because the xLIBC function DrawStringValueA will convert the number passed to it into a string in Ans as long as it is between -9999 to 9999.

You can just draw the string offscreen and use Ans if it works for you.
mr womp womp wrote:

I think those might have already been implemented, however, a few weeks back, not sure what that was about, but we got a little teaser of some possible upcoming ti-basic commands after t^3 this year, which included toString, so from what I understood, there is a good chance that 5.2 includes toString, which of course would mean that you wouldn't need libs at all for it.

The toString command, I believe, was only planned for the CE. The DCS Wiki on Color Libraries says det(13) is for the CE only.
tr1p1ea wrote:
How big are the numbers that you want to convert?

I say this because the xLIBC function DrawStringValueA will convert the number passed to it into a string in Ans as long as it is between -9999 to 9999.

You can just draw the string offscreen and use Ans if it works for you.

Oh wow, I didn't know that! Thanks!
123outerme wrote:
mr womp womp wrote:

I think those might have already been implemented, however, a few weeks back, not sure what that was about, but we got a little teaser of some possible upcoming ti-basic commands after t^3 this year, which included toString, so from what I understood, there is a good chance that 5.2 includes toString, which of course would mean that you wouldn't need libs at all for it.

The toString command, I believe, was only planned for the CE. The DCS Wiki on Color Libraries says det(13) is for the CE only.

Oops, I must have read it too quick, I thought you were talking about DoorsCE
123outerme wrote:
tr1p1ea wrote:
How big are the numbers that you want to convert?

I say this because the xLIBC function DrawStringValueA will convert the number passed to it into a string in Ans as long as it is between -9999 to 9999.

You can just draw the string offscreen and use Ans if it works for you.

Oh wow, I didn't know that! Thanks!

That is probably because this command is not in the sdk, it jumps from real(6,0) (DrawString) to real(7,0) (DrawShape) Razz I learnt about it by looking at other people's code
mr womp womp wrote:

That is probably because this command is not in the sdk, it jumps from real(6,0) (DrawString) to real(7,0) (DrawShape) Razz I learnt about it by looking at other people's code

I actually don't use the SDK. I use http://dcs.cemetech.net/index.php/Third-Party_BASIC_Libraries_%28Color%29
It does say that it does that, I just never read that before.
We are also looking at removing the +/-9999 limit and extending this to 16-bit (or possibly 24-bit) values.
tr1p1ea wrote:
We are also looking at removing the +/-9999 limit and extending this to 16-bit (or possibly 24-bit) values.

That would be great!
I've just come back to ask, is det(13), the ToString function planned for DoorsCE, coming to DoorsCSE also? That would be really nice for, for example, the saving routine in Sorcery of Uvutu. Right now, it takes about 5-10 seconds to save; This could be down to a 3 or less with a Celtic function. I understand everyone's working to get DoorsCE out, but maybe after that's done?
123outerme wrote:
tr1p1ea wrote:
We are also looking at removing the +/-9999 limit and extending this to 16-bit (or possibly 24-bit) values.

That would be great!
I've just come back to ask, is det(13), the ToString function planned for DoorsCE, coming to DoorsCSE also? That would be really nice for, for example, the saving routine in Sorcery of Uvutu. Right now, it takes about 5-10 seconds to save; This could be down to a 3 or less with a Celtic function. I understand everyone's working to get DoorsCE out, but maybe after that's done?

I don't think it will be coming to either calculator because the CE already has ToStringy functions built in (toString() and eval()). This makes the det(13) function nearly useless for the CEs. The CSE is very quickly being left behind, and I strongly doubt that Kerm or tr1p1ea would take the time to go back and implement det(13) just for the CSE. It made sense to add it in to DoorsCE because it is pretty useful, and then add it in DoorsCSE for cross-compatibility reasons, but if it doesn't get added in the first place, then the cross-compatibility argument falls apart. As for speed, I know very well that the perpetual thorn is very inefficient and is only really a solution if you need it once or twice, but I guess it will simply be a problem people never got around to dealing with before moving on to faster and thinner calculators Razz
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 14 of 14
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement