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 - Matrefeytontias
Pages: 1 ... 61 62 [63] 64 65 ... 133
931
« on: September 17, 2013, 09:20:51 am »
Thanks guys  Wait, you were 15 all the time? 
Yes sir 
932
« on: September 17, 2013, 01:34:56 am »
Today's my turn I'll be 16 at 2:30pm (France time, it's 7:35am right now) 
933
« on: September 16, 2013, 12:36:47 am »
Here we're talking about attack animation, not regular animation. The double use of "animation" confused everybody I guess 
934
« on: September 15, 2013, 07:13:25 pm »
The only problem I have is the last bullet. I feel like the attack animation should not be restricted to sprites. Instead, I think attacks should be subroutines so that we can make attacks that are customised for graphics and whatnot. For example, a thunderbolt animation might strike several places on the field before attacking a character. Using sprites for this would take a lot of memory, whereas using existing routines for lines and stuff would be a lot smaller.
It's exactly what I meant  for example, an attack data would look like this : Data(Str1r,5,0,300r,255,0,LAttackr)And you would write : :"Thunderbolt"->Str1
:
:etc
:
:Lbl Attack
:animation code for Thunderbolt here
935
« on: September 15, 2013, 04:45:22 pm »
We should arrange all datas like that then  I'll make sure to make a small test with that data format in my engine.
936
« on: September 15, 2013, 01:20:56 pm »
What I planned for data format is something like classes. Here's what I mean : - First there's the character. It has HPs, MPs, stats, a pointer to an animation and a set of pointers to attacks/skills/capacities (dunno how it's called in English).
- Then, there's the attack/skill/capacity. It has a name, a cost in MPs (0 if not required), a byte to tell the effect (hurt, heal, change stats ...), one or two bytes to tell how much damage it does/how much HPs or MPs it restores/by how much a stat increases or decrease, a byte for the precision of the attack, a byte to tell if the target gets a special state (paralized, burnt, frozen etc), and finally a pointer to a bunch of code which will be the animation you see when you use this attack.
- At last, there's the animation. It has a number of frames, and as many sprites as the number of frames.
That's how I see the thing. What do you think of it ?
937
« on: September 15, 2013, 07:57:50 am »
 I'd be so using it if only I had space for it Also, it's possible and even easy to compile Axe programs externally, see API.inc or w/e in Axe's directory
938
« on: September 15, 2013, 01:45:44 am »
@Xeda112358 yep, totally agree. @Roboman if we can't keep it at 6 MHz, I won't be able to play it with my sole TI-83+ BE, so I'll just stop working on it. Also, here's the promised screenshot Even if we don't see much things happen, everything on-screen has been generated by an algorithm (excepting sprites of course) :  The current call to BeginBattle is : BeginBattle(Data(4,0,1,2,3),Data(2,3,2),Data(3,0,2,1,1000r))
939
« on: September 14, 2013, 06:51:03 pm »
@willrandship putting Return!If Full at the beginning of a program is not called optimizing. It's called being lazy. @StreetWalker thanks ^^ and for tilemaps, remember that there will also be regular sprites and other things ; but you'll have to ask Xeda for that rather than me. Also, I got a skeleton of battle engine done. For now, it's able to : - Display the battle scene on a 4*4 isometric 3D grid (no textures yet, 16*16 blocks)
- Place correctly the party members and enemies on the corresponding blocks of the map, depending on the number of characters involved in the battle
- Display participants using dynamic sprites
- Display with text the name of items and the amount of money that the player obtained by beating all opponents (pressing [clear] is the only way to beat all opponents atm )
The whole engine is packed into a single function that takes 3 arguments. For example, here's the command I use atm : BeginBattle(Data(4,0,1,2,3),Data(2,3,2),Data(3,0,2,1,1000r))What does it do : it tells the engine to start a battle which will involve 4 party members (0 to 3), 2 enemies (3 and 2) and that winning the battle will give the player 3 items (1, 3 and 2) and 1000 dollars/coins/insert_some_name_for_money_here. I'll post a screenshot ASAP so you'll see it in action
940
« on: September 14, 2013, 05:41:04 pm »
I will never work on a game I won't be able to play. And since "OmniRPG" means that it's the game by pretty much THE TI community, it'd be stupid to say to some members "well, we don't feel like trying to optimise, so go find another game".
941
« on: September 14, 2013, 04:56:55 pm »
You don't seem to understand. It's the same buffer that is used, but it's used in different ways. And since each way requires a specific routines set, we'll have to go for only one style to save space.
942
« on: September 14, 2013, 03:41:09 pm »
Again, think about 83+ BE users (like me). I currently have about 23KB of free flash, although I have no other app than Axe and Mimas (and IkarugaX + source, the total being around 35KB. That's why I'm currently finishing it in high-speed mode before starting anything else to free flash).
Vertically-aligned buffers allow for faster drawing, but I guess TI didn't use them because what you see on-screen doesn't correspond to how memory is arranged.
943
« on: September 14, 2013, 12:13:31 pm »
So the best solution would be to build an axiom with a vertically-aligned version of Axe's graphical routines, and use this axiom instead of all Axe's functions. Also, direct plotSScreen access will need to be done differently.
944
« on: September 14, 2013, 11:44:55 am »
It's the case, battles have their own terrain, but then since it permits the use of horizontal buffers, we'll use Axe's graphical commands and the tilemap will use yours, so the final program will include two versions of the same routine, one for each buffer alignment, which is a huge waste of space.
Thus, we need to choose one buffer alignment that will be used for the whole game, else we'll end up wasting hundreds of bytes writing routines to handle both alignments.
945
« on: September 14, 2013, 11:11:03 am »
Using two sets of routines doing the same thing with differently aligned buffers is a huge waste of space. You'll have either to make your tilemapper work with horizontal buffers and use Axe's graphical routines, or replace all Axe's graphical routines by yours with an axiom and all the project will only use your axiom to work with vertical buffers.
Pages: 1 ... 61 62 [63] 64 65 ... 133
|
Show Posts
