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 - TIfanx1999
Pages: 1 ... 341 342 [343] 344 345 ... 403
5131
« on: February 08, 2010, 10:44:09 am »
You could put Crystal Defenders on hold and work on other things at the moment. Wether you are programming or not, you can still work on graphics and plan maps (scenarios?) out.
5132
« on: February 08, 2010, 10:39:27 am »
Well, you know what they say... "When life gives you lemons, make lemonade!" So, how are you coming along? ^.^
5133
« on: February 08, 2010, 10:37:31 am »
Well, IMHO Speed is #1 bra. Depends on how much data you have also, and if it'll be worth your time and the amount of space it saves.
5134
« on: February 08, 2010, 10:28:59 am »
This is interesting. Finally finished reading through everything. I wonder what all the new romcalls are? I'm kind of shocked that TI is updating... seems like it's been ages. Updates don't happen overnight, but this thing is seems really buggy (from what I've read I don't acutally own an 84). This suggests not much testing has gone into it on TI's end. As far as compatibility goes, I hope this update doesn't break anything too badly. I REALLY hope the fix the text display speeds. Does it still display slowly with pretty print off? I'm Also wondering when they plan to actually release it. If the date is actually in a week, hopefully they have a more stable version completed.
5135
« on: February 07, 2010, 08:54:20 pm »
This is highly interesting. I'll post a more complete response later. I have to get ready for work now. Oh and you haz pm DJ.
5136
« on: February 06, 2010, 07:49:19 pm »
Either ticalc.org needs a complete overhaul of their site to get into this century. (forums, user submitted news, editorials, a better review system. Teamspeak/Ventrilo, ETC) or someone else has to step up to take the void. the only big URL left is calc.org, and it's dead regardless of what the placeholder says. I really wish Adam Berlinsky-Schine would take the site over again and start over with a new team. it's still his domain.
Ticalc.org has needed an overhaul for years, and I'm sure it's been discussed before. It just seems no one has the time or intrest in doing it.
5137
« on: February 06, 2010, 07:35:36 pm »
I might have to borrow my friends copy and get him to teach me the basics. =D
5138
« on: February 06, 2010, 07:31:07 pm »
For usage in a program: Syntax: RecallPic Appvar name, sprite width(multiple of 8), sprite height, screen x coordinate, screen y coordinate.
Each appvar would be predefined to hold 768 bytes of data( i dont know if appvars themselves take up space), so you can either fill it with one full screen pic or several smaller sprites 8x8, 16x16 etc.
At compile time all the necessary data could be copied from the Appvar. If this is plausible, I don't know that the StorePic command would even be necessary in it's normal sense.
Pics would be used when you have large ammounts of sprite data, and could be archived if needed. And Binary would be used when you have a small amount of sprites or just want to play around a but. And then when compiling the program, the pics/binary would be stored into the program itself so that there is no need for any pics/appvars to run your program.
This is what I was saying as well. However change "Appvar" in my original quote to "Picture files". Could they be written in binary for readability and the have axe convert them to hex when the program is being compiled?
5139
« on: February 06, 2010, 08:05:35 am »
Ok, I see what you mean now. I think I'd prefer reading sprites from a Picture file, but hex sprites wouldn't be too bad either.
5140
« on: February 05, 2010, 08:23:55 pm »
Back on topic...
I'm going to get to the sprite stuff soon, but I don't know quite how the user will define a sprite. I think I will offer multiple methods for different purposes, but I'm not sure what they will be exactly.
My first idea was to do something like this:
StorePic 1A
[--****--]
[-******-]
[**-**-**]
[********]
[*-****-*]
[**----**]
[-******-]
[--****--]
It looks better on the calc. This would store a happy face into Pic1A. The problem with this, is that it uses a lot of space in the Source file, but the advantage is that you can make the entire program without needing any external tools and it becomes very easy to make sprites. In your original post you mentioned that using Picture files would take up alot of space, so I was trying to find an alternate workable solution. Perhaps I misunderstood and you just meant the picture files themselves were large? If that's the case, I don't mind. Picture files don't take up that much space in my opinion. Additionally, if someone wanted to make a really large game they wouldn't have to worry about having to use hacked picture files. An Appvar can also be named whatever the user wanted. If using hacked pictures isn't a problem then picture files would be a much better solution.
5141
« on: February 05, 2010, 06:07:59 pm »
To be clear I just meant the Appvar as storage to hold the sprites. When Axe compiles the program the sprite data would be copied from the Appvar to your new program. You'd only need the Appvar if you wanted to "build" the program. That way it wouldn't need to remain on calc after you complete your program. Although, If you release the source with your program, I'm sure you'd want to include the Appvar as well (so it would be buildable)
5142
« on: February 05, 2010, 09:02:50 am »
It still remains really popular too. I can't believe how many people still play it! O_o I guess it's developers did something right! 
5143
« on: February 05, 2010, 08:55:38 am »
Are you able to attack your own party members to gain proficiency in Escheron? Or are you unable to attack them at all? No. Like FF2, enemies have ranks, and how your stats are increased depends on those ranks. Even if you could attack your characters, it would not influence your stat growth. Stat growth is tied directly to which items you have equipped, and which enemies you fight. FF2 had a system where stats increased as they were used. i.e., you had to sustain damage in order to increase your vitality. Ah, ok. That's an cool setup. Although, I did enjoyed pummeling the daylights out of my party members. I am really glad that I don't have to get the tar beaten out of me in order to increase vitality though. In regards to Final Fantasy II, magic was underpowered and it made me sad. I ended up getting lost near the final area of the game, so I did ALOT of grinding. My highest spells were a level 15 cure and a level 16 cure. Each character had 16 and 15 spells total respectively (of my two casters). Average spell levels were 8.06 and 6.3 respectively. I have 37:37 game time logged. I never did end up finishing that game... 
5144
« on: February 05, 2010, 08:32:43 am »
Oh ,that's right! It would bloat your program by the size of the font display routine(s) and the sprites needed for font(s).
5145
« on: February 05, 2010, 08:16:47 am »
Whatever method you choose for sprites I would prefer if Axe did not have to rely on a seprate external program to implement sprites. However, if the most efficient way to handle sprites is by the use of an external program then I am all for it. Hmm... perhaps sprites could be stored in a user defined appvar and called from there?
Actually, now that I am thinking more about it, I think an external program would be the best way. It would be used to edit, view, and save sprites.
For usage in a program: Syntax: RecallPic Appvar name, sprite width(multiple of 8), sprite height, screen x coordinate, screen y coordinate.
Each appvar would be predefined to hold 768 bytes of data( i dont know if appvars themselves take up space), so you can either fill it with one full screen pic or several smaller sprites 8x8, 16x16 etc.
At compile time all the necessary data could be copied from the Appvar. If this is plausible, I don't know that the StorePic command would even be necessary in it's normal sense.
Pages: 1 ... 341 342 [343] 344 345 ... 403
|
Show Posts