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 ... 61 62 [63] 64 65 ... 153
931
« on: January 04, 2012, 09:07:01 pm »
I think you can safely ignore whether or not the Axiom reference is in a comment. Even if it is, the program probably still uses commands from it somewhere in the source and the token replacement should be used for clarity whether or not it is commented out. EDIT: And if the programmer is doing crazy stuff like a conditional if-else comment to include only one of two Axioms that replace the same tokens... Well that's a little nuts and I think they can deal with that not being supported. 
932
« on: January 04, 2012, 01:34:57 pm »
I am fairly certain that it can be done with minimal speed loss if token replacements are somehow cached intelligently. In fact, I'm trying it right now. 
933
« on: January 03, 2012, 10:39:12 am »
I think that any of those options would be great. I had suggested an ifdef-like command because it seemed easier to just base my suggestion on an existing assermbler directive, but any of those options would serve the purpose. The first two would be more general and flexible, but maybe the third would actually be better with its more specific and smaller syntax. Now, all Axe libraries need are conditional inclusion of routines based on whether or not they are actually used, like real routines and Axiom commands, and they'll be fully awesome. 
934
« on: January 03, 2012, 12:18:25 am »
My suggestion is that you should be to use #ifdef in a library to fill in defines with default values if the user doesn't define them. Say the user just wants a basic tilemapper. You'd probably expect that to default to a black and white 8x8 smoothscroller with 8 bits per tile, no compression, a static buffer (plotSScreen), no animated tile support, no support for reading tiles from archive, and so on. It would be a pain and possibly confusing for someone who just wants to use an easy, basic tilemapper to be forced to define a dozen different constants in their program just to say that he/she doesn't want to deal with the fancy stuff.
EDIT: Also, you said that you didn't want an IfDef type command. I'm not sure if you meant the idea of it being an individual command, or it existing entirely. If it's the former, you can still add this ability without an actual IfDef command by adding a command like Defined(), or as I suggested before, by using a trivial comparison like ≥0 in a preprocessor conditional. If it's the latter, I guess people will manage, it'll just require extra source code for users of customizable libraries.
935
« on: January 02, 2012, 08:44:59 pm »
I'm not so sure if I want an "IfDef" type command. What's wrong with just defining a constant as 0 or -1 if its going to be unused? Other than typing slightly less in some cases, it really doesn't offer an advantage over regular if statements.
The main purpose I can think of is, as I suggested in my original post, Axe libraries. Say you want to write a killer tilemapping library. You may need a bunch of different options to make it really versatile: tile width, tile height, black and white or grayscale, bits per tile, compression scheme, tileset pointer location, map pointer location, read from archive ability, smooth or rough scrolling, custom/variable buffer pointer, animated tile support... the list could go on. Being a true library, it's not proper to edit the library file itself. The user should specify customization settings in their own program. Without something like an #ifdef, you would have to force the programmer to define a dozen different constants for features they don't need, or don't even know exist. If a new feature was added to the library down the road, their program would instantly be broken because it would need a new constant defined. And including all of these constants in their source would cause unnecessary headaches and source bloat that could be a hundred bytes or more.
936
« on: January 02, 2012, 06:57:56 pm »
My idea was that any (unsigned) number in Axe is greater than or equal to 0, but NaN is not. But on second thought that syntax suggestion is sort of confusing. I guess a new command may be the best way to go.
937
« on: January 02, 2012, 05:03:18 pm »
* Runer112 points to his post on the last page The addition of preprocessor conditionals was awesome, and I will find it very useful. But could there also be something similar to #ifdef? It would be useful for Axe libraries that allow the user to customize them by including defines in their own source code, and the library can fill in any defines with default values if the user didn't define them. The obvious solution would be a new command that determines whether or not the constant is defined. If you don't want to add a new command, you could also try something like the standard preprocessor conditional, but with the constant being used in a trivial comparison, like this:
...!If °Size≥0
8→°Size
...
938
« on: December 31, 2011, 01:05:27 am »
It sounds to me like your key-reading routine doesn't have enough delay between writing to and reading from the key port. I'm not sure how much delay is safe enough for every calculator, but I know that Quigibo recently increased Axe's number of cycles between the port write and read for key input from 19 to 22 cycles because it turned out that 19 cycles isn't enough for some calculators running at 15MHz. Interestingly enough, Darl181 is the one who reported this problem for Axe as well.
939
« on: December 29, 2011, 07:42:24 pm »
I believe I have found two bugs. First, it appears that once zStart has "learned" the proper delay for your LCD, it will send this value to port 29h upon startup whether you want it to or not, as there is no option to control this. Second, it appears that bits 0 and 1 of port 29h are given no special care (either preserved or set) when this LCD delay value is sent. For instance, with my LCD delay value of 32 (20h), zStart resets bits 0 and 1 of port 29h, thus disabling the 6MHz memory delays whether this is desired or not.
940
« on: December 27, 2011, 12:46:13 pm »
The addition of preprocessor conditionals was awesome, and I will find it very useful. But could there also be something similar to #ifdef? It would be useful for Axe libraries that allow the user to customize them by including defines in their own source code, and the library can fill in any defines with default values if the user didn't define them. The obvious solution would be a new command that determines whether or not the constant is defined. If you don't want to add a new command, you could also try something like the standard preprocessor conditional, but with the constant being used in a trivial comparison, like this:
...!If °Size≥0
8→°Size
...
941
« on: December 23, 2011, 07:33:56 pm »
A version of ClrDraw that fills the screen with black instead of white. For making White-on-black games. 
This can be done quite easily already with Fill(L₆,768,ᴇFF), which fills 768 bytes (size of graph buffer) of data starting at L₆ (the graph buffer) with ᴇFF (all bits 1 = black). An optimized form of this is Fill(L₆,768,-1). A large reason ClrDraw exists is because there is a bcall that does just that. However, there is no bcall that clears the buffer to black, so it wouldn't really make sense to have an Axe command just for it, especially since a built-in routine would do pretty much the same exact thing as the code I wrote above.
942
« on: December 21, 2011, 01:07:02 am »
You know how the problem with error scrolling was the longest standing bug in Axe until a few days ago? Well I just discovered a bug that came into existence only 11 days after it and is now contending for the title! The bug involves printing tokens to the graph screen, which has apparently been broken since it was first added. The issue is that the routine feeds B_CALL(_Get_Tok_Strng) the token in hl, although the bcall actually reads the token pointed to by hl. 7 days to release a version of Axe with this bug fixed, or else this (rather lame) bug takes the title of longest standing bug in Axe!
943
« on: December 20, 2011, 08:22:47 pm »
What exactly do you need the slope for? Because line drawing algorithms, for instance, don't actually need a numerical slope value. They just use dy and dx as-is without having to divide one by the other.
944
« on: December 19, 2011, 11:37:24 am »
If you're wondering, the optimized way to do that would be:
and 0→{→{→{S}+5}+10}
945
« on: December 19, 2011, 01:12:53 am »
First, an optimization that I can't give you code for: making *^CONST use an equivalent constant division optimization if one exists. And don't forget about the trivial cases, *^1 and *^0. Of course, these only apply if you don't change this operation to return a 32-bit result somehow. Which it really should. Next, some silly optimizations: ^0, <<ᴇ8000, >>ᴇ7FFF should simply be 0, while ≥≥ᴇ8000 and ≤≤ᴇ7FFF should simply be 1. If you're wondering why ^0 should be 0, that's what the general modulus routine would return anyways. Finally, some optimizations for signed comparisons. These have been lacking general forms which take advantage of absolute jumps as well as optimized forms for constants for quite some time. Thanks to jacobly and calc84maniac for helping me come up with the first two! If either of you two are reading this, feel free to look at the other operations and try to optimize them. p_SGT0:
.db 8
ld a,h
or l
jr z,$+6
add hl,hl
sbc hl,hl
inc hl
p_SLE0:
.db 9
ld a,h
or l
jr z,$+6
add hl,hl
ccf
sbc hl,hl
inc hl
p_SLtLeXX:
.db 11
ld a,h
add a,$80
ld h,a
ld de,$0000 ;$8000-const
add hl,de
sbc hl,hl
inc hl
.db rp_Ans,6
p_SGtGeXX:
.db 12
ld a,h
add a,$80
ld h,a
xor a
ld de,$0000 ;$8000-const
add hl,de
ld h,a
rla
ld l,a
.db rp_Ans,6
p_SIntGt:
.db 11
scf
sbc hl,de
add hl,hl
jp pe,$+4
ccf
sbc hl,hl
inc hl
p_SIntGe:
.db 11
xor a
sbc hl,de
add hl,hl
jp po,$+4
ccf
ld h,a
rla
ld l,a
p_SIntLt:
.db 11
scf
sbc hl,de
add hl,hl
jp po,$+4
ccf
sbc hl,hl
inc hl
p_SIntLe:
.db 11
xor a
sbc hl,de
add hl,hl
jp pe,$+4
ccf
ld h,a
rla
ld l,a
Pages: 1 ... 61 62 [63] 64 65 ... 153
|
Show Posts