For those who do not know, I have once again taken up a project that is an interpreted programming language. For thise of you familiar with my work on ReCode, you might wonder what is different. For the rest, you will hopefully want to know what Grammer is.

First off, the name "Grammer" is meant to be a horrible rendition of what I believe to be a joke (this is a programming language so naturally you need good grammar and it would be better for programmers if they had pro grammar) .

Grammer is like TI-BASIC (and ReCode) in that it is an interpreted programming language. This means it is by nature slower than assembly, but usually smaller for more complex tasks (like games). It also means that it is easier to learn than a low level language like assembly. That being said, Grammer may still be a bit more difficult to learn than BASIC. The other major downside to Grammer as opposed to TI-BASIC is that Grammer cannot do the kind of math that TI-BASIC can. That, however is a pretty cheap tradeoff compared to the benefits of Grammer.

Simply put, Grammer is a heck of a lot faster than BASIC-- in fact, it is close to the speed of Axe or assembly. Plus, while it does not handle nearly all of the math functions of TI-BASIC, it has more than just the basic four functions. On top of that, the graphics are beyond compare to TI-BASIC and should be getting better.

At the moment, Grammer is fully capable of producing games as well as some complex algorithms. It has gone beyond ReCode to include features from a simple ON breaking ability to using labels, calling subroutines, and calling or executing sub programs. There is a better sprite routine, more advanced math (I was playing with number theory at the time when most of it was coded), better optimised routines, and more loops to use.

However, with all of that, this is still in the testing phase and is only a prototype of what the final product will be. In the end, my goal is to have Grammer be an app with a built in program editor, VAT system, variables, data editors, and a program interpreter. I hope it will be 16KB or less, but I think the data will push it over that limit (data as in the token set and whatnot).

Anyway, I will leave you with some samples for your viewing and using pleasure. If you have suggestions, or questions, feel free to ask or suggest. I won't have regular internet access for a few more weeks, though

*One of the changes I want to make is to use Theta or Ans instead of Theta' as the system var.
Grammer 1.05.07.11



My main issue right now is choosing which tokens do what. For example, I want to add in a way to shift the screen, but I am not sure which token to use. also want to find a good token for creating variables of a given size and appending or inserting data. Does anybody have any ideas?

Is it Grammar or Grammer? Anyways, this seems pretty cool, I'll have to try it later.

It is Grammer

I am very sad it's Grammer instead of Grammar, but let's ignore that for a second. Thank you for clarifying how this is different from ReCode/BatLab; I was indeed about to ask that exact question. It looks very impressive, at least from the screenshots. I have no great suggestions for the tokens at this exact moment, but I am tired, so I'll try to think about it later.

Its not a problem, but I also wanted to say that this is my first "big" project using an assembler! I used the DCS SDK which made it really easy for me to compile my code into programs, so thanks much!

That's awesome, I'm extremely happy to hear it. It makes me feel gratified when my programs help people out like that! Shaun and I were briefly discussing Grammer in the car today; hope we see some more progress from you soon.

So Grammer has had a few additions and updates-- enough that I cannot remember what all is new since my last update here, but I will try:
Tangent( now shifts the screen in any of 8 directions for a given number of pixels
π is used to prefix a hexadecimal number (this is supposed to be a pi symbol)
Text( Now has a modifier for "typewriter" mode (it displays the chars with a delay)
Fix Text( is used to set the delay time for typewriter mode
i this is the imaginary i and is used to prefix the name of an OS Real var. This allows you to store to and use OS vars

The fun comes in these latest additions for particle effects
R▶Pr( this clears the particle buffer (essentially locking the previous particles in place on the screen)
R▶Pθ( this will cycle through the particles, compute their locations, and redraw them
P▶Rx( used to add new particles
P▶Ry( used in the about to be released version to change the particle effect (currently there are only 2).

Some screenies are provided as well as a link to the download, below.

I plan to modify P▶Ry( to allow the user to change the location of the particle buffer. Currently, the particle buffer is in saveSScreen, so it only handles 383 particles, but if I add a way to create vars, the user can use much larger buffers and multiple ones to handle several particle types

Another neat suggestion that I am still thinking about is adding custom particles >.>

As promised, screenies:


Grammer v1.06.10.11 : http://www.omnimaga.org/index.php?action=dlattach;topic=9067.0;attach=9772
And here is the example in the screenie Use left/right to move the cursor, down to drop particles, and +/- to change the particle type.
http://www.omnimaga.org/index.php?action=dlattach;topic=9067.0;attach=9773

Are all particles gravity-affected? Can you use it to create starburst sorts of effects instead?

To tell the truth, I see the particles thing to be cool, but adding in functions to the language seems a bit ridiculous to me -- since implementing such a system in code is rather trivial, and the system you added to the language seems rather trivial (only gravity affected, with random left-right movement), I don't actually see much use or a point. Unless I'm missing something?

Haha, actually, I originally made a particle engine in Grammer code, but it was lagging a bit too much after only 30 particles or so. So I came back home and made a version in assembly for BASIC programmers to use and it was much faster and it was smaller than I expected. Since I also had a request to add this feature from another user, I decided "What the heck? Why not?" and added it. Also, I plan to convert this to an app soonish (no specific date!) so it won't matter if I add a few random features like this as the code size is fixed anyway

In the interest in preserving tokens, might you consider compressing all the particle functions into one token (R-Pr(1) clears buffer, R-Pr(2) cycles, etc), or are you happy with it using the four? I guess those don't have much other use.