This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Xeda112358
Pages: 1 ... 98 99 [100] 101 102 ... 317
1486
« on: December 01, 2012, 08:34:39 am »
Hehe, it's really useful! Before I learned about it, I used Pxl-Off() in a While loop (but that was years ago when I made the first version of this game).
1487
« on: December 01, 2012, 08:28:47 am »
Oh, I just use Line(x1,y1,x2,y2,0) to erase part of the line.
1488
« on: December 01, 2012, 08:27:39 am »
A few days ago, tr1p1ea (you know, the guy that created xLIB) released solidFrame-- a 3D model viewer. It can take Wavefront OBJ files (converted, of course) and allow you to rotate and explore objects. And these aren't simple wireframe models, either, but instead these are textured models. Here are a few pieces of candy for your enjoyment:    Go ahead and give it a try! (A 15MHz calculator is suggested, by the way, but it will work on a 6MHz calc) Discussion TopicDownload
1489
« on: December 01, 2012, 08:08:05 am »
No, I just use two Line( commands (and two Pt-On( commands for the tips).
1490
« on: December 01, 2012, 08:02:17 am »
Yes, yes I did, thanks!
1491
« on: December 01, 2012, 07:57:33 am »
Yes, without using bcalls which would require using opcodes.
1492
« on: December 01, 2012, 07:56:40 am »
It won't send to my calc, I think I broke it :[ Everytime I try to send it, it flashes "Garbage Collecting" then the error XMIT, then my calc crashes. Before this, it was saying there wasn't sufficient memory, though I had >200000 bytes of archive space and I eventually removed enough stuff to make it >300000. It's an 84+, by the way, using TIConnect. I think I must have either messed up my OS or TIConnect can't handle such a large app  (But it sent Pokémon Red to my SE 0_o)
1493
« on: November 30, 2012, 11:28:19 pm »
Wooh, can't wait to try it 
1494
« on: November 30, 2012, 06:53:29 pm »
You can make an asm library that is a program  You've probably seen a bazillion of mine. Basically what I think they mean is that you can make an Axe program that handles all the graphics based on input from a BASIC program.
1495
« on: November 30, 2012, 12:44:39 pm »
Thanks! I could make a large-ish assembly program (about 1000 bytes, probably) that could make this program a lot smaller and faster, but if I did that, I would just write the whole program in assembly
1496
« on: November 30, 2012, 07:18:43 am »
Wow, Hot_Dog, this is great! I saw the post you made a while ago when you were thinking about this program and I am glad you have it done. We don't have many educational games in the TI community and I have not found any that look this fun. Well done, Hot_Dog  When you finish, let us know! I am sure there are people here who would like to port the game for other languages.
1497
« on: November 30, 2012, 07:09:50 am »
I'm looking forward to your program! By the way, what language will you program in ? (Axe, BASIC, Assembly...?) EDIT: Nevermind, read the topic title
1498
« on: November 29, 2012, 10:14:45 pm »
I spent about an hour earlier today reorganising some code to use my LblRW program. I know I said I didn't want to use any more assembly programs, but this is definitely helpful. First, it lowered my program size by a few hundred bytes, making it so that the size of this program balances things out. Also, the peak RAM usage of the previous version compared to the peak RAM usage of this version is now about 800 bytes less. I also use much fewer variables and the player name is now stored inside the program instead of Str1 Now if I make a method to store all of the save data internally, instead of in a list, I estimate that I can save an average of over 1500 bytes from the peak RAM usage (and the user won't have to have a 1112 byte list). Because I am using LblRW, now, a bazillion If statements were taken out of the battle engine, speeding things up. Also, I can now return which items were acquired from battle using a small 20 or 30 bytes of code instead adding in the hundreds of bytes I was avoiding (about 400). You might notice the lack of a player sprite in battle... I plan to make an in game sprite editor so that players can customise their sprite Again, this is made much easier because of LblRW  * Xeda112358 is happy
1499
« on: November 29, 2012, 09:21:57 pm »
Grammer has no built in functions for reading archived content, unfortunately.
As to the pointers, yes, just find the number of bytes of each sprite as the offset. For example, say you store the sprites to appvar "Sprites" and these are your first few sprites:
:.A
:08081C3E1C7F3E7EFF7EFF7EFF3C1818 ;16 bytes (compressed)
:.C
:004428FE92FE ;6 bytes (compressed)
:.N
:08101C181E181D18391C391C389C389C18581878183808100000 ;26 bytes compressed
Then you could do something like this:
Get("USprites→w+16→s+6→a+26→b...
(Here, I used the pointers you use in your program).
I hope this helps!
P.S.: Here is a trick... In the Grammer program header, nothing is read by Grammer, but it is read by BASIC. This means you can do this:
.0:Pause "Grammer Required":Return
EDIT: The reason I always use the header ".0:Return" is because if Grammer isn't installed, the program won't run. If Grammer is installed, it reads the ".0:" and knows it is a Grammer program.
1500
« on: November 29, 2012, 09:06:11 pm »
 I understand, that usually happens to me during competitions, too  Too much real life stuff and other projects :[
Pages: 1 ... 98 99 [100] 101 102 ... 317
|
Show Posts