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 - Quigibo
Pages: 1 ... 27 28 [29] 30 31 ... 135
421
« on: May 27, 2011, 06:50:38 pm »
It would certainly optimize with expressions though, even with 2 byte variables. For example:
{A*12+B}r+1->{A*12+B}r
Can definitely be optimized with increment operators. The r and the end of the brackets can tell the parser whether or not to use a 16-bit increment or an 8-bit one. Variables are always assumed to be 16-bit, but you can still do the more optimized 8-bit increments via {oA}++ This is definitely a feature you will see soon.
422
« on: May 27, 2011, 02:42:58 pm »
Axe actually did use shell routines for at least one version. The only one I could find to be "compatible enough" was ion's pixel drawing routine. But it was significantly slower than my own routine so I took it out. My original vision for Axe was that I would be able to use shell routines to significantly reduce code size and it would be happy and magical. Unfortunately I never realized how specialized and super optimized Axe's routines are compared to the shell calls so that kind of died out pretty quickly. Runer's comparison of Axe's fastcopy with Ion's fastcopy is a good example of how many of the shell routines went when I tried to add them.
423
« on: May 26, 2011, 08:40:56 pm »
I actually have a copy of the routine you poster earlier and it was a bit more optimized so no worries 
424
« on: May 26, 2011, 08:31:35 pm »
Right, but an inverse can use a standard 16/16 division instead of a 24/16.
425
« on: May 26, 2011, 08:27:08 pm »
I'm not planning to add 8.8 division. I think just multiplying by the inverse should work with enough accuracy.
426
« on: May 26, 2011, 04:20:15 pm »
It would also allow me to give a compile error now when you go over the limit. Currently I can't do that because I don't know how much is data and how much is code.
427
« on: May 26, 2011, 02:22:21 am »
Anyone up for some math? I want to implement the reciprocal function for fixed point math. For 8.8 numbers, A -1 is essentially just E10000//A however that division requires a number larger than can fit in a register pair. Ideally, the routine could hijack a jump point into the current division routine instead of rewriting another one. But its possible due to the symmetry involved that there might be a significantly optimized method using a slightly different approach, but I can't think of how that would work. Has anyone seen or written a routine like this before?
428
« on: May 25, 2011, 11:38:12 pm »
It would be too difficult to make passes optional because that stuff is hard coded. The break key is a great idea though, I think I will make the [On] key break compiling and clean up unfinished files so that if you accidentally compile a huge program for the wrong shell or something, you don't have to wait a minute for it to compile just to delete it and compile again.
429
« on: May 25, 2011, 11:16:41 pm »
Its way easier to make the compiler (assuming you already have a working assembler) and it allows you to hand optimize the code really easily if you want to since you can get an assembly output. But Mimas wasn't around at the time I started Axe so that wasn't an option back then.
430
« on: May 25, 2011, 05:18:49 pm »
Its direct to machine code. Although sometimes, its slightly indirect with placeholders that get filled in later, but usually its direct. And its not a stupid question, most computer compilers actually DO do that. I would have in Axe too if there was enough memory, but unfortunately there isn't.
431
« on: May 25, 2011, 05:04:10 am »
On the subject of passes, I could also have a 4th pass to relocate all the data after the builtin subroutines to allow shell compatible programs to break the 8kb executable limit more easily.
432
« on: May 25, 2011, 01:18:47 am »
Yeah, like I said, if I add pause to the loop, it looks better (pause 11 is perfect gray). But my point is that I'm not sure anymore if having the routines row major is actually an advantage because the old routine produced just as perfect a gray when it was in sync yet it didn't have graphical problems when it wasn't. This routine seems less resilient to changes in the pause time.
Maybe my calculator is just the exception though, I don't know what the statistics are for what percentage of calculators have bad LCDs. Regardless, I don't think any single routine can produce perfect gray across ALL calculator models. So I think I should just forget about column/row ordering and just stick with the smallest, fastest routines.
433
« on: May 24, 2011, 10:46:57 pm »
Really? Wabbitemu accepts it fine for me... It was just your routine replacing the current 4 level grayscale. Random squares were drawn to each buffer and then it did a "Repeat getkey(15):DispGraphrr:End" loop.
434
« on: May 24, 2011, 09:22:01 pm »
Sorry for the late response, this is how the program looks on my calculator (see attachment). I'm pretty sure it has nothing to do with the delay being too short since it looks better when I add more pause between each DispGraph.
435
« on: May 23, 2011, 06:59:41 am »
Runer, I was testing out your 4 level grayscale routine and I'm getting some really weird results. Its literally showing black and white lines across the otherwise perfect gray that shift about every second. When I add some pause between displays, it looks better, but still not as good as the column major routine. The emulator makes it look fine, so I can't upload a screenshot, but try this upload on hardware.
Pages: 1 ... 27 28 [29] 30 31 ... 135
|
Show Posts