Show Posts

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.


Topics - harold

Pages: 1 [2]
16
Math and Science / Pressure Checkerboarding
« on: November 23, 2012, 06:13:26 am »
I wrote a simple fluid simulator with a co-located grid for pressure (it seemed the easiest way to do it), and the thing I'm simulating can't use artificial velocity dampening (I'm simulating objects that move through air, it would be weird and improper if the air speed dropped towards one end of the screen). So I got pressure checkerboarding.

I "solved" that by sampling at 1.2 pixel offsets in all four directions (instead of the usual 1.0) in the jacobi iteration. That works because it samples into the pressure squares (of the checkerboard) and immediately smears them out, so they average out with their neighbours for the most part.

But what did I actually do in terms of physics? Does this violate any laws?

Also, slightly off-topic, there are some really bad effects caused by the fact that pixels are square - everything that isn't an axis-aligned line looks like a "stair" and it messes with the pressure. Is there some way I can easily simulate a smooth surface?

17
Introduce Yourself! / Not really new, but
« on: November 21, 2012, 04:59:01 am »
I've been around, of course, but I'm planning to suddenly get way more active.

Why, you may ask? Because other places are getting increasingly unpleasant.

A common pattern is asking a question about performance only to get a dozen replies saying that performance is irrelevant and you shouldn't care about and "we're not going to answer you until you prove you actually need performance". Pretty much guilty until proven innocent.

Also, I never received that bag of peanuts, so this topic is totally necessary :)

18
Other / Realistic Mecha Tech
« on: October 14, 2012, 04:52:06 pm »
With robotics being what it is today, why aren't there giant mecha's yet? So I started thinking, can we build them right now, with current tech?
And I haven't really encountered that much trouble, but then again, what do I know.

So here's a rough outline of my current idea, feel free to poke holes in it or, preferably, suggest something better:

Based on the following, I went for an "all-electric" approach:
- hydraulics: not too bad speed/strength, but angular range of motion of a joint is terrible. Acceptable precision.
- pneumatics: very fast, can have speed and precision trouble and the range of motion is still terrible.
- mechanical drive (connecting actuators to the main engine with pushrods or pulleys or whatever) is probably the worst option.
That leaves an option which doesn't seem to bad: electric torque motors everywhere. With a large radius, and active cooling (fluid-cooling for the high power parts such as knees, hip, elbow, shoulders, air cooling elsewhere). I did some calculating, and with current tech you can easily make your mecha strong enough with torque motors. I know, it's weird. But let's see:
Let's take one from this list, just to prove the point: http://www.etel.ch/torque_motors/TMB
A diameter of 80cm is acceptable for a 5 meter tall mecha (that sticks out only 40cm at each side of the joint, and that doesn't look as bad as you may think it does), so let's take the strongest one of those: 6.4KNm continuous, 11.2KNm peak. Let's put in the most demanding place, the knee, and assume a worst case angle of 0 degrees, and assume both leg sections have a length of 1.2 meter. That means your mecha can weigh about 550kg. WTF? Not good enough! No, but no one said you had to use just one. While it has a diameter of 80cm, it has a width of only 15cm. You can easily use three (or heck, why not four), giving you a max weight of 1600kg. That's more like it, and remember: you don't do this. This worst case corresponds to squatting on one leg. Why would you do that? You actually have two legs, and you're not even going to squat to zero degrees when preparing for a jump - and when you're jumping, you can turn the dials to eleven and use peak-torque, which is nearly twice the continuous max torque. Unless my physics suck (not entirely out of the question), this will work out just fine in terms of raw strength. You should be able to jump, run, climb and throw one hell of a punch.

Then there's the issue of power supply. Carrying around a generator and a flammable liquid works alright and is the usual solution, but if you look into Aluminium-Air batteries there is something to talk about there too. Alu-Air batteries have a lower energy density (9MJ/kg according to some sources) than, say, diesel fuel (45MJ/kg), but that's not the only factor. For Alu-Air, you don't have an engine and a generator, and that space is not insignificant - you'd need a pretty sturdy engine and generator. Also, being a battery, mechanical failure is unlikely unless moderately damaged, and it works great under non-constant load, which is what you'll have in a mecha - running, jumping, punching, etc? Such great bursts would require energy storage to smooth out if you went for a combustion motor + generator (unless you used pneumatics, which I chose not to).

Slightly into future-tech: both battery tech and electric motor tech are improving as we speak. These are active area's of research. If it works well enough now, imagine how well it will work a decade from now, or even just with the latest research models.

Now, the controls. They have been subject of much debate. Those "hands and feet only" style controls (joysticks and pedals, seriously?) don't offer nearly enough degrees of freedom - the entire idea is to have a tactical unit that can do whatever the heck, not just a "tank with legs". I think the best option here is keeping most of the body immobile and sensing the muscles of the pilot. That also lets you give the mecha more flexible joints than the pilot has - it senses which way you want to move a joint at what strength, not where you want to have it, so it could easily "go further" than a human joint. That's also no problem at all for a torque motor. It shouldn't be too hard to train for that. Taking such direct control also means you don't need very complex "walking algorithms" and systems to keep balance - the pilot should be able to do it himself, using his natural instincts, feeling for balance, and some training.
We're not quire there yet with reading input directly from the brain, but we're eerily close. That's the sort of tech no one knows exists - it does, but it hasn't, to my knowledge, been miniaturized yet, and the response times are bad.

That works great for legs and arms, but not so much for hands. There, you'll want tactile feedback, and that sort of tech already exists as well. Also, you'll need some way to control "other stuff" (turn night vision on and off, climate control, weapon systems, etc). So I propose that your left hand (or right, if you're a leftie) doesn't control a robotic hand but instead manipulates a touchpad. That makes the left arm of the mecha a good place for fixed weapons (no lasers yet, but a nice gatling gun should work), which may seem odd at first, but you'll get used to it, and you could still hold a weapon in your right hand. I'm not 100% satisfied with this approach though, so if you have a better idea, that would be great.

Sensors (vision etc): you'll want this to be good. I'm thinking stereoscopic projection on the eyes, with extra info overlaid (also the virtual buttons and stuff that your left hand manipulates, if you can't see them you can't find them), looks around when you turn your head. And you know the drill: can zoom well, can draw boxes around targets, has infrared mode, and generally tries to provide useful information without getting in the way. That already exists, too.

So, thoughts? Is this even on the right track?

19
Computer Programming / [x86] Hiding the Else in a NOP
« on: August 14, 2012, 01:46:39 pm »
I'm trying to implement 0x8000000000000000 >> nlz(x) well.

What I came up with might be a bit unorthodox:
Code: [Select]
 mov r11d, 1
  bsr rcx, rax
  jz _iszero
  shl r11, cl
  .db 0F, 1F, 80 ; nop [rax+sdword] with the sdword being the next shl
_iszero:
  shl r11, 63  ; 49 D3 E3 3F so 4 bytes
Because BSR is retarded and returns something useless when the argument is zero, I have to handle that case with a branch. But this gets rid of the branch I'd otherwise use to skip the second shl.
An other way to do this is shl-ing by 63 in all cases (or it could be a 64bit mov) and then shr back in the nonzero case. That means xor-ing the result of bsr with 63 though - not a disaster, but more instructions.

Is there any reason not to do it this way? (besides "maintainability", I'm the only person who's ever going to read it anyway and I certainly know what this means)
Any unexpected slowdowns on some micro-architectures? Are trace caches OK with this?
Is the other way I described better?

20
ASM / Binary Puzzle solving/generating
« on: March 26, 2012, 07:31:26 pm »
Binary puzzles.

I will update this post with the fastest ways to solve, count or generate them, and any sub-problems of those.

Detect duplicate columns (needed at the bottom of the search tree for a brute-force solver)

Jacobly:
Code: [Select]
    ; Returns NZ if there was a match
            ld hl,matrix
            ld d,$08
    outerloop:
            ld bc,$0801
    innerloop:
            rlc (hl)
            sbc a,a
            xor (hl)
            or c
            ld c,a
            inc l
            djnz innerloop
            ld l,matrix&$ff
            inc a
            jr nz,found
            dec d
            jr nz,outerloop
            ret
     
    found:
            ld c,8
            dec d
    foundouterloop:
            ld b,d
    foundinnerloop:
            rlc (hl)
            djnz foundinnerloop
            inc l
            dec c
            jr nz,foundouterloop
            scf
            ret

Detecting more than 4 zero's in a column or more than 4 one's.
(no entry)
I used this pseudocode:
Code: [Select]
int colc = 0x33333333;
int colcn = 0x33333333;

solve:
    int newcolc = colc + unzipToNibbles[row];
    int newcolcn = colcn + unzipToNibbles[row ^0xFF];
    if ((colc | colcn) & 0x88888888)
        more than 4 ones or zeroes
    else
        solve(newcolc, newcolcn)

more tomorrow, I have to go

21
ASM / BIT n,(HL) flags
« on: November 24, 2011, 11:33:41 am »
BIT n,(HL) sets some nice flags, including of course flags 3 and 5.
It takes the values for 3 and 5 from an internal register, that among other things holds:
- the original H after ADD HL,xx
- the upper byte of PC after a JR
- the upper byte of IX+displacement after at least some instructions that use IX+displacement

My question is, does anyone have a more complete list?

22
Math and Science / Interval arithmetic questions
« on: August 07, 2011, 12:07:34 pm »
I'm doing some interval arithmetic, and I can't seem to find the answer to this:

When adding two intervals where one of them is empty, what is the result?
For example, [a, b] + {} =
  • empty
  • [a, b]
  • undefined
  • ????

23
Other Calculators / z80 opcode usage stats
« on: July 31, 2011, 09:49:28 am »
I did a primitive order-1 frequency analysis of z80 opcodes as used in TIOS.
It's pretty useless really, but it shows some interesting things.
For example, it's clear that control flow instructions are particularly popular.
Also, there's a general bias towards low values. This bias is much higher for immediate values (as in ld a,imm8 and cp imm8)
Perhaps something to keep in mind when writing a compressor for programs.

24
What do you all think, should it be done?
I see some good and bad things about it, for example
good: faster than basic, smaller than asm, almost no code size limit (could be run from archive and non-executable ram)
bad: it will take a year before a program starts even with lots of lazy loading, requires the 'runtime' to be installed (embedding it in the program would negate pretty much all benefits), hard to debug code generation bugs

25
Miscellaneous / My Little Pony: Friendship is Magic
« on: July 20, 2011, 01:25:15 pm »
I see no mention of ponies anywhere! This has now been corrected.


26
I don't know how many people here use C# (not many, going by the Programming Help topics..)
But this might be interesting anyway.

SharpAsm is a small library I wrote that lets you write a function in assembly and use it directly from C#.
It's very easy to use, for example:
Code: [Select]
Asm asm = new Asm(@"
    bsr rax, rcx
    ret");
Log2Delegate fastLog = asm.GetDelegate<Log2Delegate>();
// now use fastLog like any normal delegate
Obviously assembling the code takes a little time. When I use this library, I usually create all asm routines in a static constructor and then keep reusing the same delegate for all instances.

Source (the assembler): http://dl.dropbox.com/u/27035142/SharpAsm/Assembler.cs
Source (executable memory manager): http://dl.dropbox.com/u/27035142/SharpAsm/ExecutableMemory.cs

The assembler uses string manipulation instead of actual parsing, and is kind of kludgy. It also doesn't include all opcodes and doesn't always use the smallest encoding (eg not the special eax forms).

edit: almost all of SSE, SSE2, SSE3, SSSE3 and SSE4.1 is now supported. Just redownload the files. Please report any bugs .. if anyone actually uses this (uhm no)

Pages: 1 [2]