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 - Xeda112358
Pages: 1 ... 5 6 [7] 8 9 ... 317
91
« on: January 26, 2020, 09:04:58 am »
Oh, yes,the current release of spasm-ng has a bug with the name field. @NonstickAtom785 was working on compiling the fixed fixed version, so maybe he'll be able to upload a spasm.exe this week? If you want to get it to compile in the meantime, you can open src/TIDE.z80 and edit line 5 to be: .db $80,$48, "TIDE "
The bug is that spasm is expecting the name field to be $80,$48 (which means an 8-byte name), but it is actually allowed to be $80,$4x. There is a version that has this bug fixed and hasn't been merged yet: https://github.com/alberthdev/spasm-ng/tree/feature/app-name-var-sizeOtherwise, the bin/ folder has an already compiled .8xk (but that doesn't help you if you want to play with modifying the code  )
92
« on: January 24, 2020, 07:44:11 am »
Both @E37 and I have made efforts to, but mine is not mature enough to really be useful: https://github.com/Zeda/TIDEE37 may have added more to this project since the last update, but I'm not sure.
93
« on: January 18, 2020, 11:48:37 am »
I don't play RPGs much, but damn is that a good soundtrack.
94
« on: January 18, 2020, 11:02:09 am »
Hi! With @NonstickAtom785's talk of making an RPG in Grammer, I decided that I should finally add in smooth-scrolling tilemap support in Grammer (finally). Anyways, I went with a more standard format, so we need a new tilemap editor, and I like how this one has turned out:  The controls are listed in the readme, and I've included a sample set of files (spritesheet+tilemap+config).I've also included a map viewer, prgmTILEMAP:  That is not documented, but use [ *] to use 15MHz mode, and [/] to use 6MHz mode (default). It uses the same data as the map editor, so it loads the same tilemap and spritesheet that you were working on.
95
« on: January 18, 2020, 11:01:45 am »
Wow, lots of updates to report: The GitHub page is getting a lot more documentation, thanks to @NonstickAtom785 (both in documenting and bugging me to document stuff). Bug Fixes: - Fixed bug with Param
- Fixed bugs with Input
- Fixed bug with PauseIf. This was allowing un-breakable infinite loops!
- Fixed bugs with Archive/Unarchive (and similar bugs). These could cause crashes.
- Fixed bugs with archiving in the main menu
- Fixed bug with empty strings
- Fixed bug with ending quotes on strings!
- Fixed Omnicalc/Batlib fonts
- Fixed bug with not implementing screen invert :|
Updates: - Optimized Dispgraph
- Added new display methods that allow overlaying or masking multiple buffers
- Added smooth-scrolling tilemap routines! This is long overdue; I reserved space for more tilemap commands and it took 8 years to actually do it >_>
- Reimplemented degree token to temporarily set a buffer
- Added TI-OS fonts to the text routines (request)
- Updated variable-width font at request to look like it used to.
- Reimplemented ' option for the Menu( command.
- Added DS<( to complement IS>( (nonstickatom)
We are now up to version 2.50.9.4  You can find documentation on the GitHub, but I'll attach the .8xk EDIT: Here's a screenshot implementing the smooth-scrolling tilemap commands and new DispGraph techniques:
96
« on: January 16, 2020, 12:29:25 pm »
Oh, yeah, I'm not sure exactly how to do that, sorry. Evidently it is feasible, but you'd probably need a bit of assembly to do it.
97
« on: January 15, 2020, 12:56:32 pm »
I'm confused about what you want. You just want to draw the text, like the Output( command in TI-BASIC ?
98
« on: January 15, 2020, 12:22:20 pm »
Holy hell that's awesome.
99
« on: January 15, 2020, 10:28:46 am »
Screen shifting only shifts the data on the screen (and for reference to E37, right/left shifting can shift multiple pixels at a time and is optimized to take advantage of bytes and nibble shifting).
The tilemap routine draws the map to the screen. When you shift, you have to tell Grammer to draw the incoming tiles afterward.
100
« on: January 15, 2020, 09:40:44 am »
Hmm, well, the easy parts will be making the tools for tilemaps and sprites. To view, say, inventory menus, Grammer's Menu(' command will be very handy.
As for storyline, maybe a classic hero quest? Badguy happens, hero is summoned to save the day, hero has various struggles/trials to get to the Big Fight.
101
« on: December 20, 2019, 09:48:49 am »
Hey, I made a new font editor for Grammer! I don't have much time to post, so I'm going to keep this short. Here it is: EDIT: I'm on mobile now. I can't remember if I ever posted about it, but I made a bold font here that is compatible.
102
« on: December 04, 2019, 12:56:13 pm »
Grammer v2.50.8.6In this update, I focused on fonts! - I broke compatibility with third-party variable-width fonts (all zero of them) made for Grammer. Whereas before, Grammer had a variable font in which each char had its own height and width, now the whole font gets a height byte, and each char gets a width. This seemed a lot more reasonable-- it's a lot easier to program with it, it's a bit faster to access chars, and I could use DrDnar's Monochrome Font Editor
- I converted both the fixed 4x6 font to an mfefont, and I totally remade the variable font as an mfefont
- Whereas before, the variable width font was sparse (missing many chars), now it is complete!
- Yes, huge fonts are supported, technically.
Now for bug fixes. Again, big thanks to @NonstickAtom785 and Hans Burch: - For <<expr>> is officially documented, and fixed, and now you can nest them.
- For <<var>>,0,65535 no longer causes an infinite loop.
- Rounded square roots now round in the correct direction.
- Yet another If-related bug was fixed, this time the bug was with Then (but not with Then...Else). This bug caused the program to erroneously skip End statements if they were programmed as End:End. Ouch.
- !If works again.
- A page boundary bug was fixed that could cause major issues when reading variables from archive.
Some other updates: - Modules are no longer verified when calling a module function. Instead, they are verified when they are initialized (ex. "5MYMOD->$) and after verified, Grammer assumes that they remain correct. This reduces some overhead for module functions.
103
« on: December 03, 2019, 11:08:53 pm »
Okay, I've fixed a few bugs The following kind of code was broken: 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
104
« 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 ) : https://github.com/Zeda/Grammer2/blob/master/src/gfx/line.z80
105
« 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 
Pages: 1 ... 5 6 [7] 8 9 ... 317
|
Show Posts