As I don't own a TI-83 or TI-84 calculator, I am not as familiar with them as I am to my TI-84+CSE, but I would like to make some of my programs work on both types of calculators. Here are my current questions:

Is there anyway to detect the type of calculator the user is running the program on without using the graph screen?

Is it possible to link a CSE and a monochrome calculator together and play a multiplayer game, if the same program can run on both calculators individually?

How would I convert this into something a monochrome calculator could use? Would I still have to convert the colors to numbers if I jump over this part of code with a If statement?
Code:
```:If C=5 :det(12,BLACK,BLACK :If C=4 :det(12,DARKGRAY,DARKGRAY :If C=3 :det(12,GRAY,GRAY :If C=2 :det(12,MEDGRAY,MEDGRAY :If C=1 :det(12,LTGRAY,LTGRAY :If C=0 :det(12,WHITE,WHITE :Output(A,B," "```
FrozenFire49 wrote:
As I don't own a TI-83 or TI-84 calculator, I am not as familiar with them as I am to my TI-84+CSE, but I would like to make some of my programs work on both types of calculators. Here are my current questions:

Is there anyway to detect the type of calculator the user is running the program on without using the graph screen?
No, you need to use graph screen coordinates, but you can do it without changing graph screen coordinates. We have a topic somewhere about various techniques for that. I tried looking for it, but I'm afraid I couldn't find it.

Quote:
Is it possible to link a CSE and a monochrome calculator together and play a multiplayer game, if the same program can run on both calculators individually?
Yes, GetCalc() uses the same protocol on both calculator versions. And if I or anyone ever gets around to porting CALCnet, that's an option too.

Quote:
How would I convert this into something a monochrome calculator could use? Would I still have to convert the colors to numbers if I jump over this part of code with a If statement?
Code:
```:If C=5 :det(12,BLACK,BLACK :If C=4 :det(12,DARKGRAY,DARKGRAY :If C=3 :det(12,GRAY,GRAY :If C=2 :det(12,MEDGRAY,MEDGRAY :If C=1 :det(12,LTGRAY,LTGRAY :If C=0 :det(12,WHITE,WHITE :Output(A,B," "```
Yes, you would, but it's pretty easy to do. Also, you shouldn't execute those det() statements at all on the monochrome calculators, as under Doors CS det(12) is something completely different, and under the OS, it's nonsensical. Of course, on the monochrome calculators, you have only black text on a white background (and the reverse, if you use DrawText) available to you.
KermMartian wrote:
No, you need to use graph screen coordinates, but you can do it without changing graph screen coordinates. We have a topic somewhere about various techniques for that. I tried looking for it, but I'm afraid I couldn't find it.
I've found this forum (Sticky-ed) http://www.cemetech.net/forum/viewforum.php?f=19. Which one of the ways mentioned to you recommend? I prefer to stay on the homescreen without opening up the graph, if that's an option.
KermMartian wrote:
Yes, you would, but it's pretty easy to do. Also, you shouldn't execute those det() statements at all on the monochrome calculators, as under Doors CS det(12) is something completely different, and under the OS, it's nonsensical. Of course, on the monochrome calculators, you have only black text on a white background (and the reverse, if you use DrawText) available to you.
So what would I use? Is there a library or something that can adjust the darkness of the output to have the different shades of gray?
unfortunately, to do gray on the calc, it needs the screen to be switched really fast to a second, similar image. in other words, for 90% of basic, no. it would be cool if we could control voltage output to specific parts of the screen to get real grays, but the TI doesnt work like that, unfortunately.
LuxenD wrote:
unfortunately, to do gray on the calc, it needs the screen to be switched really fast to a second, similar image. in other words, for 90% of basic, no. it would be cool if we could control voltage output to specific parts of the screen to get real grays, but the TI doesnt work like that, unfortunately.
Looks like I'm left with learning sprites.

Also which type of multiplayer is recommended and/or faster:
Where the game runs off one calculator. For example, Calculator A is the "host". It gets the inputs from calculator B, processes those inputs with the main game stuff, and gives the outputs to calculator B to be displayed.

Where the game runs off both calculators. Each calculator gets their own variables, sends those variables to each other, processes them, and displays their own output, which should be the same.
FrozenFire49 wrote:
Also which type of multiplayer is recommended and/or faster:
Where the game runs off one calculator. For example, Calculator A is the "host". It gets the inputs from calculator B, processes those inputs with the main game stuff, and gives the outputs to calculator B to be displayed.

Where the game runs off both calculators. Each calculator gets their own variables, sends those variables to each other, processes them, and displays their own output, which should be the same.

The second approach is faster, since there's less data to send and more processing power available. However, it's easier to run into bugs that make the calcs desync.
I understand what you're thinking, but I have some concerns with it.
JosJuice wrote:
The second approach is faster, since there's less data to send and more processing power available..
Sure there's twice as much processing power, but there's also twice as much data to process (a set of data for each calculator). I think there will still have to be a host for the random variables, though.
JosJuice wrote:
However, it's easier to run into bugs that make the calcs desync.
The calculators syncing is my concern too, especially when running it on 2 different calculator types.

At the same time, the other way does have more stuff to transfer, like you said.

When I tested GetKey( on my friend's 84+, I've noticed that it is slow, even for just one variable. Also, the other calculator has to be doing nothing for it to transfer, what would I have to do to keep the game from pausing to just send variables?
FrozenFire49 wrote:
I think there will still have to be a host for the random variables, though.
You could set both RNGs to the same seed by storing a value to rand. But yeah, marking one calc as a host sounds like a reasonable idea.
FrozenFire49 wrote:
When I tested GetKey( on my friend's 84+, I've noticed that it is slow, even for just one variable. Also, the other calculator has to be doing nothing for it to transfer, what would I have to do to keep the game from pausing to just send variables?
That's just how GetCalc( works. If you don't want to pause the game, you need to find another (probably assembly-assisted) linking method.
JosJuice wrote:
FrozenFire49 wrote:
When I tested GetKey( on my friend's 84+, I've noticed that it is slow, even for just one variable. Also, the other calculator has to be doing nothing for it to transfer, what would I have to do to keep the game from pausing to just send variables?
That's just how GetCalc( works. If you don't want to pause the game, you need to find another (probably assembly-assisted) linking method.
Thanks for correcting me, by the way. I ment GetCalc( instead of GetKey(.

Anyway, is there a way to get the sending calculator to unpause itself after the variables are sent? Doesn't the receiving calculator unpause itself automatically?
Unfortunately, no, there's no way to do that. One alternative would be to use BASIC CALCnet for the monochrome calculators, although unfortunately there isn't a version for the color calculator yet. It is a much more comprehensive networking protocol that includes polling for messages, and continuing execution if a response or message has not yet arrived.
oh! by the way, is it possible to enable a monocrome 84 program to run on a color 84 program? I would seriously like to know

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.

»
» All times are UTC - 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