Omnimaga
Calculator Community => Casio Calculators => Topic started by: Ashbad on September 10, 2011, 06:35:33 pm
-
Dear public,
After hearing a multitude of requests like "Can you port this from Prizm to the Nspire CX because they're both color?", I decided to make a thread explaining why this won't happen to clear any misconceptions about porting between the two. Please refer people who ask about it here so they can get a general sense of the "why".
Anyways, here are some reasons:
- Prizms and CXs don't both have the same languages to program for them. The CX has Lua, the Prizm has C/ASM. The two are quite different and while it is possible to port between the two, it isn't very practical and will take a *lot* of time.
- The CX has very little likely hood of gaining it's own Ndless (which means it will have the same programming as the Prizm pretty much), and if it does happen to get it, TI will be sure to stamp it out quick. So, very few hopes there.
- If it *does* get C/ASM support, and it keeps it for quite some time, porting between the two is still very hard; there are very few "standard functions" supported by the GCC SDK (basically, most utility functions are Prizm-Specific, not C-Standard) and programmers would have to change their programs to use Nspire or even C-Standard routines instead. It's doable, but it's still painful and not many authors would bother with it.
- The two have different screen sizes, so programs trying to crank the most out of their screen space would have to be redesigned for a different LCD space (I believe it's a bit smaller and narrower on the CX)
- The two run at different speeds, and Prizm programs running at 29MHz would have to be adjusted to run at a different speed (much slower if ported for Lua, much faster if ported with Ndless)
- The two have very different key sets which would fare badly for certain programs.
- With Lua many routines commonly used with the Prizm's C are not useable.
- Most Prizm owners don't own a CX, and likewise the other way around.
- Many of the Prizm owners are fed up with TI and don't *want* to port it to a TI platform
- Porting in general is never as fun as making a game, and even if most of the above didn't apply, most people don't port for the hell of it -- it's usually a very boring and tedious process
If I missed any, post any other reasons below and I'll add them to the list. And be sure to point people to this ;) I know it'll personally save me a lot of explanations.
-
I agree. If I will have to port something, that means I will have to play and try everything possible things in the games over and over, right?
I will never enjoy playing one game repeatedly just so I could port one game to different system.
-
I agree. If I will have to port something, that means I will have to play and try everything possible things in the games over and over, right?
I will never enjoy playing one game repeatedly just so I could port one game to different system.
Oh yes, exactly. You have to pretty much test every single line of non-trivial code, play through the game *multiple times*, have others test it, make all of the changes, and then even do another few quality checks by playing some more and "pushing the engine" to force any bugs out of hiding. All to have it on a somewhat-similar device :P it's bad enough to do that the first time.
On computers, porting between other systems is usually very easy since you can do a lot with just the standard functions, and you usually don't have to worry about key layout, screen size, etc. With calcs, it's a lot worse.
-
This will start to become more profound as Prizm coders begin to use more low level to control the hardware in place of OS routines as we saw many years ago on the 83+. Think for example ionfastcopy and calcnet2.2 which in some cases are so hardware specific that they need to be modified for other 83+ series calcs. Porting these hardware routines would be very difficult or even impossible when going from the Prizm to the CX such as if the serial port is involved.
-
But really, if you're porting C code, all you'll need to worry about is the code that interacts with the hardware. Any gameplay code etc. should work as intended, which removes the need to extensively debug such things. (Well, unless you're somehow relying on little or big endianness, which doesn't usually happen in C.) Yeah, syscalls and helper functions might be different, but that's all part of the porting process.
-
But really, if you're porting C code, all you'll need to worry about is the code that interacts with the hardware. Any gameplay code etc. should work as intended, which removes the need to extensively debug such things. (Well, unless you're somehow relying on little or big endianness, which doesn't usually happen in C.) Yeah, syscalls and helper functions might be different, but that's all part of the porting process.
From someone who's been coding a lot with the Prizm lately, I can tell you firsthand most of the code I write will be pretty painful to port.
-
Can you port this from Prizm to the Nspire CX because they're both color?
Ashbad, first of all, nice article, although I have to think... Where did you see somebody saying that? Thanks.
-
Can you port this from Prizm to the Nspire CX because they're both color?
Ashbad, first of all, nice article, although I have to think... Where did you see somebody saying that? Thanks.
forgot, someone asked that specifically on IRC once, but a lot of questions very similar to that have arisen, not just that one in particular.
-
- The two have different screen sizes, so programs trying to crank the most out of their screen space would have to be redesigned for a different LCD space (I believe it's a bit smaller and narrower on the CX)
6144 pixels to be exact. I don't think it would be too painful to redesign for, though...
- The two have very different key sets which would fare badly for certain programs.
I would have to disagree with that. Admittingly, the API to get the key would be different, but nevertheless, you're still using arrow keys and ENTER. ;)
- With Lua many routines commonly used with the Prizm's C are not useable.
Ehh... they are very different languages. It's like comparing apples to oranges. :P
- Most Prizm owners don't own a CX, and likewise the other way around.
- Many of the Prizm owners are fed up with TI and don't *want* to port it to a TI platform
Agreed there, even if I'm not a person against TI (not in the dev world, anyway).
The most one can do is to ask for the source code and do the port themselves.
You can't ask am Axe coder to port their game to the TI-89, right? ;)
- Porting in general is never as fun as making a game, and even if most of the above didn't apply, most people don't port for the hell of it -- it's usually a very boring and tedious process
Not too bad ;) Wabbitemu -> Linux is kinda fun, as you get to see the program come to life! :D
It's still not as fun as making a game yourself, but porting it is still nothing to be bored of! :)
Personally, I wouldn't say porting is "impossible". ;) Admittingly, Ndless is very young at the moment.
The issue is NOT the hack - the Ndless devs are always hunting and hunting, and they seem to have one in the works. ;)
It's the current SDK that's offered - there's absolutely NO drawing APIs available. You have to do all the screen updating yourself, which isn't fun.
Hopefully, with the next release of Ndless, we might get a full API. :) That will certainly boost the currently stale C/ASM dev for Nspire.
I would also say that the delay may also be because of the new HW, particularly the screen.
The devs are likely trying to figure out how to make good use of it. ;)
In the end, I'd say that if you want a port, you should probably do it yourself... when the time is right. :)
-
Can you port this from Prizm to the Nspire CX because they're both color?
Ashbad, first of all, nice article, although I have to think... Where did you see somebody saying that? Thanks.
forgot, someone asked that specifically on IRC once, but a lot of questions very similar to that have arisen, not just that one in particular.
It was me who asked :P
I am not really into programming languages(*yet*) and such so I didn't know (and asking never hurts right :P).
tbh I was a bit jealous(on prizmcity :P). And thanks for the good explantion you give here (and you gave on the IRC).
-
Asking questions is good, that's why I wrote this whole article; without asking questions, you'll remain without knowledge. If you ask, someone will be sure to tell you in crucial detail exactly why or how it works :)
-
Can you port this from Prizm to the Nspire CX because they're both color?
Ashbad, first of all, nice article, although I have to think... Where did you see somebody saying that? Thanks.
forgot, someone asked that specifically on IRC once, but a lot of questions very similar to that have arisen, not just that one in particular.
Yeah... I have to say, I highly doubt that happened more than once, hence I don't understand the "stop asking us to make ports".
-
Can you port this from Prizm to the Nspire CX because they're both color?
Ashbad, first of all, nice article, although I have to think... Where did you see somebody saying that? Thanks.
forgot, someone asked that specifically on IRC once, but a lot of questions very similar to that have arisen, not just that one in particular.
Yeah... I have to say, I highly doubt that happened more than once, hence I don't understand the "stop asking us to make ports".
It has happened more than once, which is fine, and we're not sternly saying "stop asking us to make ports"; we're just saying why there's an unreasonably low chance that any prizm games will be ported for now.
-
It would be interesting to see an abstraction layer that have the same function calls for stuff like drawing and getting key input for each calc, allowing for simultaneous development for both calcs. (IDK what to do about the different screen sizes though) To make programs for both, it has to start from the very beginning, as making a complete game for one then porting to the other is harder.
-
It would be interesting to see an abstraction layer that have the same function calls for stuff like drawing and getting key input for each calc, allowing for simultaneous development for both calcs. (IDK what to do about the different screen sizes though) To make programs for both, it has to start from the very beginning, as making a complete game for one then porting to the other is harder.
Good point there. Perhaps new games after the Nspire obtains C again will share a set of common libraries with the CX allowing for portability from the start, with a side effect of post-porting being painful. However, remember, the first step is to actually get the CX C support :P