The New xLIB - An APP
Moderator: tr1p1ea
- Jim e
- Calc King
- Posts: 2457
- Joined: Sun 26 Dec, 2004 5:27 am
- Location: SXIOPO = Infinite lives for both players
- Contact:
Copying a program from a group to the ram would work without wasting batteries. Something like this.
Decomp("groupname","ProgName"
Also it be nice to catch delvar so it can delete programs(and other things) to.
This way you won't have to unarchive a thing and installation would only need two files(main and group). Personally I don't like 50 some odd progs in my calc, even if I have an se.
Decomp("groupname","ProgName"
Also it be nice to catch delvar so it can delete programs(and other things) to.
This way you won't have to unarchive a thing and installation would only need two files(main and group). Personally I don't like 50 some odd progs in my calc, even if I have an se.
- MissingIntellect
- Regular Member
- Posts: 102
- Joined: Tue 21 Dec, 2004 2:46 pm
- Location: Santa Clarita, California
- Contact:
- dysfunction
- Calc Master
- Posts: 1454
- Joined: Wed 22 Dec, 2004 3:07 am
- Location: Through the Aura
I have an idea for a few routines:
1. A fast text routine, able to draw 3x5, and 5x7 text in regular, video inverse, XOR or OR mode.
2. Some or all of the TI-OS drawing routines, but faster, especially Cricle(. Also a rectangle drawing routine would be great.
And may I further state that tr1p is the man!?
1. A fast text routine, able to draw 3x5, and 5x7 text in regular, video inverse, XOR or OR mode.
2. Some or all of the TI-OS drawing routines, but faster, especially Cricle(. Also a rectangle drawing routine would be great.
And may I further state that tr1p is the man!?
"You're very clever, young man, but it's turtles all the way down!"
@Merthsoft: especialy if they could be filed with either dither, black, white, none...ect and be bordered or borderless
It would be cool if the program would alow for 3 diffrent graph buffers for all called commands (though that of course would take extra memory for each buffer, so it wouldn't be a bad idea to only generate the extra buffers if a function drew to one) and if the drawling tools let you specify which buffer to draw to (without/without update of course) and you could call any them by using a command like DispGraph1, DispGraph2, and DispGraph3[/quote]
It would be cool if the program would alow for 3 diffrent graph buffers for all called commands (though that of course would take extra memory for each buffer, so it wouldn't be a bad idea to only generate the extra buffers if a function drew to one) and if the drawling tools let you specify which buffer to draw to (without/without update of course) and you could call any them by using a command like DispGraph1, DispGraph2, and DispGraph3[/quote]
- dysfunction
- Calc Master
- Posts: 1454
- Joined: Wed 22 Dec, 2004 3:07 am
- Location: Through the Aura
A lil suggestion about the current sprite routine:
would it be possible to have almost the same syntax than omnicalc sprite command, I mean to have something like this
real(1,sPIC_Num,Spr_Num,Spr_Width,SprHeight,Spr_X,Spr_Y,Spr_Method,Spr_UpDateLCD
instead of
real(1,Spr_X,Spr_Y,Spr_Num,Spr_Width,SprHeight,sPIC_Num,Spr_Method,Spr_UpDateLCD
also it would be cool if for the sprite width if we wouldnt have to input the width divided by 8 because it's a bit confusing ;P
would it be possible to have almost the same syntax than omnicalc sprite command, I mean to have something like this
real(1,sPIC_Num,Spr_Num,Spr_Width,SprHeight,Spr_X,Spr_Y,Spr_Method,Spr_UpDateLCD
instead of
real(1,Spr_X,Spr_Y,Spr_Num,Spr_Width,SprHeight,sPIC_Num,Spr_Method,Spr_UpDateLCD
also it would be cool if for the sprite width if we wouldnt have to input the width divided by 8 because it's a bit confusing ;P
-
- Extreme Poster
- Posts: 479
- Joined: Fri 17 Dec, 2004 11:09 pm
- Contact: