« previous next »
Pages: 1 ... 29 30 [31]   Go Down

Author Topic: Grammer 2-The APP  (Read 61454 times)

0 Members and 1 Guest are viewing this topic.

Offline E37

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 271
  • Rating: +17/-0
  • Trial and error is the best teacher
    • View Profile
Re: Grammer 2-The APP
« Reply #450 on: September 03, 2019, 01:44:56 pm »
Ok, you can stop now. Look, if you continue, you will convince me to use Grammer over Axe for all my non-game projects. How dare you tempt me away from our lord and savior Axe Parser.
Logged
I'm still around... kind of.

Offline Xeda112358

  • they/them
  • Project Author
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4607
  • Rating: +716/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Grammer 2-The APP
« Reply #451 on: September 03, 2019, 02:21:54 pm »
There are perks to both languages, that's for sure. I think Grammer is better for higher-level stuff, and Axe is better for faster, lower level stuff.

EDIT: Here is what the fancy menu looks like now:

For this one, each of the items is generated on-the-fly by a Grammer subroutine, and that contributes to it's slowness. It has to execute the subroutine every time the user moves up or down, as well as whenever an element is generated. In this implementation, every time the menu scrolls, it has to generate all of the elements from scratch. I might make it just scroll the contents up or down and generate a single item instead of the whole thing, but that's for future work. At least Grammer already has code for shifting rectangular regions of the screen up or down!.
« Last Edit: September 04, 2019, 12:14:20 am by Xeda112358 »
Logged

Offline Xeda112358

  • they/them
  • Project Author
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4607
  • Rating: +716/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Grammer 2-The APP
« Reply #452 on: September 05, 2019, 08:16:30 pm »
Minor update to the above.
The menu routine is now more efficient on scrolling. I did actually take advantage of the "rectangle shift up/down" routines so now it makes fewer calls to the Grammer routines, improving performance.
Here is what it looks like now:


I also remade the rectangle routines. It is 112 bytes larger, but it is cleaner code, uses 4 bytes of already allocated RAM instead of 24 bytes of specially allocated RAM, and doesn't use shadow registers (so it doesn't need to disable interrupts). As well, I added two new methods-- they both invert the border, but one clears the inside, the other sets it to black. I have no idea why that might ever be desirable, but I have all the other methods of setting the border and fill to black/white/clear/invert, so why not? (and it didn't add much to the code). Now I just need to add in left/right rectangle shifts and world domination will be mine.

Attached is the .8xk for those who need the latest.
Logged

Offline Xeda112358

  • they/them
  • Project Author
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4607
  • Rating: +716/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Grammer 2-The APP
« Reply #453 on: September 13, 2019, 08:14:30 pm »
Hey folks, have the first official update in over seven years!
Since the last update, I've optimized some more and added in filled circle routines internally. With that, there are now 12 circle drawing methods, with various borders and fills (between white/black/invert/clear).



Download Grammer v2.50.6.3 :)
Logged

Offline Xeda112358

  • they/them
  • Project Author
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4607
  • Rating: +716/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Grammer 2-The APP
« Reply #454 on: September 19, 2019, 07:39:33 pm »
This is just a quick update! I tracked down a critical bug in Grammer that has been around for a few of the mini releases (probably since last year). Send( was returning the wrong pointer, so if you started writing bytes to a file, you would almost certainly end up corrupting variables in RAM. Anyways, the link in the previous post now points to the corrected version :)
Logged

Offline Xeda112358

  • they/them
  • Project Author
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4607
  • Rating: +716/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Grammer 2-The APP
« Reply #455 on: October 02, 2019, 10:08:44 pm »
I (re)updated the download in the Latest Releases thread with some more bug fixes. Also, I added in the arctangent routine after @E37 bugged me about it. It was a little more work than I was expecting, but it is useful. In fact, if you supply two arguments, it works as an arctan2 routine :)

So bug fixes:
- Another bug in Send( was fixed
- inString( was just plain broken, so I fixed that and had to adjust the Lbl routine to work with the fix.
- Vertical caused some exciting crashes, so I fixed that and even optimized it.
Logged

Offline Xeda112358

  • they/them
  • Project Author
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4607
  • Rating: +716/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Grammer 2-The APP
« Reply #456 on: November 25, 2019, 11:52:06 am »
Wooh, lots of bug fixes, a few new features! Latest Release.
Logged

Offline Xeda112358

  • they/them
  • Project Author
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4607
  • Rating: +716/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Grammer 2-The APP
« Reply #457 on: November 26, 2019, 07:11:12 pm »
I've been working on the built-in fonts!

As some may have noticed, the variable font was very sparsely populated, only containing some important characters. Part of the reason is that the old font format was... convoluted. Each character had its own width and height, which made it difficult to make an editor for it. I decided to go with a more sensible option, one that I had used in the past-- The fontset has a height-byte, and each char has its own width (which is allowed to be 0).

There were two advantages to this: one, it is easier to code the text routine, and two, DrDnar's Monochrome Font Editor already supports this format (Xeda's Format #2) which means I had an easy-to-use editor. So, with all of this, some motivation, and some free time, I completed the font and reworked the text routines:


I haven't have tested the Input routine with this, so I should work on that and it works, so I hope people like this ^~^
Also, if anyone wants to make their own fonts based on these, I have the "mfefont" files here:
Variable-width font (export this to Xeda Format #2)
Fixed 4x6 font (export to Xeda Format #1)

You can find the download in the GitHub project's /bin folder, or attached.

EDIT: Tested the input routine; it works ^~^
EDIT2: Oh my. Sweet. Baby. Carrots. Fonts can be BIG apparently. I tested a 16-pixel wide character and it works fine :0
EDIT3: More updates! I've gone bug hunting and I managed to fix the following:
  • The undocumented For <<constant>> can now be nested! This should be documented; it has been around for years.
  • An ooold bug report I found mentioned that For X,0,65535 would cause an infinite loop, so I fixed it!
  • Rounded square roots, via √(' were pretty broken. I had an old bug report that showed √('255 was returning 0, but that was fixed a few months ago when I totally rewrote the square root routine. But, I did botch the rounding, causing it to round up when it should have rounded down, and vice-versa. This is now fixed :)

I also overhauled the module documentation, and I realized I had to advance the module version since I broke some support with the original :(
« Last Edit: November 27, 2019, 09:35:58 am by Xeda112358 »
Logged

Offline E37

  • LV5 Advanced (Next: 300)
  • *****
  • Posts: 271
  • Rating: +17/-0
  • Trial and error is the best teacher
    • View Profile
Re: Grammer 2-The APP
« Reply #458 on: November 28, 2019, 10:34:26 am »
That looks quite nice. How does it work with font hooks? I was playing around with adding custom fonts to one of my games and I noticed that the font hook makes the OS's display routines way slower. I think that is because it bcalls the font hook and bcalls take forever. You might be using custom routines since you have variable-height font though. Do your display routines obey the font flags? (like inverse, erase behind etc.)

I can't quite figure out what you are using to display the font in the demos. It looks like you are just using the ti-basic style 'Disp' command (or PutC) since you can see the screen tearing a little when you scroll but that doesn't take variable-width font...

You should add in the clipped line routine you made if you haven't done so already. I have been using it for a while now and it works perfectly.
Logged
I'm still around... kind of.

Offline Xeda112358

  • they/them
  • Project Author
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4607
  • Rating: +716/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Grammer 2-The APP
« Reply #459 on: November 28, 2019, 11:36:11 am »
I use custom font routines and the text flags that Grammer uses are separate from the OS's flags. In the example, I put in DispGraphs every time I shift the screen up just so that people had a chance to actually see the font (since it doesn't fit on one screen for either font). I found that a custom font routine was much easier and faster than using the OS routines, but of course that meant I needed to make a font for it.


For the line routine, I actually went with a very different approach, but used the Axe routine as scaffolding. For Grammer, I wanted a line routine that was much more modular, so it actually takes IX as an argument that points to a plotting routine. Doing this is a bit slower than the other routine, but it doesn't need the additional clipping code (the plot routine just does nothing when OOB). It will also make it way easier to add new line drawing options in the future, like dotted lines, thick lines, etc.

Here is the line drawing routine (I only just realized that my editor got confused about the tabs from Axe's code :P) : https://github.com/Zeda/Grammer2/blob/master/src/gfx/line.z80
Logged

Offline Xeda112358

  • they/them
  • Project Author
  • LV12 Extreme Poster (Next: 5000)
  • ************
  • Posts: 4607
  • Rating: +716/-6
  • Calc-u-lator, do doo doo do do do.
    • View Profile
Re: Grammer 2-The APP
« Reply #460 on: December 03, 2019, 11:08:53 pm »
Okay, I've fixed a few bugs

The following kind of code was broken:
Code: [Select]
If <condition>
Then
    <<do stuff>>
    <<While, Repeat, For, or If/Then (but not If/Then/Else)>>
End:End
If the condition evaluates false, Grammer would search for the matching End token. However, I tried to be clever, and combined it with the code for when it is If without Then, and so it seeked the end of the line (specifically the newline token, colons (":") didn't count). Unfortunately, this meant that the second End was skipped, causing an outer loop to End prematurely. Oof.

In fixing this bug, I noticed another clever optimization that I had made which was really not clever and had broken "!If" for a while! !If works now :)


An unrelated bug is with copying data from archive to RAM if it crossed a page boundary. Once again, I thought I'd be clever and I noticed that I had an "adc hl,bc" in a place where the carry flag was guaranteed reset, so I "optimized" it to "add hl,bc" to save 4cc and a byte. Whelp, it turned out that I was using "adc hl,bc" because that one affects the sign flag, whereas "add hl,bc" doesn't. Ouch.


For loops had an update, specifically fixing the previously undocumented command For <<expr>> which would loop <<constant>> number of times. Today, @NonstickAtom785 found a bug when trying to use a variable as the expression. In actuality, it was a For bug affecting any expression that started with a pointer var! I fixed this by simply checking if the token following the pointer var was a comma. If it isn't a comma, treat it as an expression, otherwise, treat it as a normal For loop.

There were some updates to modules, too: I moved the verification step. Before, every time a module command was run, the module would have its header verified (look for the 4-byte magic number, then make sure the version was compatible). Grammer now verifies when you first initialize it ("5MYMOD->$) and assumes for subsequent calls to module functions that the module is still valid. This removes some overhead, but module functions are still slow to call, and likely always will be :P
Logged
Pages: 1 ... 29 30 [31]   Go Up
« previous next »