Omnimaga
Omnimaga => Completed => Our Projects => Grammer => Topic started by: Xeda112358 on December 29, 2011, 07:48:58 pm
-
This is where y'all can drop your ideas and requests. I make no promises, but it is good to have everything in one place, right? So the first request was by yeong and that was to have a way to incorporate BASIC and Grammer together with Grammer 2 (it was possible in the first Grammer). So here is a program that should make that possible. Just start a line with .0:Asm(prgmGRAMMER and the code up until a Stop will be run as Grammer code. At the Stop, the code will be read as BASIC. You can do this as often as you like in a program, too :) Lemme know if it doesn't work .__.
-
:D
Now I can bomb her with feature requests. >:D
1. Better sound routine (you can do this later)(I just saw the conj(' ' command )
2. "Augmenting" the data that are in the labels. For an example, when .M have 2 data, (Like, 12), I can't augment the 3rd byte in.
3. Maybe access to hacked strings/pictures if it's not already possible
-
For number 2, you can do that if it is in RAM, but any labels that come after that will need to be recalibrated.
For number 3, if you have a token for it, that is already possible, but I am thinking I can add in the RecallPic and StoPic commands that access all 256 pictures and maybe a solve( command to play with strings and GDBs and whatnot.
-
Feature request: if rectangles are drawn half outside the screen and half inside then there is still the half drawn thats inside.
-
Ironically, I have that half working :P It will work if it goes off the right side and bottom portion of the screen. I will see what I can do...
-
Okay, in response to sorunome, here is an update with full rectangle clipping:
Grammer.8xk (http://www.omnimaga.org/index.php?action=dlattach;topic=10961.0;attach=10980)
(http://www.omnimaga.org/index.php?action=dlattach;topic=10961.0;attach=10979;image)
-
Feature request:
Can you modify solve(0 command so I can put the size I want to copy in optional 3rd argument? :D
-
Okay, I like that idea very much and I just added it as well as an optional fourth argument for an offset into the var.
So for example, if I wanted to copy the first 128 bytes of prgmHELLO to the temp program Hi2, I could do something like this:
solve(0,"EHELLO","VHi2",128
Or if I wanted to copy 128 bytes at an offset of 4 bytes into the var:
solve(0,"EHELLO","VHi2",128,4
-
Yes! Thank you so much XD
-
Very cool feature addition! =)
-
Thanks to yeong for the idea! And I am still working on these other feature requests when I can find the inspiration:
Smoothscrolling
Var11~255 Access
RecallPic
StorePic
Sprite clipping
-
Hmm, so now I have a question because I am feature requesting 2 more sprite options for Pt-On(:
Masked sprites
Gray sprites
The question is, should I have an extra argument for the pointer to the mask or should I have the mask built in to the data? And if the latter is the case, it would be faster and easier to use every other byte as the mask.
So what should I use? If I do the latter option, I can easily make a sprite editor to handle those two types and then you can use grayscale options for tilemapping :D
-
Triple post .__.
Okay, so at Sorunomes request, I finally added in a way to tell which version you have and I added an option to enable the token hook. I even have some future options that you can see but not use (they will let you view different vars). At the moment, you can only toggle the hook ON by pressing F5. Hopefully I will add the ability to restore the hook setting by pressing F5. This way, if you use Axe token hooks (or other token hooks), you can go back and revert to Axe tokens.
EDIT: In relation to the poll, here (http://ourl.ca/14754) is what the text compression routine looks like that I would implement.
-
Request:
When I use [ command, the only option I can think of typing 2-bytes number is this:
C[ㅠFF,ㅠ01 //This will store ㅠ01FF into C
with little-endian format D:
can you add a easy way to do so?
-
Do you mean using iPart(C,ㅠ01FF? Otherwise, I can add [[ for two-byte values and [( for just straight hex.
-
iPart is only good for storing few datas. The code gets ugly once I start to type something like this...
C[0,1,3,ㅠFF,ㅠ01,4,2,ㅠEE,ㅠ78,3,1,.....
-
Okay, two things:
1) Thanks for voting on the poll! It so far looks mixed. I plan in any event to add text compression to Grammer 3 :)
2) I have a few new updates based on this thread-- I added yeong's request (including a request via IRC) and I added in more variable support (such as Str133, GDB67, et cetera). On top of that, I added support for storing Grammer strings to OS strings.
See EDIT2 on this (http://ourl.ca/13558/279192) post for details and the download is on that post, too :)
-
I think text compression is a great idea. It'll help out for projects that have large chunks of text. What about compressing graphical data? :D
-
That could be tough and it depends .__. The text compressor only works with 46 chars and works using some stats on the most common appearances of letters. Of course, making a general routine that scans any data would probably be neat, too :)
-
Ah, ok. Also, didn't realize the compressor was for short texts ( I probably overlooked it) x.x. And yea, a general routine would be sweet. :D
-
Oh, I meant only 46 chars can be used. The text can be any size (as long as it and its compressed form fit in RAM).
The characters include punctuation, uppercase letters, numbers, and a few other chars.
-
can you add a "Line Jumping" feature?
like if you put ln(+3, it jumps to 3 lines after (maybe line must be defined by newline token) and ln(-3 jumps back 3 lines and stuff.
It'll be cool. :D
-
Okay, wonderful idea and here is your update! As a note, ln(0 will jump forward 65536 lines. Here are some examples:
ln(3 ;jumps to the line with "Yeah!
"Hi
"Whaddup?
"Yeah! ;The code jumps here
Lbl "ScrollMenu→Z
prgmZ ;StartOfLoop
DispGraph
If getKey(15
ln(-3 ;jumps back to prgmZ
Again, thanks for the token idea, especially! I made a version for ReCode that used other tokens (and was conditional) and I have wanted to add it to Grammer as well, very much. Thanks! :thumbsup:
-
@Xeda: Ah ok, it's just a limited character set. :) That's fine then. =D
-
New token hook thingy looks great. :D
However, it kinda bothers me that I can't put "[" in the string anymore. D: (If I do, the code doesn't work properly D: )
Is there a way to disable the token hook at the string part?
-
I think in the next update, I will just remove the hook for { and [. And why can't you put a "[" in a string? It should still show up as [ when it is displayed...
-
I don't know what's happening, but it just doesn't work D:
It just quits Grammer X.x
-
Oh, jeez, nevermind, I know what it is .__. Here is the fix. I noticed it yesterday when I was making the flame animation and I fixed it and did not even think to upload the fix here. For ASM programmers, I originally needed an extra POP to exit the routine, but then I rearranged it to not need that, but I left the POP in.
-
Yet Another Feature Requests/Maybe Question
1)How do I copy picture to memory address? (I'm pretty sure it can be done with Fill( command but just making sure.)
2)I think I read something about 32 bit number stuff. Are you still planning to implement it?
-
EDIT: I blame chrome >.<
-
1)How do I copy picture to memory address? (I'm pretty sure it can be done with Fill( command but just making sure.)
2)I think I read something about 32 bit number stuff. Are you still planning to implement it?
1) You have a few options. If you have the data in RAM, you can use the Fill( commands. However, since that copies 768 bytes and the OS stores 756 bytes, you might want to do something like this:
solve(0,"GPic1","Vt→A
solve(1,A,pi9340,756 ;copies the 756 bytes to the graph screen.
2) Well, I do have some 32-bit stuff in the App, but not fully available in Grammer. However, there is support for multiplication, addition, and subtraction. For example, you can take advantage of Ɵ' in a lot of cases. I know in IRC you wanted to do 32-bit addition and subtraction for things like money in a game:
To perform GG'+B where G is the upper 16-bits and G' is the lower 16-bits:
G'+B→G'
G+Ɵ'
If Ɵ' ;this means 32-bits were exceeded D:
-1→G' ;This is negative 1, not minus 1
→G
And similarly for subtraction:
G'-B→G'
G--Ɵ' ;this is minus negative Ɵ'
If Ɵ' ;this means 32-bits were exceeded D:
0→G'
→G
-
one more request: able to display 32 bit numbers in decimal.
-
I can definitely do that, but what command should I use to signify a 32-bit number? (I might use it in other areas, too, such as 32-bit math)
EDIT:Rather, what token?
-
maybe u? (2nd+7)
and for reading 32-bit numbers from data, (( might be good. (Unless it's used, that is)
-
I can do that, I think. Is there any other better tokens to use?
-
This does not handle 32-bit inputs via math or numbers, but it will display 32-bit numbers by using two variables in a row. For example, if B was FF0Fh and B' was 7BACh, you can display FF0F7BAC by doing this:
Text('0,0,BB'
(that will display 4279204780 if my math is correct)
Because of how I coded this, Grammer actually stores intermediate values as 32-bit numbers (but the upper 16-bits are all zeroes). This means that I might need to modify the Fix command to allow for one more mode-- 32 bit mode.
EDIT: Luckily nobody downloaded before I found a bug that I forgot to fix... I forgot to change a byte in the For( command because I changed the routine for locating a variable. It is now fixed :)
-
Another feature added and also some minor fixes:
you can now use the exponential E ([2nd][,]) to prefix a binary result. This does return 32-bit values for text output and maybe for future use with 32-bit math.
-
so now E101 = 5? Great. :D
-
Yes, exactly :) I am trying to think of what else to add D:
-
what you could do is do base E number
so 3E99 means trinary 99.
-
Right now, the conversion from binary is pretty fast. Converting from an arbitrary base could be pretty slow, though :/ I mean, it is doable, but I would prefer to use some other token so that binary can be read fast.
-
After working on this (http://ourl.ca/15341) topic (and still failing), I have added a few useful functions. First, e^(n now performs 2^n (and the token hook changes this accordingly). This is a function that will likely remain as I have wished it was included for a while. The next thing I added was probably even more important and useful for many projects-- pixel testing boxes. This is especially useful for collision detection and I plan to add more versions at some point. The method I have added pixel-tests the border of the given rectangular region and returns the number of set pixels. (I plan to add methods for pixel-testing filled regions, as well)
It uses a modifier of pxl-Test( and similar arguments to Line(, so here is an example to check the perimeter of a pixel at (Y,X):
pxl-Test('X-1,Y-1,3,3,0 ;0 is the type (test the perimeter)
A value from 0 to 8 will be returned :) I am putting this in Feature Requests because I was wondering what folks thought and if they had similar suggestions before I release it. Also, I still have to work on it a bit more. It works for my purposes, but it still needs to handle screen boundaries better.
-
is there a way to display token as according number? (Like comma to 42[iirc] )
-
To display an ascii char, you do something like:
:Text(0,0,'43
To display a token using the hex value, you can do something complicated like this:
:pi8478→A[(2B00
:Text(0,0,A
-
Hmm. I don't remember reading about Text(coord,coord,'Stuff ... D:
I'll try it though. XD
-
Yeah, it was kind of sneaked in once when I made a bunch of updates :D I made an edit to the readme, but I don't think I ever let anybody know .__.
-
/me remembers "Full" incident. :D
-
So I've been messing around with the greyscale and whatnot.
My request is: can you add Tangent( into one of the greyscale-enable command?
-
Question what GS levels does Grammer support? Is it like Axe where you can use 3 or 4?
-
@DJ_O: D: I thought I already posted a response to this, sorry. It must have been a bad internet connection at the time :(
Currently, only 3-level gray is supported, but I would like to add 4-level in the future, as well.
-
Ah ok thanks for the info. :) ALso nice update in the other topic :D
-
persalteas gave a great idea to add the ability to use Omnicalc fonts. I've been looking for an idea for the fourth font option and I think this is the best one :) This also means that it will work with BatLib fonts, too :) As a note, you must use an offset of 11 for Omnicalc fonts (they have extra data at the beginning). So for example, I have an Omnicalc font called prgmBOLD:
Output(3,11+Get("EBOLD
And now Omniacalc fonts can be used in your Grammer programs :) This is very helpful since there are tons of Omnicalc fonts available :)
-
Aha ! nice ! =)
the advantage of Omnicalc fonts is that they can create small sprites easy to use. (by sacrificing one character.)
Good job.
-
Okay, so I am adding in some custom particle effects, but I need input on how I should have the ruleset stored. Should I do it as a number or like this:
P>Ry(3,"D,LR
That will make it try to go down first, then if it can't, it will try left or right. Currently, I have it number input like this:
P>Ry(3,5632
In binary, 5632=0001 0110 0000 0000. I would like to know if I should reverse this so numbers are smaller? For example, 0110 0001 which is 97?
Also, the particle engine is faster ^_^
EDIT: Ended up doing both :)
-
I wonder if you plan to add support for numbers up to 60,643,687,620? :trollface:
For example if members decided to port one of my old RPGs to Grammer, there are certain with elemental magic properties that can reach that high in amount of damage caused to the enemy (before being brought back to 9999) :P
For example, in Illusiat 11, there is a boss that takes 250 times more damage vs any elemental magic, so if you use the tri-elemental magic which multiplies all 3 elemental defense/weaknesses together, this means the boss takes 15,625,000 times more damage than normal vs that spell. :P
-
In the plans for a future Grammer, I did plan to support arbitrary sized numbers, since the OS version is planned to replace the current TI-OS, even in math. However, I don't think Grammer 2 will support that natively (though I made a program in Grammer code that could handle large numbers like that).
-
Ah ok I was asking since Yeong is porting Illusiat 11 to Grammer (http://ourl.ca/18029/331833;topicseen#new) for the Cemetech contest (which ends in 3 weeks), but due to the way damage formulas are done in the game, the number range supported by grammer was nowhere close to prevent glitches from occuring in the port if the character happened to fight very weak monsters at high level, especially the tri-elemental magic spell.
Also I think he ran into a bug with 32 bit numbers causing them to not be fully supported, as in above 2 or 4 millions or something, they glitched out.
-
Well xeda said the maths are not yet done so XP
Also why won't recallpic work?
-
I have no clue why it isn't working for you, it works fine for me. Well, actually, I have an idea... What is your code, precisely, and what picture are you trying to recall?
-
Well I did RecallPic 9 and tried to load os var pic9
-
To load OS var Pic9, you need to do RecallPic 8 :P Remember:
0=Pic1, 1=Pic2, 2=Pic3, 3=Pic4,...,Pic0=9
TI names them weird (internally, they start at 0, but to the end user, they display starting at 1).
-
oh. so Grammer version starts with 0, then. XD
I probably need an updated readme file.
-
Btw Yeong I don't think you're allowed to get any help for Illusiat if that's what you're asking above :P
3) No private help from others. No code help from others. Feedback on screenshots and ideas may be requested (only) in the entry's official Cemetech topic, but keep in mind that we will be grading you on your originality.
Of course reporting Grammer bugs is fine, although you have to be careful to not report plenty of false positive since people might inaverdently help you.
I think I have read somewhere that it might be tolerated if done directly in your Cemetech topic, but you might have to make sure first. Just making sure you don't get in trouble.
-
Well basically all I asked for was the correct syntax of recallpic so I should be fine.
-
Feature request: any other methods other than overwriting with RecallPic.
Also can grammer writr text on backbuffer?
-
Sorry for double posting but my phone won't let me. :P
It seems like grammer goto/prgm doesn't work inside conditionals.
-
I think we covered a few of these on IRC, but for everybody else:
If Uses everything on the line, regardless of what the token is, even if it is a colon. Colons will separate commands, but does not work exactly like a newline. This allows more complicated math formulas in the conditional.
To draw Text( on another buffer, you will need to make that buffer the main buffer. To set it back to the main buffer afterwards, use Disp pi9340.
Recallpic has the following syntax: RecallPic #[,Method[,Buffer
So to use a different type of logic, change Method:
0=Overwrite
1=AND
2=XOR
3=OR
5=Erase
-
Ah. Stuffs like recallpic syntax is not on the readme I have Xp
Can I haz a newest readme?
-
This has the most up-to-date released readme, I believe.
Grammer 2 (http://ourl.ca/15327/299276)
-
Can you make an "Else" command ?
-
I have very little coding space, but I might be able to add that. It is definitely a good idea.
-
Thank you ;D
-
Feature suggestion (in longer terms): TI-84 Plus C Silver Edition compatibility. :P
-
My plan for an 84+C version is to maintain backwards compatibility. This way programs can be identical and work the same. The main difference will be color and how big pixels are.
-
Ok cool to hear. :D From what I gather, unless the new calc is not even a Z80 and lacks Z80 emulation at all, it should just be a matter of address changes like the TI-83 to 83 Plus and different screen, so the non-screen parts of Grammer might not be too hard to port. Of course that might be problematic if you still code everything on-calc and don't buy a new calc, though.
-
That is awesome to hear!
At least some language will be available on the 84pcse/me glares at axe
-
Yeah, I will need to rewrite the graphics commands, but so long as it can run z80 code, the rest shouldn't be tough to convert.
-
Why not making a compiler that compiles only a part of the code from a label in the source to another. I believe it'd be awesome and maybe faster!
-
I am not exactly sure of what you mean, sorry :/ Grammer 2 doesn't compile anything, so I am not sure where that would help out at the moment (but compiling is in the plans for Grammer 3). However, there are tricks for working with labels to make them faster, such as precomputing their location and storing them to point variables. This way, you don't need to constantly look up labels.
-
Sorry, I meant making a way to pre-interpret a part of the code (like loading a part of the code interpreted in a temporary programm).
I think it would have to be done while lauching the programm.
With ".Token" as your way to locate what I call the Label, the structure may look like that:
.0:"name"
;Your code
.Token ;It has to compile from the beginnig and until it reaches this point.
;another code
.Token ;It has to compile from the last token and until it reaches this point.
[...]
; End of the code.
I think this would improve the speed (comparing to interpreting) of the programms and use less of memory than compiling.
Sorry for my English, I'm a French student :-[
-
Sorry for interrupting the conversation (Soulthym ? Un étudiant français qui fait du Grammer ? Serions-nous deux ? :o ), but I have an idea...
I saw what you have done with your app 'Tutor' Xeda, and I thought it could be very useful in Grammer.
I explain:
Imagine the user sets a list of keycodes that would be automatically pressed the next time the calculator will be waiting for a signal from the keyboard, we could make:
- pre-recorded answers to Inputs
- cheatcodes in games to control automatically the player/object-to-move
- We could use this to allow the player to make tiny macros in a game, without modifying the source code
In the same way, but much less useful because it can be easily done yet with getkey, create a function that records what key are pressed to make an history.
With this two functions, the user could record a manipulation and re-do it many times automatically.
-
Okay, I think I see what you mean, soulthym. I don't have much code space left in the app for something that complicate.
EDIT: I accidentally clicked 'post' before finishing :P
@persalteas: Unfortunately, the OS doesn't parse key hooks during program execution unless you are at an 'Input ' command, Pause, or Menu(
-
No matter, maybe I'll be working on that during holydays^^(is it possible to have the grammer source in asm?)
Edit:Maybe it could be implemented in an alternative version of Grammer 3(like Grammer 3 precompiling version)
-
I could probably make an alternate, unofficial version. It would probably have features removed, though, o make room.
The source is typically included with the download, but here is the current code that I have (attached). I am not sure if it works because it has been a while since I last looked at it.
-
Thank you a lot!
Edit: I just thought: Why not including plugins( like mimas does for example)?
-
I just thought: Why not including plugins( like mimas does for example)?
Sorry, I did not see this for a while. I was thinking of doing that, but I thought it would be too difficult. It would be really easy if the plugin was an app.
-
@persalteas : et moi, je compte peut-être pour du beurre ? Certes, je n'ai absolument rien fait et ne connais ce langage que très partiellement... Mais je soutiens totalement le projet et développerai peut-être des trucs lorsque j'en aurai le temps !
@Xeda:
When we call a label, it needs time to find it. We can put the address in a variable, but it needs memory and a new name for each label. So why not add a new type of label being automatically parsed at the start of the program so that the application doesn't have anymore to parse it each time it is called ? For example, such a label could be declared as :
..LABEL
And when we do "call LABEL" or "Goto LABEL", the address will be stored for all the program execution.
PS : why not include to your .zip persalteas' tutorial ?
-
@Xeda:
When we call a label, it needs time to find it. We can put the address in a variable, but it needs memory and a new name for each label. So why not add a new type of label being automatically parsed at the start of the program so that the application doesn't have anymore to parse it each time it is called ? For example, such a label could be declared as :
..LABEL
And when we do "call LABEL" or "Goto LABEL", the address will be stored for all the program execution.
Hehe, that is something that I am already working on (I even have had code for almost a 10 months in Grammer for this).
PS : why not include to your .zip persalteas' tutorial ?
I include a link to it in the readme, but I should remember to put the actual PDF in there.
-
Hehe, that is something that I am already working on (I even have had code for almost a 10 months in Grammer for this).
Ans why not do so that this function is enabled for "." and disabled for ".." instead ? Labels which location doesn't have to be stored are rare and are used only when there's lots of SMC.
-
Well, the code currently replaces the data with data not usable in the TI-BASIC editor (which is why I haven't officially added it). Otherwise, all labels would get replaced :)
-
Necro-post since this is the appropriate location:
I was thinking it might be neat to be able to execute Grammer programs that are stored in Groups. I'm not sure that it would be useful, though.
Some other features that might be cool:
- Viewing and creating DoorsCS-style folders in Grammer's main menu.
- Archiving/Unarchiving from the main menu.
- Add some useful settings like pretty much all other shells have (enable lowercase, for example).
- Add a simple source viewer in the main menu (not an editor, just something to preview a file).
These aren't ideas that are really necessary, so I might not even add them. Or maybe I need a way to add "hooks" for the main menu so that people can download extensions?
I'd love some feedback, but there aren't many active Grammer users anymore.
-
I think instead of adding hooks you should create an appvar search that finds any appvar that starts with a specific header, like how Grammer figures out which prgms are Grammer programs.
I don't know if you would need hooks or not for that. :w00t:
-
Oh, I mean just Grammer's own "hook" system where it calls external routines (in appvars) at various stages of menu rendering. The plan was to have a way for external packages to kind of register with Grammer, with pertinent info stored in Grammer's appvar so that multiple hooks and stuff could be registered. But, that got complicated when I tried it last year :P
-
So what I'm getting from this is that you tried to make a system where external variables registered with Grammer and Grammer would interact with the hooks of that variable??? Could you dumb it down a little? O.O
-
So my intent was a "parser hook" kind of feature. So when Grammer was getting ready to parse a token, it would first pass it through a third-party program in case they would alter parsing. Now I think it might be useful on the main menu during, say, the filtering step (when it is figuring out which programs to display), or for keypresses or something.
-
Ahh. I get it now. Thanks for explaining. I know how annoying that can get. <_< 1337
-
The Menu( Command Feature Request
Menu(ᵒx,y,w,"Item 1"[Lbl pointer],"Item 2"[Lbl Pointer],etc...
If that's to hard then add + to it maybe?
Another Idea:
Menu('x,y,w,[Lbl pointer]*
*The Lbl would have a description, in the form of a String, that tells the menu what the name should be. If there is no description then the name of the label is used.
-
*The Lbl would have a description, in the form of a String, that tells the menu what the name should be. If there is no description then the name of the label is used.
I don't understand, sorry. As for the former, you can use the existing Menu(' command. You supply a pointer to a routine that gives the strings, and a routine that does something when an item is selected. In the latter routine, you could Goto different labels based on what is selected.