Hmm, looks nice. Gray seems a bit flickery though, is it better on calc? Are you redrawing the tilemap every frame?This is a 6Mhz screenie. The game will be faster, so the grayscale will be looking smoother.
That looks very nice! how large will this be? because you may have to use BASIC to cirucmvent the 8kb limit. unless you're going to make this an APP? either way, it looks cool so far. ;)At the moment my sprite/map data and my code are compiled into one ion program,
I think I can store so much codebut Axe APPs have a 16kb code limit, due to Axe not being able to write to two pages yet.
as I want, since I saw that Desolate can hold 22KB
The 8811 byte (I think?) limit is only for executable code, but you can put as much data as you can fit into a program. The 8kb limit applies to all programs, although nostub programs can't have more that about 8192 bytes of executable code.That looks very nice! how large will this be? because you may have to use BASIC to cirucmvent the 8kb limit. unless you're going to make this an APP? either way, it looks cool so far. ;)At the moment my sprite/map data and my code are compiled into one ion program,
but I will have to shift the data into external appvars / progs later.
So there will be the code in an ion prog with a size of ~16KB (I think I can store so much code
as I want, since I saw that Desolate can hold 22KB) and 1 or 2 files with my sprites, maps and character
data (the character data is changable and I have to put this data into the main file if I cant modify ROM files).
The 8811 byte (I think?) limit is only for executable code, but you can put as much data as you can fit into a program. The 8kb limit applies to all programs, although nostub programs can't have more that about 8192 bytes of executable code.Am I really just able to use <8Kb Code in my prog? Then I wonder how Desolate works.
Do you mean The 8811 byte (I think?) limit is only for Source code instead of "The 8811 byte (I think?) limit is only for executable code"? or am I missing something?The 8811 byte (I think?) limit is only for executable code, but you can put as much data as you can fit into a program. The 8kb limit applies to all programs, although nostub programs can't have more that about 8192 bytes of executable code.That looks very nice! how large will this be? because you may have to use BASIC to cirucmvent the 8kb limit. unless you're going to make this an APP? either way, it looks cool so far. ;)At the moment my sprite/map data and my code are compiled into one ion program,
but I will have to shift the data into external appvars / progs later.
So there will be the code in an ion prog with a size of ~16KB (I think I can store so much code
as I want, since I saw that Desolate can hold 22KB) and 1 or 2 files with my sprites, maps and character
data (the character data is changable and I have to put this data into the main file if I cant modify ROM files).
Desolate isn't in Axe. Also, when he says <8kb, he means the Source code, otherwise you get a memory error. but if you compile into an App, your limit is 16kb. You can also use BASIC programs to link them together and XCOPY to Archive/Unarchive stuff though. I think that's how FinaleTI is circumventing the limit with Poemon TI.The executable code, as in the actual programming can't exceed 8kb, but with data the program could theoretically be as large as 24kb. The 8kb code limit applies to any Axe or Asm program. A lot of Mirage or Ion programs have all their data in the program, making them the 20-22kb programs you see, although their executable code doesn't exceed the 8kb limit. Nostub programs can be the same way, but for some reason (on TI's part) they can't be bigger than 8192 or so bytes to be run from the homescreen. That 8192 bytes is the entire program size, including data. I believe running one from a shell gets around this issue, but they still can't have more than 8kb of executable code, and their max amount of executable code is a couple hundred bytes less than the executable code limit in a Mirage, Ion or DCS program. Apps can have up to 16kb on one page, data and code. Since Axe only supports single page apps right now, any app made with Axe can only be up to 16kb total size. One way to circumvent the code limit, as yunhua said, is to use a basic program as your main program and have it launch Asm programs (nostub, of course, as they can be run from the homescreen and basic programs without any external libs.
EDIT:Do you mean The 8811 byte (I think?) limit is only for Source code instead of "The 8811 byte (I think?) limit is only for executable code"? or am I missing something?The 8811 byte (I think?) limit is only for executable code, but you can put as much data as you can fit into a program. The 8kb limit applies to all programs, although nostub programs can't have more that about 8192 bytes of executable code.That looks very nice! how large will this be? because you may have to use BASIC to cirucmvent the 8kb limit. unless you're going to make this an APP? either way, it looks cool so far. ;)At the moment my sprite/map data and my code are compiled into one ion program,
but I will have to shift the data into external appvars / progs later.
So there will be the code in an ion prog with a size of ~16KB (I think I can store so much code
as I want, since I saw that Desolate can hold 22KB) and 1 or 2 files with my sprites, maps and character
data (the character data is changable and I have to put this data into the main file if I cant modify ROM files).
EDIT: eh? where did Finale's post go?
ok, that makes more sense, I guess I wasn't compltely reight. :PI can feel the power rising.... >:D
btw, FinaleTI: your close to 666. :o
Hmm, looks nice. Gray seems a bit flickery though, is it better on calc? Are you redrawing the tilemap every frame?This is a 6Mhz screenie. The game will be faster, so the grayscale will be looking smoother.
And yes, for now I refresh the screen every frame.
I tried to compile my code as an app, but there is a strange bug.
I can execute the app just one time, then the program exits by itself after a frame.
Screen and Source attached.
(http://img294.imageshack.us/img294/4766/xevappbug.gif)
It works since I added 0→A→B→C→D→E→F→G... ,thanks. :>I tried to compile my code as an app, but there is a strange bug.
I can execute the app just one time, then the program exits by itself after a frame.
Screen and Source attached.
(http://img294.imageshack.us/img294/4766/xevappbug.gif)
Make sure you aren't writing data to any static pointers like GDBXXX, PicXXX, or StrXXX. And make sure at the beginning of the program, you initialize all your variables--that could be why it quits after the first run.
Yeah I agree. The only issue is that he will have no choice for when there is scrolling (although I think he can just scroll the screen 16 pixels then draw the missing column/row of sprites, but I'm not sure if that's any faster).Hmm, looks nice. Gray seems a bit flickery though, is it better on calc? Are you redrawing the tilemap every frame?This is a 6Mhz screenie. The game will be faster, so the grayscale will be looking smoother.
And yes, for now I refresh the screen every frame.
I suggest you don't do that every frame. In RandC, I only refresh the screen after something happens (a cursor move, message, etc.) and I have found it results in absolutely perfect grayscale ')
Character Structure
+000 - Level
+001 - Experience
+002 - Experience Max
+003 - Status ( 0 = Not avaible/dead; 1 = In the base; 2 = On the map; 3 = Able to move)
+004 - Position X
+005 - Position Y
+006 - HP
+007 - HP Max
+008 - Item 1 Number
+009 - Item 1 Property
+010 - Item 2 Number
+011 - Item 2 Property
+012 - Item 3 Number
+013 - Item 3 Property
+014 - Item 4 Number
+015 - Item 4 Property
+016 - Item 5 Number
+017 - Item 5 Property
+018 - Current Weapon
+019 - Nimbleness (How far he can walk per round)
+020 - Class
+021 - ATK
+022 - M ATK
+023 - DEF
+024 - M DEF
+025 - Speed
+026 - Weapon 1 Class
+027 - Weapon 1 Rank
+028 - Weapon 1 Exp
+029 - Weapon 2 Class
+030 - Weapon 2 Rank
+031 - Weapon 2 Exp
+032 - Change Counter (For Laguz')
+033 - Change Counter Max
+034 - Change - When he is transforming
+035 - Poisoned
+036 - Sleeping
+037 - Tile Link
+038 - Weight
Nice :DI have not done so yet.
ANy luck fixing the slow grayscale by the way?
Also, I read some stuff about Fire Emblem and planned a lot.
Here is the current character structure. It would be nice, if you suggest additional properties.Spoiler For Spoiler:
Also, I read some stuff about Fire Emblem and planned a lot.
Here is the current character structure. It would be nice, if you suggest additional properties.Spoiler For Spoiler:
Wow, that's a lot of properties to record. Is this going to be an app? If it isn't, I can't see how you'll stay under the 8kb limit if you're using If: statements to register the properties.
It's looking great though.
Lookin' great Aichi.The virtual camera and the characters position changes. The character that you can see on the screenie
Will the main character move around the map or will he remain in the center of the screen while the map moves underneath him (like in Ultima V (http://tifreakware.ath.cx/index.php?showtopic=322))?
Fire Emblem is kinda like Final Fantasy Tactic, right?Yes, it is very similar.
I voted other:I second that. That's the best idea IMO. Nice work BTW, keep up the good work!
I say he should disappear UNTIL you pay to have him revived. That way, he's not gone for good, but you have to work to get him back.
I voted other:This idea is pretty fantastic. Thank you. :)
I say he should disappear UNTIL you pay to have him revived. That way, he's not gone for good, but you have to work to get him back.
Also: Aichi, I love your progress so far in this game! Great job so far!!
Fire Emblem is kinda like Final Fantasy Tactic, right?
Lookin' great Aichi.The virtual camera and the characters position changes. The character that you can see on the screenie
Will the main character move around the map or will he remain in the center of the screen while the map moves underneath him (like in Ultima V (http://tifreakware.ath.cx/index.php?showtopic=322))?
is one of much characters that you control at the same time, so you cant control a character with the arrow keys, but you control a cursor with it. You can move the coursor around the map and point on characters to do something with this character.
Do you know Fire Emblem? You find a gameplay video in my signature.
I say he should disappear UNTIL you pay to have him revived. That way, he's not gone for good, but you have to work to get him back.I voted other for this too. :)
.English
Data(Str1-40343, Str2-40343, Str3-40343)
"Wayne: Aichi, did you found a solution for the pointer issue?"->Str1
"Aichi: No, it seems to be impossible at the moment."->Str2
"Wayne: Oh, bad News. The Game."->Str3.German
Data(Str1-40343, Str2-40343, Str3-40343)
"Wayne: Aichi, hast du eine Lösung zu deinem Pointer Problem gefunden?"->Str1
"Aichi: Nein, es scheint im Moment nicht möglich zu sein."->Str2
"Wayne: Oh, das sind schlechte Neuigkeiten. The Game."->Str3Then I just would have to use the data start pointer and add the value of bytes being in the data of the first line..Main
ClrHome
Getcalc("prgmENGLISH",Y1)
Getcalc("prgmGERMAN",Y2)
.Output what Aichi says on German
1->X .The second text, Str2
Output(0,0,Y2+{2*X+Y2}) .Pointer to the file + a value stored in this file to reach Str2
Repeat getkey=15
End
ClrHome
Sorry I can't help but this is the thing I like most about axe, we can now finally make neat data files and select when transferring only those that we need! This is great for a game that is designed for multiple languages!Im thinking Axe adds 40343 ($9D95+2) to the pointers, cause this should be the place where
Why the -40343? is that an appvar size limit or something?
.Axe 40351
Pxl-On(0.0 40355
9->A 40357
"123"->Str1 40362This is what i think he is doing. He has an appvar full of data, and since this data sets are random length, you can't know where one starts and another ends. How to fix this? Well if we have 10 sets of data, we can have 10 numbers at the begining of the appvar. The first number will say "The first data set is X bytes from the begining of this appavar" and so on.
When you store text into a pointer in Axe, the pointer holds the location of the text. So after "1234"->Str1, Str1 holds the location of the String "1234". Well, programs in assembly (and axe) *always* start at the location 40341. So if Str1 is 10 bytes after the start of the program, it will be located at 40351. If we want to find out how far Str1 is from the start of the program, we just subtract the location of the string (40351) from the start of the program (40341), and we get 10 :)
Data(Str1-40341) in my code, before I use this command: "ABC"->Str1 But (unlike all pure asm compilers I know) Axe is not allowing to use pointers before these pointers are defined.
Cool, I checked the site. You should maybe put a link to this topic as well for people who want to discuss as well. :P (assuming you plan to share the website link with other people)This is what i think he is doing. He has an appvar full of data, and since this data sets are random length, you can't know where one starts and another ends. How to fix this? Well if we have 10 sets of data, we can have 10 numbers at the begining of the appvar. The first number will say "The first data set is X bytes from the begining of this appavar" and so on.
When you store text into a pointer in Axe, the pointer holds the location of the text. So after "1234"->Str1, Str1 holds the location of the String "1234". Well, programs in assembly (and axe) *always* start at the location 40341. So if Str1 is 10 bytes after the start of the program, it will be located at 40351. If we want to find out how far Str1 is from the start of the program, we just subtract the location of the string (40351) from the start of the program (40341), and we get 10 :)
Yeah, this is exactly what my plan is. :)
The major problem is following:
Axe dont allow that I have thisCode: [Select]Data(Str1-40341)in my code, before I use this command:Code: [Select]"ABC"->Str1But (unlike all pure asm compilers I know) Axe is not allowing to use pointers before these pointers are defined.
I could put the Data( with all pointers into the last line and update the pointer to this Data( in the main code always when I change something in the language pack, but this wouldnt be efficient developing, huh?
So, the best solution for the problem would be that Quigibo let the compiler search for Str1 in the whole code, when Str1 is used before it is defined. While it isn't able to use the Data( in the first line, I have no other choice but I must put the Data( into the last line.
However, website update: http://xeverion.net.tc/ Added basic infos and the recent screenshot.
Nice, didn't notice a website there :P Looks good so far!The webhoster I use is pretty great, free and without ads, but just avaible in german I think.
What host are you using? Is it FREE? if so, Pyyrix and RandC might get their own websites :)
/me wonders if there were any more work on this since last update
/me wonders if there were any more work on this since last update
Some planned stuff, but not much, though.
The code will be too extensive to be in a singlepaged app.
A thing to solve this issue were splitting the code into
some subprograms and call them by Hybrid BASIC, but I don't
like this method, since the result would be altogether 7-8 files.
Also, I'm designing the code using many subroutines to call data and
optimaze things, so every of these subprograms had to contain the same routines.
Anyway, this would be the best solution that is currently avaible.
I rather wait for the avaibility of compiling code into multipaged applications.
I don't know whether Quigibo will be able to include such a feature.
Else I'll wait for the next programming language he metioned to create maybe here (http://ourl.ca/7665).
I'm still planning some stuff I mention on my Xeverion website.
Otherwise, I'm creating stuff with Blender (The website background for example)
and I thought about making Super Smash Bros. / Little Fighter II for TI.
Well, you could keep it all Axe by creating all the programs you need, then copying their code to appvars. Then, when you ran the program/app and needed one of those programs, you could create a temp program and copy the code from the necessary appvar and run the newly created program with some Hex ASM./me wonders if there were any more work on this since last update
Some planned stuff, but not much, though.
The code will be too extensive to be in a singlepaged app.
A thing to solve this issue were splitting the code into
some subprograms and call them by Hybrid BASIC, but I don't
like this method, since the result would be altogether 7-8 files.
Also, I'm designing the code using many subroutines to call data and
optimaze things, so every of these subprograms had to contain the same routines.
Anyway, this would be the best solution that is currently avaible.
I rather wait for the avaibility of compiling code into multipaged applications.
I don't know whether Quigibo will be able to include such a feature.
Else I'll wait for the next programming language he metioned to create maybe here (http://ourl.ca/7665).
I'm still planning some stuff I mention on my Xeverion website.
Otherwise, I'm creating stuff with Blender (The website background for example)
and I thought about making Super Smash Bros. / Little Fighter II for TI.
Well, you could keep it all Axe by creating all the programs you need, then copying their code to appvars. Then, when you ran the program/app and needed one of those programs, you could create a temp program and copy the code from the necessary appvar and run the newly created program with some Hex ASM.I don't really want to implement somehting like this.
or wait till the prizm with a C sdk and make add ins up to 1 MB each O.o and 16 bit colorzI rather wait for the second one, since I want to stay with TI83+/84+/SE. :)
...or wait till axe supports multipage apps.
Why is multiple sub-programs such a major issue Aichi? It's not like it will make the game any worse. People will still play it anyway. I don't get why people hate them so much, especially that you still end up with multiple files even when using APPS because of the appvars. I feel this is extremly narrow-minded
Why restrict yourself so much just because it would be in multiple sub-programs? Sorry but this frustrates me so much. I don't get why you would kill the project by absolutely wanting multiple page apps. Plus I wish you good luck dealing with multiple pages anyway because ASM programmers told me it was a major hassle to switch between them.
Multiple pages APPS for Axe are NEVER going to happen. If it does, it will be in 2013 or 2014. Quigibo is too busy with university to deal with this now. So you are gonna abandon Xeverion just because you are too narrow-minded to just use multiple sub-programs instead?
Yeah I think he did not want multiple appvars either, though. But then, even with an app, he still ends up with them.DJ, it might be possible, but you wouldn't be able to unarchive them :P
If Axe ever was gonna have multiple app page support, then Aichi would be in for even more trouble, because apparently switching between pages is a major PITA. You would need to ask Iambian to confirm, though.
On a side note is it possible to create appvars directly in the archive and have them be larger than 24 KB?
Yeah I think he did not want multiple appvars either, though. But then, even with an app, he still ends up with them.DJ, it might be possible, but you wouldn't be able to unarchive them :P
If Axe ever was gonna have multiple app page support, then Aichi would be in for even more trouble, because apparently switching between pages is a major PITA. You would need to ask Iambian to confirm, though.
On a side note is it possible to create appvars directly in the archive and have them be larger than 24 KB?
On a more serious note, they would still be usable. I think it is in fact possible; I remember statements that there are bcalls that allow the creation of appvars directly in the archive.
Well I wondered since it's possible in Axe to read stuff from archive. I am unsure how far it can read in an appvar, though...Yeah I think he did not want multiple appvars either, though. But then, even with an app, he still ends up with them.DJ, it might be possible, but you wouldn't be able to unarchive them :P
If Axe ever was gonna have multiple app page support, then Aichi would be in for even more trouble, because apparently switching between pages is a major PITA. You would need to ask Iambian to confirm, though.
On a side note is it possible to create appvars directly in the archive and have them be larger than 24 KB?
On a more serious note, they would still be usable. I think it is in fact possible; I remember statements that there are bcalls that allow the creation of appvars directly in the archive.
Ah ok because it seemed like you were insisting so much on not using sub-programs because it was apparently an extremly bad thing. It seemed like you were ready to kill this project if you were gonna be forced to use them. That said I guess with multiple sub-programs it's indeed harder to use sub-routines in all of them. I think it's no hope to wait for multipage support, though, because just seeing Axe progress rate lately mulltiple app support is just not gonna happen anytime soon. It's not Quigibo fault, but rather life fault that makes university so demanding.Why is multiple sub-programs such a major issue Aichi? It's not like it will make the game any worse. People will still play it anyway. I don't get why people hate them so much, especially that you still end up with multiple files even when using APPS because of the appvars. I feel this is extremly narrow-minded
Why restrict yourself so much just because it would be in multiple sub-programs? Sorry but this frustrates me so much. I don't get why you would kill the project by absolutely wanting multiple page apps. Plus I wish you good luck dealing with multiple pages anyway because ASM programmers told me it was a major hassle to switch between them.
Multiple pages APPS for Axe are NEVER going to happen. If it does, it will be in 2013 or 2014. Quigibo is too busy with university to deal with this now. So you are gonna abandon Xeverion just because you are too narrow-minded to just use multiple sub-programs instead?
Wow, sorry. I didn't know how wrong I am when I thought multipaged apps had no disadvantages and it was no problem for Quigibo to implement such an oncalc compiler.
I don't hate subprograms and I'm wondering where I said games using subprograms are bad.
I just thought that using an applications would be better for my project, espacially because I designed my code as a network of sublabels. Using different programs needed many equal sublabels (for example needs every sublabel the axe parser drawing routine and about 40 character structure sublabels), what provides kinda ineffiecient results.
Ok, I will forget my stupid idea and perhaps split the game into programs.
Also, I'll be more cautious with posting things and listen to people who has more experience than me.
Any luck with this Aichi, btw? Or are you mostly brainstorming for more ideas?