After looking around the internet, I came across something that's just so much better than what the doctor's office is stocked with. You know, the poor as hell scales that don't even describe what sort of pain you're going through. You can find the posting here at Hyperbole and a Half. If you are or know a med student, they'll get a laugh out of this, then carry it around for its sheer utility.

I also took the liberty of formatting it to fit on a letter-sized paper.

Sorry there hasn't been an update in ages. The resource table thinger is kicking my butt... and I felt kinda burnt out on the project in the past week or so. I'm gonna try to pick it up later "tomorrow" (technically today) and see how far I can get into a test scenario. I mean, pulling together a miniature file system isn't the easiest thing in the world, but who knows how things'll turn out.

I personally want to pet a blue lobster, because they just seem so awesome. And I want to discover if blue lobsters actually like (or at least will eat) cherries.

[...]
Also on a less serious note, be careful with that blue lobster so the PETA doesn't get on you.

PETA isn't the organization that you ought to be worried about. It's The Infamous Lobster Army that you need to be afraid of. Remember, he's got eyes everywhere, and he's waiting for the one chance to use his death-whiskers on an unsuspecting individual caught disseminating the idea of lobster cruelty among the masses. See this post for more details.

[...]
Also it's always good to backup outside your home too. Imagine you got backups on CDs, flash drive, computers, calculators, but then a tornado or hurricane tear everything apart?

These days, I happen to keep a running backup of the very important projects like E:SoR and CaDan on an off-site FTP account. The primary purpose, admittedly, was to share source material with geekboy in a somewhat primitive manner, but it serves its righteous purpose as an off-site backup as well. And can also serve as a possible place to make a site for CaDan, but geekboy is the guy who's doing that job.

No matter how many local backups you make of your stuff, you can end up losing it all in a natural disaster. Since stuff like that happens rather rarely (areas where it's common do not apply unless your place isn't hardened against stuff like that. Example: Earthquakes in California), you don't think it could happen to you, but it could happen, and you will be thankful that not everything that tied you to this world was where your local stuff was at. I've got to worry about a tsunami wiping everything out, and if I happen to survive, first thing's first. Make sure my friends and family are alive (sorry guys). Second thing for me is to figure out how to get into contact with the community and tell everyone I'm just fine. People here on Omnimaga actually care about your well-being, which also makes this place one of the best communities out there. Is this a revelation for some? We do actually stick together and we worry about people when bad stuff happen.

Point is, once you get back on your feet and feel like you're ready to code again, you're gonna wish you had a reliable backup other than what you had at ground-zero. More power to you if you happen to have extremely damage-resilient flash drives, or indestructible CD/DVD's, or perhaps your information was stored on a Toughbook®. Maybe you had none of these and you're just SoL. Nobody wants to be there.

Although not feasible for most people, having a group of people working on your project, especially a group whose geographic locations are wildly varied, can help protect your project, since you're likely going to distribute source among your trusted online and/or IRL friends. Having multiple backups everywhere is simply a side-effect of the group effort that's happening with your project.

Even if you had local backups, do you make sure that your backup device is not connected to any source of power or plugged into anything that has a source of power? What happens if lightning strikes and your "backup" flashdrive is still connected to your computer even though you aren't using it at the moment? What happens if you had an SD card in your computer at the time? An external hard drive? Forget about your internal hard drive, that's fried. The answer is that everything is fried, and possibly your CD inside your CD/DVD-ROM drive too if you get a hard enough jolt (though if that happens, you've probably got more to worry about than your data...)

And, finally, what happens if the worst were to occur? Some terrorist builds and lets off an EMP and destroys all your (along with everyone else's) electronics? Sure, you're gonna have more to worry about than your data, but still. I actually happen to have flash drives inside a tin (which *should* shield against that sort of thing) for that very purpose. Call me paranoid, but I like to have data intact, and I'm sure you do too. Plus, you're not going to lose those flash drives if they're in something large enough to be seen in the room, so you get that benefit. I mean, what good is a backup if you can't even find it?

tl;dr: Have convenient off-site backups in multiple geographic locations. Make your on-site backups disaster-resistant. Just in case the world ends. If you're paranoid, choose the four corners of the world as your backup sites. And your bank's safe-deposit box.

As a Z80 ASM coder, I thought I should share this one experience when I changed over my OS from Vista to Win7.

I thought I had backed everything up by moving all of my project files which was on the desktop to the other partition (I have two partitions, one for the OS and one for all the other data), and I forgot to back up the reboot of Celtic 2, which I worked on for about a week up to that event.

When I went back to put the backed up files onto the shiny new desktop, I realized that I copied "CaDan2" and not "Celtic2". You'd think I would've caught that but it didn't happen until too late. I was having problems just dragging and dropping files into the backup shortcut, the damned thing was running so slow before I went to reinstall. Hell, it took over two hours just to get to see my desktop before I changed over my installation. I was getting rather impatient, but that ended up costing me in the end. I had absolutely NO backup of the revised Celtic 2 project.

When I went in to try to recover the files using the software "Recuva", it saw the contents of the old filesystem, but I knew my chances of success was slim. I mean, I cleared out an installed an entirely new OS and the chances of any of the files remaining intact was slim.

No such luck. It was overwritten completely by some Win7 component. The only file that was partially recoverable was this postscript file that was generated by Branchmap, which in itself does not contain any source.

In hindsight, I probably would've saved myself loads of time and headaches, and possibly the loss of this project, had I booted up some other OS from a live CD and copied the files that way. I mean, it should not take the same amount of time to make a sandwich to cajole Vista to let me drag a folder across the desktop to the backup folder.

Anyway.

tl;dr: Make sure your computer backups are safe too.

It's true, ain't it?

This is a little late, but...

Quote from: http://ourl.ca/2637/255828

0.o
What's the theory behind that?  I've been trying to get aiming like that working since something like January...

To begin, let us go ahead and set what we mean by "angle". In our nice happy normal lives, we know that there are 360 degrees or 2*pi radians in a circle. We will assume that the zeroth degree is a line starting from the center of the circle drawn to the right most point (the 3 'o clock position). Draw another line from the center out to any other point on the circle and we can measure how far away it is from that starting point. That will be our angle, and it is measured in... wait? What? No, we're not going to use degrees for this. Neither are we going to use radians! Instead, we'll just make up our own unit of measurement. Let's call this a "binary degree" and set the number of these binary degrees that can exist in a circle from zero to 255. Why do we do this? Because it fits nicely in a single 8-bit register and lets us calculate these things faster. After all, we're in it for the speed.

The bullet's path is in polar coordinates, so that means we've got an angle and a radius. Since the bullet's radius is a function of time, we can omit having a radius altogether and just let it fly at a velocity.

To aim at something, you have to ask yourself "What angle do I need to shoot at in order to intersect at the player's position?" To get this answer, you will need an inverse trigonometric function. Given the starting point, which is the enemy's firing position, and the end point, which is the player's position, you have an X and Y. You have three basic inverse trigonometric functions to choose from: arcsine, arccosine, and arctangent. Absolutely FORGET about the other three. When you run your arguments through those functions, you will obtain an angle that you can then use to shoot at the enemy. But wait!

You only have information readily available to use the arctangent function, since it only needs the X and the Y. The other two functions want a hypotenuse (or rather, the radius, which we never kept track of) so they're right out, unless you want to go ahead and calculate them using Pythagorean's theorem. When you need to perform high speed calculations, you don't need to do more than you have to, so now let's forget about arcsine and arccosine. Let's just use arctangent.

So, now we picked our function. We get the angle from arctan(y/x). So now we've got to do division, right? Wrong! CaDan does absolutely no division, at least, not in the way a "normal" person would think of it. In fact, we don't actually do the function at all! Instead, we create a lookup table (LUT) that contains all the coordinates we can input, and have all the angles we need to output. Now, let's go ahead and say right now that we can strip the signs off of the X and Y to make using this table a bit easier. You still need to keep record of what those signs were; we'll need them for later.

For CaDan, since the screen is 64 x 64, I can get away with having X's and Y's go from 0 to 63 (zero inclusive), in such a manner that each column (data in a single row) enumerates all X's given a certain Y, and going from row to row, enumerates all Y's. But such a table, given 64*64, would total 4KB. We do NOT want to spend that much memory on such a table, so let's cheap this one out. We'll pick every 4th value, going from 0 to 60 in both directions. Keep in mind that you can't have 0 as an X value, so you're just going to have to assume that as X approaches zero, the angle approaches 64 binary degrees (pi/2 = 64 binary degrees). In the code box below is such a table, ranging from 0 to 64 binary degrees.

ArcTanTable:
.db 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00 ;|00 00|
.db 64,32,19,13,10,08,07,06,05,05,04,04,03,03,03,03 ;|01 04|
.db 64,45,32,24,19,16,13,11,10,09,08,07,07,06,06,05 ;|02 08|
.db 64,51,40,32,26,22,19,16,15,13,12,11,10,09,09,08 ;|03 12|
.db 64,54,45,38,32,27,24,21,19,17,16,14,13,12,11,11 ;|04 16|
.db 64,56,48,42,37,32,28,25,23,21,19,17,16,15,14,13 ;|05 20|
.db 64,57,51,45,40,36,32,29,26,24,22,20,19,18,16,16 ;|06 24|
.db 64,58,53,48,43,39,35,32,29,27,25,23,22,20,19,18 ;|07 28|
.db 64,59,54,49,45,41,38,35,32,30,27,26,24,22,21,20 ;|08 32|
.db 64,59,55,51,47,43,40,37,34,32,30,28,26,25,23,22 ;|09 36|
.db 64,60,56,52,48,45,42,39,37,34,32,30,28,27,25,24 ;|10 40|
.db 64,60,57,53,50,47,44,41,38,36,34,32,30,29,27,26 ;|11 44|
.db 64,61,57,54,51,48,45,42,40,38,36,34,32,30,29,27 ;|12 48|
.db 64,61,58,55,52,49,46,44,42,39,37,35,34,32,30,29 ;|13 52|
.db 64,61,58,55,53,50,48,45,43,41,39,37,35,34,32,31 ;|14 56|
.db 64,61,59,56,53,51,48,46,44,42,40,38,37,35,33,32 ;|15 60|

To fetch values off this table at a good speed, let's go ahead and align this table to a high byte. Say, this table is to be copied to 0x8000. Now, let's construct the low byte in the following manner: Since the low 4 bits (16 entries wide) represents X, let's shove the X value in the low 4 bits, and since each row represents a Y value, it should be the upper 4 bits, so let's shove that in the upper nibble of the low byte. You set the resulting value as the low byte of the address, then fetch from that address.

And this is where geekboy says it starts getting crazy, but I would like to disagree.
Now that we've gotten an angle from the table, you'll want to notice the values as you approach the axes. See how they're getting rather... granular? That's one weakness to this approach. The angles you get as you approach the X or Y axes tend to suck and your shots will tend to miss simply because it can't aim properly. Especially since we've used a table that doesn't cover every single point, so what do we do? We go ahead and interpolate those values. I sure hope you didn't discard the sign-stripped X and Y values you calculated earlier between you and the enemy. We're going to need those bits you shuffled out in order to use the LUT. In fact, those are the ONLY bits you need for this part. What we're going to do is pick the angle you're at and find the next angle to the right and below you and find out how "close" you are to those angles. In our scheme, we stripped the lowest 2 bits of our X and Y, so that means there are 4 values to choose from. If you're sitting exactly on the boundary in the LUT (those two bits are zero), then you can skip the step for either the X or Y. What you do with those two bits is count how many times you are at the first angle you have, and then count how many times you are away from the next angle, then take the average of that. I like to do the X and Y calculation separately so that I can stick with 8 bit math. When you take a total average, you end up with an angle that is about as close as you can get without actually having to have those values in your table. It's not magic. It's just making a straight line that closely matches the curve, and then taking a point off that line... okay, so we're stretching that concept but hey. It works.

"But wait," you might ask after that hefty paragraph. "That's only one quadrant! I spent all that time listening to you whine on and on about the accuracy of the angle, but I want to be able to aim anywhere!" That's right. You *do* want to be able to aim anywhere within that full circle. Remember when I asked you to save what signs the X and Y were? You get to use those signs to correct what the angle should be. Now, since this is a circle, once you've got one quadrant, you basically have all four of them with just a little bit of manipulation. I'm going to leave it as an exercise to you as to *how* the angle is to be modified given the sign. Here's a hint: With one, you negate the angle. With the other, you add pi (128 binary degrees).

So, all in all... that's the theory. Or explanation. Or whatever.
That's what I do. And the aiming still sucks around the X and Y axes. I mean, it's good enough to not give you a safe spot but still. Not as good as I'd like it to be.

EDIT: I think I forgot to mention that almost all instances of X and Y are supposed to be calculated from your position and the enemy's position, so I suppose that would make it a delta X and delta Y? I dunno.

EDIT2: If you didn't get much out of that, perhaps you could get a little more out of the routine that CaDan uses. Because of the way the routine uses its pointers, it's not necessary to have the arctangent LUT page-aligned. That's just a side-effect of using IX in a manner that ensures compatibility with the Nspire or other half-broken emulators that doesn't support undocumented instructions.

Also keep in mind that the character's X and Y coordinates (in routine's DE) are formatted as (%xxxxxx00,%yyyyyy00) with the lowest two bits being subpixel bits, which aren't used in the calculation. I'm sure I could squeeze a little more accuracy during the interpolation phase if I *did* include those bits, but I did not. Anyway, below is the routine that CaDan uses:
;Warning: Loads and loads of register-juggling ahead.
r.arctan: ;in: HL=(x1,y1) DE=(x2,y2)
 ld b,0        ;initializing...
 ld a,e        ;
 rrca \ rrca \ and %00111111
 sub L    ;y1-y2
 jr nc,_  ;result is negative. Set B for flags (bit 0) and adjust Y for pos.
 set 0,b
 neg
_:
 ld e,a      ;D=Y for later
 rlca \ rlca ;shifting so that %00yyyynn is %yyyynn00 for later. n matters not
 ld L,a      ;half-result in L now
 ld a,d
 rrca \ rrca \ and %00111111
 sub H     ;x1-x2
 jr nc,_   ;result is negative. Set B for flags (bit 1) and adjust X for pos.
 set 1,b
 neg
_:
 ld c,a    ;C=X for results later
 rrca \ rrca ;shifting so that %00xxxxnn is %nn00xxxx. n still matters not.
 xor L     ;combine with Y
 and $0F   ;mask out to keep old X low bits
 xor L     ;and we have %yyyyxxxx
 ld L,b    ;saving flags into L for now.
 ld h,e    ;restore H for... stuffs
 ld ix,ArcTanTable
 ld e,a
 ld d,0
 add ix,de ;We have our offset now.
;So at this point, C=X, H=Y, L=flags.
;Let's go ahead and do X-interpolation first.
 ld a,c
 and %00000011 ;value-ranking
 ld c,(ix+0)   ;storing non-adjusted "output" value into C
 jr z,r.arctan.skipx
 ld e,a  ;Loop for second half of X interpolate
 cpl     ;ranking first value on inverse of distance to next number
 add a,5 ;So 1=3,2=2,3=1
 ld b,a
 xor a
_:
 add a,c
 djnz -_
 ld c,(ix+1)
 ld b,e
_:
 add a,c
 djnz -_
 rra \ rra
 and %00111111
 ld c,a       ;out by the time we're done with everything.
r.arctan.skipx:
 ld a,h
 ld H,c     ;H=InterpolatedX
 and %00000011 ;value-ranking
 ld c,(ix+0)   ;storing non-adjusted "output" value into C
 jr z,r.arctan.skipy
 ld e,a  ;Loop for second half of Y interpolate
 cpl     ;ranking first value on inverse of distance to next number
 add a,5 ;So 1=3,2=2,3=1
 ld b,a
 xor a
_:
 add a,c
 djnz -_
 ld c,(ix+16)
 ld b,e
_:
 add a,c
 djnz -_
 rra \ rra    ;Also trying to get any leftovers from too many values of 64
 cp 64
 jr z,_
 and %00111111
_:
 ld c,a       ;added. Since 64*4 is a 9 bit number, getting that back.
r.arctan.skipy:
 ld a,c
 add a,H
 rra
 cp 64
 jr z,_
 and %00111111 ;and NOW we have our final angle. (if it wasn't 64...)
_:
 ld b,0        ;Set to 128 if X is negative. For additions later on.       
 bit 1,L
 jr z,_
 ld b,128
 neg           ;negate angle
_:
 bit 0,L
 jr z,_
 neg           ;negate angle again if (-,-) else first neg. Still correct :)
_:
 add a,b       ;completing the angle
 ld c,a        ;saving the completed angle to C
 ret

EDIT3: If you're trying to get a routine like this to work on a 96x64 buffer, I could suggest doubling your area by halving the input X/Y coordinates. There will be some loss of accuracy, but if you're putting this in a game where your "hitbox" is the full 8x8 or larger sprite, then this won't be much of a concern. In fact, I don't think there will be any concern now that with a 128x128 firing range in all directions around the sprite (256x256 total area), then you could safely fire from off-screen. The angle that is output will be all the same.

If you somehow need the radius as well, I'd consider saving whatever's in C and use Pythagorean's Theorem to obtain the radius. You'd just double (square) the X and Y, add them together, and then pass that value through some sort of square root algorithm. You can find a good routine that does square roots around here: http://baze.au.com/misc/z80bits.html