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 ... 56 57 [58] 59 60 ... 153
856
« on: March 10, 2012, 03:22:19 pm »
Optimized.  S*7*3+11→SEDIT: Alternatively, to save 4 bytes (as long as you already use general multiplication elsewhere) at the cost of, on average, 666 cycles: S*21+11→S
857
« on: March 08, 2012, 04:48:56 pm »
That's only the end of the line, the whole line is:
not({→r1} and r2-1/256) and r4 or {r3}→{r3}+12→r3
What this is really doing, just in an optimized manner, is this:
not({→r1} and r2-1/256) and r4 or {r3}→{r3}
r3+12→r3
858
« on: March 07, 2012, 10:33:20 pm »
I believe what he means is including only part of OS files at compile-time.
Edit: I guess I should ask though, can anyone imagine a situation in which this would be useful? Because I'm having trouble doing so, and taking up application space for a feature that's not going to be useful to most people isn't the best idea.
859
« on: March 04, 2012, 02:51:53 am »
I think in the process of fixing replacements in Axioms in 1.1.0, another bug was introduced. Now, if I reference an Axe command or another Axiom command in my Axiom, I get two copies of the referenced command in the compiled code. 
I thought this bug was gone. Apparently it's not. And it affects the built-in Axe commands as well. For instance, using division in your program will give you two copies of the modulus routine, or using any of the DispGraphs in your program will result in two copies of p_Safety.
860
« on: March 03, 2012, 05:41:19 pm »
I think that relative jumps were included in Grammer because jumping to a label requires searching the entire program for the label at run-time, which can take lots of time. However, jumps to labels in Axe will always be filled in at compile-time and will always be very speedy, so relative jumps aren't necessary for speed purposes. I suggest that you put a label where you want to jump to and Goto the label like a normal jump.
861
« on: March 03, 2012, 05:33:48 pm »
ability to line jump?
If you mean the ability to jump to a line while editing the program, that's not really Axe's job. That's much more appropriate for an external app, like zStart, which I believe already has label jumping.
862
« on: March 03, 2012, 02:40:37 pm »
Not being able to nest preprocessor conditonals is making the development of YAAM a little difficult.  Not having inline preprocessor conditionals adds difficulty as well, but that sounds like more of a stretch. I think that could be solved with regular preprocessor conditionals in macros, but that's probably far down the road.
863
« on: February 28, 2012, 09:54:47 pm »
Axe doesn't really accept A° as much as it simply doesn't reject it. It's not being parsed as one unit, it's being parsed as A followed by °.... Whether Axe throws an error depends if °... is valid. And this shouldn't/can't be changed because one of the (awesome) properties of Axe is its loose syntax that allows for "units" to be linked together without an operator between them. For instance, just one thing that pops in my mind is that such a change would break subroutine calls with one argument like Asub(B). Pretty much, every Axe program I have ever written would be broken, as well as probably at least 25% of others' programs. 
864
« on: February 25, 2012, 07:46:10 pm »
Well I can tell you that clipped lines is on Quigibo's to-do list (I have it right here  ). So I figure if you/jacobly creates a pretty nice line clipping method, Quigibo would probably be happy to include it in Axe. And the people who have been bugging him for native clipped lines (myself included) would be happy as well.  EDIT: One thing you could make in an Axiom is an alternate routine, possibly without clipping, that's optimized to be faster.
865
« on: February 25, 2012, 07:34:56 pm »
Line clipping support!
This is going to be coming in an Axiom that is under development.
Frankly, if you get decent line clipping, I think Quigibo would want to include it in Axe itself. The only reason Axe doesn't have proper line clipping currently is because he hasn't gotten around to making a decently small/fast solution himself.
866
« on: February 24, 2012, 02:25:08 pm »
This is nice runer112. Hopefully this should make things much easier for people.
Does your tilemapper supports shifting more than one pixel in one frame? I mean like in Super Sonic Ball, for example, where you could scroll by 4 pixels at once.
Not yet. But it will. However, it's worth noting that, although vertical shifting by Y pixels will be just about as fast as shifting by 1 pixel, horizontal shifting by X pixels will not. I estimate that it will only be somewhere from 5-25% faster than calling the 1-pixel shift in a loop.
867
« on: February 24, 2012, 01:52:40 pm »
I'm not sure if I'll add animated tile support. The idea behind my drawing method, and what makes it fast, is only drawing tiles as they are shifted in. Having to redraw only a few animated tiles per frame might work. But if a large portion of the visible area was composed of animated tiles, my method would actually start to become slower than just redrawing the entire tilemap every frame.
868
« on: February 24, 2012, 12:00:58 pm »
Looks nice, so you plan to implement grayscale?
Also nice pokemap 
Grayscale is right at the top of my to-do list. Looks nice! Keep it going!
Will do! That's look awesome, I like those optimization ! 
Just a question, what are apperr1 and apperr2 usually ?
appErr1 and appErr2 form a 26-byte section of RAM that you can use as scrap RAM in your programs, because very few things will write to them. As the name suggests, really the only thing that writes to this area are errors, but if an error message occurs, you don't need to worry about your program's data being destroyed because your program will have already quit. 26 bytes was about the perfect size for the amount of data I needed to store, so I chose this as the default RAM area to be used. But, just like everything else in this project, I've planned to make everything customizable. If you want to change the RAM area used for some reason, you can by defining °MR to be something else before including YAAM.
869
« on: February 24, 2012, 01:16:34 am »
I've been planning this project for a long time, and with the recent release of Axe 1.1.2, I can finally begin to make it a reality! YAAMYAAM? How is a vegetable going to help me develop Axe projects?| | YAAM is no vegetable! It stands for Yet Another Axe Mapper, my friend! It is an Axe library designed to make smoothscrolling tilemapping in Axe both fast and easy by providing all the necessary routines for you in an easy to use manner! Instead of having to write your own tilemapping engine to your custom specifications, select the options you want from the built-in variety of options in YAAM and your tilemapper is done! (This will be more true in later versions as I add more features) |
But drawing a whole unaligned tilemap every frame is slow! I don't want my game to be slow!| | Au contraire, YAAM makes scrolling tilemaps very quick by shifting the previous frame's tilemap and redrawing only the tiles shifted in, which is quite fast. If the tilemap doesn't shift between frames, you don't need to redraw it at all! |
That sounds cool! What other cool features does it have?| | Here, let me draw you up a quick list:- Very fast tilemap shifting
- Handles all drawing and shifting through a few easy to use routines
- Works with any tile size up to 8x8
- Works with any map width and height
|
But I want this feature! And fix this bug!| | For any feature requests and bug reports, just post them in this thread. However, I am already planning many features for the future, so your feature request may actually already be on my to-do list:
|
Awesome! Where do I get it? How do I use it?| | Easy there, one question at a time! The latest version of YAAM (v0.2) can be found attached to this post. It requires Axe 1.1.2. Download the zip file, send YAAM.8xp to your calculator, include it anywhere in your program, and you're good to go!
Full usage details can be found in the included readme. No they can't, because I haven't written one yet. However, I have included a sample program using YAAM that should detail the basics of using it. You can also learn more about YAAM's options and variables by looking at the options section in the library itself, which has small comments to generally explain what everything is. To set constants like tile width and height to your own values, redefine these values before including YAAM. To set everything else like tilemap size and pointers, store values to the variables listed after including YAAM. |
More features will be coming soon!
870
« on: February 21, 2012, 02:54:56 pm »
Would it be possible to, when axe is compiling/zooming a program and it encounters an error, go in and edit the program then when you quit the editor go back to continue or restart compiling/zooming?
This might not be practical for large bug fixes or whatever, but for things like physics tweaking and the like t would be useful
Not sure if it would be a compile option or certain key, tho..
I'm about 90% sure that this is impossible without Axe installing extra hooks, which Quigibo does not want to do. I know that you originally suggested this idea in the zStart thread, and I believe that was the correct place to request a feature like this. I also believe that thepenguin77 is already planning to implement this feature in zStart. He is just waiting for the next version of Axe, which should handle compile errors better from API calls, and then he can add this.
Pages: 1 ... 56 57 [58] 59 60 ... 153
|
Show Posts