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 - Runer112
Pages: 1 ... 80 81 [82] 83 84 ... 153
1216
« on: May 28, 2011, 03:36:27 pm »
If Quigibo wanted to release this with Axe, he'd either have to keep it up to date himself or give me new versions of Axe about a day in advance so I can update the file and give it back to him. Supposedly we're very close to Axe 1.0.0 though, for which he may or may not want a file like this being packaged into the sort of "final" version.
1217
« on: May 28, 2011, 01:06:16 pm »
Updated for Axe 0.5.3. As usual, the updated command information document is attached to the first post. Changelog:[NEW] denotes new Axe commands, [CHG] denotes changed Axe commands, and [FIX] denotes Axe commands that haven't changed but have corrected information. Red denotes a bug. Green denotes a change that I deem to be awesome.- [CHG] All 2-byte big-endian loading and storing commands now work
- [FIX/0.5.2 CHG] Added trivial math operations +0, -0, *0, *1, *65535, /0, /1, //0, //1, ^1, ^65535 (If you're reading this Quigibo, did I miss any?)
- [FIX/0.5.2 CHG] Added notes specifying that //0 and ^65535 are mathematically incorrect
- [CHG] Any of the trivial math operations listed above that result in no compiled code cause a crash during compiling
- [NEW] Increment and decrement operators ++ and --
- [CHG] Nibble storing routine adjusted to access nibbles in big-endian format, like the nibble reading routines
- [FIX/0.5.2 CHG] The routines to draw strings in applications converted into subroutines
- [FIX] Adjusted the cycle estimates for p_NewLine, p_ClearScreen, and p_SaveToBuffer
- [CHG] Optimized p_FastCopy — 1 byte smaller, 1548 cycles faster
- [CHG] Optimized p_DrawAndClr — 2 bytes smaller, 1548 cycles faster
- [CHG] Optimized p_DispGS — ~5000 cycles faster
- [CHG] Speed-optimized p_Disp4Lvl and improved grayscale quality — 3 bytes larger, ~7500 cycles faster
- [FIX] Adjusted the cycle estimate for p_DKeyExpr
- [FIX] Adjusted the cycle estimate for p_Div
- [FIX] Adjusted the cycle estimate and notes for p_SDiv
- [NEW] 8.8 fixed point reciprocal command -1 — 29 bytes, ~1349 cycles
- [CHG] Division and signed division have a bug that will cause them to always return 0 if the divisor is greater than 255
- [CHG] Speed-optimized p_Sqrt — 15 bytes larger, ~5500 cycles faster
- [FIX] Added a note mentioning that p_FlipH can produce a garbage sprite
1218
« on: May 28, 2011, 11:42:34 am »
You can make the flipping animation twice as fast by changing this line:
-128-2→θ
To this:
-128-4→θ
1219
« on: May 28, 2011, 11:21:17 am »
As long as you don't use division or flipH(), you should probably be fine. But since I know a lot of people are programming physics platformers that could definitely use either of these, they should probably wait.
1220
« on: May 28, 2011, 10:47:20 am »
Here is the list of bugs I have discovered in Axe 0.5.3: - 16-bit/16-bit division is broken and will always return zero! (See this post) Very bad!
- Except for bitwise operations, every mathematical auto optimization that results in no compiled code crashes when compiling! Also very bad!
- [Pre-existing] flipH() can produce a garbage sprite; see this post
- [Pre-existing] The //0 optimization (and the result of //(0) for that matter) is not mathematically correct due to being a signed operation
- [Pre-existing] The ^65535 optimization is not mathematically correct
Also, this isn't a bug, but could you add arbitrary buffer support to DispGraphrr? I put the buffer loading at the very start of the routine and added the push hl / pop hl specifically for this awesome purpose.  EDIT:Commands.htm still says that DispGraphr and DispGraphrr will not work at 15MHz. I'll fix that.
By the next version perhaps? 
1221
« on: May 28, 2011, 09:29:39 am »
I tried to warn you not to use my old, more optimized reciprocal function that modified the division routine because it broke 16/16 division. Now division is broken in Axe 0.5.3.  If you plan on making a new release quickly to fix this, wait an hour or two until I can finish checking all the updates and make sure none of the others are broken.
1222
« on: May 27, 2011, 10:30:59 pm »
When the variable was created, the OS allocated just the right amount of size to contain it. It uses that size to know how far after it in memory to store the next variable, and how much of memory to free up when the variable is deleted or archived. If you alter the number, it will result in either a memory leak or the variable overlapping another variable. The next time the OS tries to overwrite the variable, delete the variable, or rearrange the contents of RAM, there will likely either be a memory leak left in RAM or part of another variable will be overwritten.
1223
« on: May 27, 2011, 10:21:18 pm »
It is not safe to allocate/deallocate memory for an OS variable by just changing the size bytes. You'll probably want to use MemKit's Delete() function, which is able to deallocate a specified number of byte from an OS variable.
1224
« on: May 27, 2011, 07:20:41 pm »
Actually it wasn't a bump for conditional Goto, but I still really want that as well. And of course conditional sub() would go hand in hand with it. At least sub() without arguments.
1225
« on: May 27, 2011, 07:14:19 pm »
Oh, I assumed ++ would only be an available operator for variables, as other programming languages use it. But I guess it makes sense from an optimization standpoint to allow it for one-byte values and complex pointers.
Now if only Axe supported conditional jumps based on the Z80's flags, we could make super optimized loops...
1226
« on: May 27, 2011, 06:11:42 pm »
An increment of zero can be valid in some languages. It will just likely freeze/crash your program unless you manually increment the variable yourself or jump out of the loop.
1227
« on: May 27, 2011, 04:27:17 pm »
And just like SirCmpwn said, this messes with the flags in the exact same way that CP A does.
It affects the n flag differently. 
1228
« on: May 27, 2011, 10:32:16 am »
Axe's FastCopy is very different from Ion's FastCopy: - Axe's FastCopy supports copying from an arbitrary buffer; Ion's FastCopy does not
- Axe's FastCopy correctly preserves the interrupt status; Ion's FastCopy does not
- Axe's FastCopy preserves the CPU speed and will run correctly at either 6MHz or 15MHz; Ion's FastCopy does neither
- Axe's FastCopy will work on newer calculators with bad LCD drivers; Ion's FastCopy will not
I could give you a similar list for every other command shared between Axe and Ion.
1229
« on: May 27, 2011, 10:12:48 am »
Axe's routines are all custom made and different from shell routines, so it couldn't use them.
1230
« on: May 27, 2011, 09:26:27 am »
I whipped up a quick program and it worked for me. Are you sure you typed in the code correctly? And what is the context of where you added this code?
Pages: 1 ... 80 81 [82] 83 84 ... 153
|
Show Posts