Omnimaga
General Discussion => Other Discussions => Miscellaneous => Topic started by: dreamdragon on January 12, 2014, 08:41:31 pm
-
man it sucks. >:(
whenever yo go to any website that offers prgms for your shiny new ti84+c se, all they have are like five prgms.
and what makes you madder is the fact that older calculaters have pages upon pages of downloads!
there has not been much of a coding flood lately for ti's new calc...
dont get me wrong...there are alot of prgms if you search hard enough....
but compared to the downloads for the other ones.....
shesh. :o
and im also talking about prgms that help you with your school work or whatever.
older calcs have loads of prgms for this area. ._.
but ti 84+c se seems to be a quite empty here... :'(
progamers...i challenge you to take those prgms...those prgms that are old and neglected....sitting in the directory page of these websites...
AND PORT THEM. THEY AND THEIR CREATORS DESERVE TO SEE THE LIGHT!!!!!
:hyper:
-
Well, you have to keep in mind that there aren't nearly as many programmers that have the 84+C as the older models. Also, the older models have been around for about 17 years, the newer model has been around for nearly a year.
-
Well, you have to keep in mind that there aren't nearly as many programmers that have the 84+C as the older models. Also, the older models have been around for about 17 years, the newer model has been around for nearly a year.
i know, i know.
im probably rushin it a lil, but comeon.
people who keep checkin in for new prgms will get tired of finding nothing and just call it quits.
:'(
and once that happens its almost impossible to draw them back without decent media coverage. <--- humor,lol ;D
im bored.
does anyone know how to design a program for the ti84+c se that rapidly strobe lights???
like this guy---> :hyper:
-
Why were there multiple topic notifications here but only one post? Did I miss anything? ???
Anyway users are doing calc programming during their free time, which is usually rare for students, so they can port programs if they want, but the best thing is if you can help porting some too, especially if you want old programs ported. Also, the reason why the TI-84 Plus C Silver Edition has so few programs is because it just got released less than a year ago and only made it to offline stores 3 or 4 months ago, when school started.
-
I will only port my recent games. Nobody is interested in the wacky basic games I made before I joined omnimaga :P
-
ah...
that makes sense *.* :hyper:
has there been any attempt at having two different calculator OS models on one calculator?
just wonderin!
Why were there multiple topic notifications here but only one post? Did I miss anything? ???
Anyway users are doing calc programming during their free time, which is usually rare for students, so they can port programs if they want, but the best thing is if you can help porting some too, especially if you want old programs ported.
im a student...
i have made a few prgms...(very simple, ones that help me find slope or hypotenuse)
i sometimes alter prgms on my calc to change the color of a certain object... for ex in fireworks i changed the gray smoke to a multicolored one...
-
please do not make duplicate topics. your poll could have been added to the previous topic, or you could have at least indicated that this was a poll by using a different thread title.
-
Merged both topics, combined some posts, and cleaned the thread up a bit. In regards to your question, Xeda summed it up pretty well. Have some paitence, the new color model really hasn't been out that long at all. Do some of these old projects deserve to be ported? Absolutely!, and I'm sure some of them will in time.
*Edit* It's also worth mentioning that some of the older games won't port over as easily because the method to display things on screen is a bit different on the new model.
-
I don't know if porting older b&w games would be feasable. For some it's deffinately possible, but it's not a good idea for all games.
The games for the b&w calcs are designed to look good in b&w, and many of them have graphics that would be slow or hard to do on the color calc because of having not enough RAM for a graphics buffer (especially not multiple). For this reason, don't expect to see many smoothscrolling games, or games with mode 7 or raycasting.
Fortunately, the higher resolution and color of the new calc do also have some good parts. You can fit a lot more on the screen, and everything will look much better. It also has more flash memory than other calcs of the same line. So, while many 84+ games are about action and moving levels, many CSE games will probably have static levels where only a few things move. This could lead to some great puzzle games, and maybe also some point&click games. And RPG's are very possible as well, but instead of having smoothscrolling, they will probably be more like the ASCII RPG's on the 84+, but with much better graphics.
Moral of this post: It's probably much better to think of new game concepts that go hand in hand with the new high-resolution color screen then to try to port the old b&w games.
-
Portal Prelude was in Axe Parser, not BASIC. As long as Axe isn't ported to the CSE, I doubt that anyone will bother porting Portal Prelude, unless someone is really willing to make a Z80 ASM version from scratch.
Also your posts seems like you are trying to force other people to port programs you want. It is disrespectful. We have lives besides Omnimaga and calculators and we will only port programs if we are willing to do so. Same goes for Axe Parser CSE: The author will only make it if he is willing to do so or if he has time to. If you really want Portal to be available on the 84+CSE this soon, quit using us as your slaves and do it yourself.
-
have you heard of portal prelude?
i want this to be the one that SHOULD be ported...
shesh
at least give me the prgm in BASIC!
Also, of course we have heard of Portal Prelude, it was developped here lol.
But it won't be ported anytime soon since it was written in Axe and Axe is not available yet on the CSE, except if some mad guy, or some really impatient guy disassembles it, change every drawing command then compiles it back. You could do it by the way.
And it won't be cross-ported in basic because that would get ridiculously slow and huge (I am not saying that Basic is always slow and huge, but I think Portal Prelude would work that great).
So wait for the CSE to get its own games, or for Axe to be ported to it so that porting some games is easier, or for Basic authors to port their games, or the same for ASM programmers, but in any case, wait. There is no point saying "please port" because people don't have unlimited free time and not all monochrome coders have a CSE, so some are doing what they can and some don't do what they can't.
-
@dreamdragon: It probably isn't your intention, but you are coming off as a bit demanding/rude. Even if someone did want to port something, it still takes time. Programs don't get created overnight. Keep that in mind. ;) Also, there is a topic for <a href=http://ourl.ca/872685> program suggestions</a>, but please remember that you should be respectful and not pushy. :)
-
On a side note, some games were ported already:
-Block Dude
-Dino Puzzle
-Pac Man
-Scorched Earth
-Tunnel (multiple versions, although they now go horizontally instead of vertically)
-Snake (multiple versions)
Supersonic Ball might be ported one day. The title screen and graphics are already done but that's pretty much it.
-
I'd like to point out how much leeway the forumers have been giving you, dreamdragon. :)
A major problem (besides those listed already) is that many games already pushed the limits of the calc itself and were well written for THAT hardware. This calc is very different and also takes MUCH longer to do screen-related things, which is most of what makes these games: fancy graphics.
Also, many old coders who wrote stuff like Phoenix a decade ago don't stick around anymore to help put stuff on the CSE.
-
Also, many old coders who wrote stuff like Phoenix a decade ago don't stick around anymore to help put stuff on the CSE.
I know what you mean, but that is a bad example. Patrick Davidson is still around, and did in fact (more or less) <a href=http://www.ticalc.org/archives/files/fileinfo/454/45470.html>port Phoenix</a> to the new model. ;)
-
Portal Prelude was in Axe Parser, not BASIC. As long as Axe isn't ported to the CSE, I doubt that anyone will bother porting Portal Prelude, unless someone is really willing to make a Z80 ASM version from scratch.
Also your posts seems like you are trying to force other people to port programs you want. It is disrespectful. We have lives besides Omnimaga and calculators and we will only port programs if we are willing to do so. Same goes for Axe Parser CSE: The author will only make it if he is willing to do so or if he has time to. If you really want Portal to be available on the 84+CSE this soon, quit using us as your slaves and do it yourself.
sorry. i got a little bit too excited. :'( :-[
how do i port, if i might kindly ask. ::)
-
I'd like to point out how much leeway the forumers have been giving you, dreamdragon. :)
A major problem (besides those listed already) is that many games already pushed the limits of the calc itself and were well written for THAT hardware. This calc is very different and also takes MUCH longer to do screen-related things, which is most of what makes these games: fancy graphics.
Also, many old coders who wrote stuff like Phoenix a decade ago don't stick around anymore to help put stuff on the CSE.
ouchies...first word to the old programmers leavin ya guys.....
im so ni eve ...
i will try to be more mature...
-
It is not easy to port game to the TI-84+CSE. First, because programs on the TI-84 are not optimized for this model. Second, because the CSE is not graphically optimal.
The CSE has too few RAM and CPU speed to run smooth games like the non-CSE model did. It is a limitation because even if the programmers keep the sprites in B/W, the CSE still has to render them like color sprites, therefore making games slower than they could run on their original hardware.
That limits the applications that can be ported to the CSE for now. It is not impossible for TI to release a better CSE in the future, but for now games like Portal Prelude or F-Zero probably won't be ported.
As for how to port games, it is the process of re-writing the source code with the new hardware in mind. Luckily, the B/W and CSE models use the same processor architecture (no need to use a new ASM language), but a few things might have changed, like the location of interrupts, system calls and most obvious of all, display functions.
In this perspective, I wonder if a how-to guide for porting game from the B/W models to the CSE is possible. A reference document where the changes between these and how they affect the code are documented. Maybe a post here on Omni like the Axe Parser threads.
-
It is not impossible for TI to release a better CSE in the future, but for now games like Portal Prelude or F-Zero probably won't be ported.
however if TI wanted it could have released at least a CSE with similar specs to other calcs but it is locking down CSE like it did on nspires
-
The CSE has too few RAM and CPU speed to run smooth games like the TI-84 did. It is a limitation because even if the programmers keep the sprites in B/W, the CSE still has to render them like color sprites, therefore making games slower than they could run on their original hardware.
That limits the applications that can be ported to the CSE for now. It is not impossible for TI to release a better CSE in the future, but for now games like Portal Prelude or F-Zero probably won't be ported.
IIRC, the CSE has more RAM than newer 84+ calcs due to extra RAM pages being back. And it doesn't have a higher CPU speed, but since Portal Prelude was made in 6MHz to keep compatibility with the regular 83+, you can still think you do have a higher CPU speed available. You also have the possibility not to refresh the whole screen, which can work on a "static" game like Portal Prelude. But yeah, F-Zero is going to be harder.
the TI-84.
I always say that, and I seem to be the only one, but there is no "the TI-84". This because there is always something behind the "84", either a "Plus" or a "Pocket", sometimes both, sometimes followed by a ".fr" or a "SE", and now with the possibility of a "CSE". So yeah, I can understand that you can't name them all each time and that most of them are compatible between each other, but now that the CSE is out (and since you mentionned the CSE in your sentence), you could talk about non-CSE 84 calcs as "the non-CSE 84 calcs", but not "the 84" since even in your sentence you are talking about another 84 calc so really, there is no "the 84".
the Arse Parser threads.
*.*
Heresy! :P
-
Smooth games are possible on the CSE as long as you don't refresh huge parts of the LCD memory every frame. See Tunnel.8xk, Jumper, JezzBall, Tetrica and Pac-Man, for example. Therefore, Portal Prelude would be possible.
-
Smooth games are possible on the CSE as long as you don't refresh huge parts of the LCD memory every frame. See Tunnel.8xk, Jumper, JezzBall, Tetrica and Pac-Man, for example. Therefore, Portal Prelude would be possible.
agreed. i downloaded tunnel,jumper,jezz ball, tetrica and pacman. ;D(http://www.omnimaga.org/Themes/default/images/gpbp_arrow_up.gif)
they run awesome with absolutely no lag what so ever. ;)
if i do port, i would have to look for the similarities for the basic codes between the two calcs, yes? :)
however.... :-[
the science programs like periodic take forever to draw themselves... :banghead:
(ps: who is assm bandit???) ???
It is not impossible for TI to release a better CSE in the future, but for now games like Portal Prelude or F-Zero probably won't be ported.
however if TI wanted it could have released at least a CSE with similar specs to other calcs but it is locking down CSE like it did on nspires
what do you mean locking? :-\
yes there are new codes in the basic library than the other 84s, but i would not say locking. <_<
n spire is n spire! :evillaugh:
EDIT: Post merged- Xeda112358
-
Locking as in "no native programming support".
-
the Arse Parser threads.
*.*
Heresy! :P
Oopsies, fixed. Also fixed the TI-84 reference.
-
In assembly, sprite rendering would be faster for most size, but only if you have a handful of sprites. Basically, you save time by being able to draw directly to the LCD at pixel coordinates without an LCD delay.
Also, dreamdragon, it is preferred that you use the "Quick Modify" or "Modify" buttons to edit your post instead of posting close together (also known as a "double post" which is referred to in the rules).
-
Is drawing 8 pixels individually really faster than a write to the gbuf and to the lcd?
EDIT: i guess for non-aligned sprites, it probably is.
-
For that size, no. However, a 16-bit color, 16x16 sprite at arbitrary coordinates (no clipping) would take 9506 t-states. On the monochrome models, you would have to rotate the sprite data accordingly before drawing to the gbuf, and then you would have to update possibly 3 columns of 16 pixels tall.
I think I can manage the drawing part using SMC in about 5400 t-states, then the LCD update part would require some quick overhead code to compute the offset into the gbuf, 6 coordinate writes to the LCD, and 48 data writes totaling 54 writes. Assuming the rest of the code is handled in the wait-states, if the average wait-states are 76, then the color model is only slightly faster.
So at 6MHz, it is faster on the monochrome calcs in most cases. However, the monochrome calc wouldn't be running at 6MHz, it would be 15MHz which could require about 130 cycles between LCD writes (sometimes more, sometimes less). In this case, it would take >12000 t-states.
EDIT: For reference, here is the (possibly incorrect) code I was referring to for the CSE calculations:
ld hl,$10B8 ; BGR mode, increment order
ld a,$03
call SetLCDRegister
call SetSpriteWindow
ld hl,sprite
call RenderSprite
<< do whatever >>
ret
RenderSprite:
;Input:
; HL points to the sprite
ld bc,17
ld d,2
outi \ outi \ outi \ outi
outi \ outi \ outi \ outi
jp nz,$-16
dec d
jr nz,$-20
ret
SetSpriteWindow:
ld de,15
ld a,$50
ld hl,(y_coord)
call SetLCDRegister ;Horizontal Start
add hl,de
call SetLCDReg ;Horizontal End
ld hl,(x_coord)
call SetLCDReg ;Vertical Start
add hl,de
call SetLCDReg ;Vertical End
ld hl,(y_coord)
ld a,$20
call SetLCDReg ;Y pos
ld hl,(x_coord)
call SetLCDReg ;X pos
SetLCDRegister:
ld c,$11
SetLCDReg:
out ($10),a \ out ($10),a
out (c),h
out (c),l
inc a
ret
sprite:
.db $03,$C0,$0D,$70,$10,$A8,$20,$54,$40,$2A,$40,$16,$80,$2B,$80,$15
.db $80,$2B,$40,$56,$30,$AC,$0E,$70,$01,$80,$01,$80,$03,$C0,$07,$E0
x_coord:
.dw 151
y_coord:
.dw 112
I adapted it from my attempt at writing a monochrome sprite routine, so the sprite data is mostly garbage now :P
-
In assembly, sprite rendering would be faster for most size, but only if you have a handful of sprites. Basically, you save time by being able to draw directly to the LCD at pixel coordinates without an LCD delay.
Also, dreamdragon, it is preferred that you use the "Quick Modify" or "Modify" buttons to edit your post instead of posting close together (also known as a "double post" which is referred to in the rules).
opps :-[
-
I just got the the new +c. Not a lot of games but the ones like jumper are fun.
-
Heya and welcome to the forums by the way. :D
I hope to make some more +C games myself, but motivation is hard to get at the right moment x.x
-
If i might ask very gently ;):
does porting require you to look at the similarities in the tibasic code in the model of calculator you want to port to?
like, are there older commands that are the same in a new one, but in the newer one its a different command altogether?
and, is it vital that you go through the original prgm to be ported?
just some very curious questions. ._.
:hyper:
-
84+ BASIC to CSE BASIC is almost identical except drawing commands, which have extra arguments. I think those arguments are optional, though. There are also extra commands. However, you still need to adjust stuff since the screen is larger.