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 ... 98 99 [100] 101 102 ... 135
1486
« on: May 17, 2010, 10:13:06 pm »
I'm not going to make a separate version because I need to keep consistency with the new version.
The XOR thing you were talking about, the efficient way is simply this: 1-{L6+A}(r)->{L6+A}(r) since adding one to the negative is the same thing as the complement. I think I will have the not() command do this more efficiently in the future though.
1487
« on: May 17, 2010, 09:27:32 pm »
That code isn't hard to follow at all, and its not very complex. But I have a feeling what your teacher is complaining about is that you made it very "C style" instead of "C++ style". They want to train you to stick with the C++ commands and not do those efficient workarounds becasue eventually you're going to be dealing with abstract objects and your code will no longer be portable when instead of strings you have classes and instead of characters you have child objects.
1488
« on: May 17, 2010, 09:20:39 pm »
The only way to make it look cleaner is to update the screen more often between frames (slow it down) becasue 4 bit gray needs to be drawn in the same place for 3 frames to guarantee a cycle through all the gray. That's becasue the pixels stay black for 0,1,2, or 3 times during the duration of 3 frames to get the white, light gray, dark gray, and black. By contrast, 3 bit gray only needs to be drawn 2 times between frames for a smooth animation (but still, more looks better). That's why most 4 color grayscale games, like desolate, don't generally feature a lot of motion at once.
1489
« on: May 17, 2010, 09:09:48 pm »
Sure, use as many as you want.
1490
« on: May 17, 2010, 09:07:51 pm »
Yeah, they're still bitwise, just now they're only 8 bit instead of 16 bit. Have you tried compiling? It should still work if you were only using low bits.
1491
« on: May 17, 2010, 02:37:41 pm »
Actually, the 4 level grayscale is this pattern:
11011010
10110101
01101011
11010110
10101101
01011011
10110110
01101101
In the one you posted, there are the same number of 0s as 1s in the 3rd and 6th columns making those pixels medium gray instead of dark gray. This pattern can also be inverted bitwise for light gray.
1492
« on: May 17, 2010, 02:28:00 pm »
Oh, are they just simple non-executing data? Much simpler! You can create variables in ram instead of in the rom (as long as they fit there) by just defining them to be there. If they need to start initialized with some value, just make sure you initialize it all at the beginning of the program. I also have a macro for variables:
#define VAR(name,size) name: \ .org name+(size)
This creates a variable of any size at the current .org position. I usually define them at the end of the program, but you can put them in the beginning too.
;Program goes here
ld a,(timer)
ld (score),hl
;End of program
;You can use any safe ram for this. This is where the variables get stored.
.org appBackUpScreen
;Declare all variables and appropriate sizes
VAR(timer,1)
VAR(score,2)
;This allocates 1 byte to the timer variable and 2 bytes to the score variable.
1493
« on: May 17, 2010, 02:40:50 am »
Amazing work, Quigibo. That was a impressive optimization. 
Is there any main optimizations like that left? 
There are many more left. I only did the most basic of basic look-ahead parsing technique. Another major optimization will be looking ahead to see if arguments are constant or variable expressions when compiling. Right now, expressions after each argument are saved as a precaution becasue later arguments might use longer routines that scramble the registers. But if I can guarantee that all arguments after that point are constant, then I don't need to do all that useless saving. @DJ, your code probably was optimized. I had to make the sprite drawing routines slightly larger to accommodate grayscale, however at the same time, there were a couple places that got optimized so it just happened to balance out coincidentally.
1494
« on: May 17, 2010, 02:26:21 am »
Yeah, I get those all the time. Once when I was dealing with interrupts, I forgot to save the ix register in my interrupt code and so the program would occasionally start doing some cray stuff and I couldn't find the error anywhere and it took me at least a week to find it after disassembling it line for line and finally realized there was no error.
When I say "outside the main program" I just mean anywhere in the ram, you wouldn't want to write it to a program or any user variable. It gets confusing becasue you have to change your pointers around when making absolute calls, jumps, and loading and saving from ram since the locations are different than your code. Fortunately I have some very useful macros that I used in pyoro to simplify this:
;Use this instead of a label in any code that is to be copied somewhere else.
#define MAP(name,src,dest) name = ($+0 - src) + dest
;This is just a simple copy routine
#define COPY(src,dest,size) ld hl,src \ ld de,dest \ ld bc,size \ ldir
Here is it used in a useless example before and after:
BEFORE
call ClearScrn
ClearScrn:
inc a
dec hl
smc_Gray= $+1
ld a,%10101010
rrca
ld (smc_Gray),a
ret
After
;This should be in the beginning of the program
SMCram = appBackupScreen
COPY(SMCrom,SMCram,SMCromend-SMCrom)
;This is how you call the routine (same as before)
call ClearScrn
;This is the routine that will get copied to ram
SMCrom:
;Other SMC code can go here
MAP(ClearScrn,SMCrom,SMCram)
inc a
dec hl
MAP(smc_Gray,SMCrom,SMCram)+1
ld a,%10101010
rrca
ld (smc_Gray),a
ret
;The rest of your SMC goes here
SMCromend:
1495
« on: May 17, 2010, 01:53:06 am »
Sure thing! I also included a list of some of my macros since I think I use a few of them in my routines.
1496
« on: May 17, 2010, 12:42:34 am »
The doc only mentions appvars, programs not supported yet.
The calculator uses a separate call for creating appvars, programs, lists, etc. I can easily add support for those, but I'd have to change the routine so it calls the correct bcall depending on the variable type. The only problem is that it kind of bloats the size of the command. If I split it into separate commands, or with modifiers, there would be too many possibilities and it would be confusing and hard to memorize. I'll figure out something soon though.
1497
« on: May 16, 2010, 07:07:21 pm »
oh yeah I for got about that lol.
1498
« on: May 16, 2010, 12:01:56 pm »
The simplest way to fix it is to turn it into an app, that gives you a 16kb executable limit instead of 8. Revsoft is down right now, but I think someone might still have a copy of wabbitsign you can use. The only consideration is that you can't have self-modifying code in an app. If you do, you have to copy that code to the ram and call it there instead of directly in the app.
1499
« on: May 16, 2010, 03:41:14 am »
Copying all those grayscale sprites took as long as writing the update almost  Even though grayscale was the main focus of the release, I've found that I've significantly decreased program size with the look-ahead parsing, it was surprisingly simple to write. I also found a part that was supposed to be optimized but never was in the previous versions and just went unnoticed. Well, I fixed that too. Just an explanation for look ahead... there is a situation that you will never be in, but you might think its a bug if you try it. Its intentional. Whenever you add or subtract a constant to a pointer like: L1+5, it automatically groups this into a single pointer (L1+5) to minimize runtime calculations. Constant + Constant = Constant so now it just replaces the number with what it should be before it compiles. But, that changes the order of operations if you were to do some other operation on the left of the pointer. Like 2*L1+5 is actually 2*(L1+5). But you'll never end up doing that really becasue the only operation you ever do to pointers is addition and subtraction anyway. As an example, Builderboy's Portal X code shrunk by about 6% (almost 500 bytes) with these optimizations alone.
1500
« on: May 16, 2010, 03:28:51 am »
Axe Parser
Beta 0.2.4
One word to describe this release: grayscale! New Features:- Draw pixels to the back buffer (grayscale)
- Get pixels form the back buffer
- Draw sprites to the back buffer (grayscale)
- 4 color grayscale rendering
- Draw ANY buffer directly to the screen without having to copy it to the main buffer
- Look-ahead parsing significantly reduces code size when using static pointers
Changed:- A couple new auto-opts for "is negative" and "is not negative" .
- Fixed bug with Cos( Sin( and square root as second argument
- Fixed bug with >Frac and >Dec when last line was a pointer.
Cool new example program to test 4 color grayscale.
Pages: 1 ... 98 99 [100] 101 102 ... 135
|
Show Posts