I'm working with memory locations in Hex and I'm having trouble subtracting two Hex numbers. I tried watching tutorials on YouTube and I'm still stuck.
My memory locations are 0x120, 0x 118, 0x110, 0x 108, 0x100
Subtracting 0x118-0x8 seems simple enough: 0x110
How do I subtract 0x120 - 0x8 ? I know the result is 0x118, but I'm not sure why.
Thank you for your help.
It is simple as follow ( 0x010 = 16 ):
0x120 - 0x8 =
(0x110 + 0x010) - 0x008 =
(0x110 + 0x008 + 0x008) - 0x008 =
0x110 + 0x008 = 0x118.
Related
I'm looking for a formula to calculate the RGB of a new color, based on the opacity. Of course, there's already an answer for this (i.e. Calculating opacity value mathematically), especially this answer:
The formula for combining C1 = (R1,G1,B1) and C2 = (R2,G2,B2) into a new color C3, where C2 is overlayed on top of C1 with opacity p is usually ( (1-p)R1 + p*R2, (1-p)*G1 + p*G2, (1-p)*B1 + p*B2 ).
This is great, it works, I get the correct value. However, I need a reliable source for this formula, which I cannot find. Sure, that answer has an link to Wikipedia, which again lacks the source.
If there's any other formula for calculating the color based on the opacity value mathematically and there's a reliable source for such a formula (e.g. book or scientific paper), feel free to share it.
Thanks!
Thanks to anyone who helped. I actually found the answer in this link: http://jcgt.org/published/0004/02/03/paper.pdf
It's a (semi)scientific paper, and the formula is as follows:
Aα * Ac + (1−Aα)*Bα*Bc / Aα + (1−Aα)*Bα
I've tested it on this scenarios:
rgb_div = (80, 85, 250); opacity = 0.2
rgb_bg = (100, 205, 30); opacity = 1
new color = (96, 181, 74)
There is a commonly used verlet-integration formula on the web by Johnathan Dummer, called Time-Corrected Verlet. However I've read several forum posts, that people get weird or unexpected results with it in certain conditions.
Formula by Johnathan Dummer:
x1 = x + (x – x0) * dt / dt0 + a * dt^2
There is also a stackoverflow answer, which states that Dummer's time-corrected formula is broken and the poster presents his own derivation as the correct one.
Suggested correct formula by a stackoverflow answer
x1 = x + (x – x0) * dt / dt0 + a * dt * (dt + dt0) / 2
Well, is Dummer's formula really broken? If yes, is the derivation of the poster better?
PS: It is also weird that Dummer uses the verlet integration formula x1 = x - x0 + a * dt^2 on his website instead of the correct x1 = 2x - x0 + a * dt^2.
The wikipedia page Verlet integration - Non-constant time differences presents the two formula, without referenced. I've not checked the derivation myself but the reasoning for the second improved formula looks sound.
I've downloaded Dummer's spreadsheet and modified one of the formula to use the correction. The results are much better.
The exact results are in yellow, we see that just using the normal Verlet algorithm with fluctuating frame-rate is bad. Dummer's time-correct varient in red is pretty good, but a little off. The dark green version with the improved correction is much better.
For projectiles under gravity which has a quadratic solution you may find that the improved version is exact. When the degree gets a bit higher it will vary from the true path and it might be worth testing to see if we still get a better approximation.
Doing the same calculation for a sin curve shows the improved method is considerably better. Here Time-correct Verlet is drifting quite a bit. The improved version is better, only a little bit off the exact answer.
For the PS. Note that if you set dt=dt0 in the TCV formula
x1 = x + (x – x0) * dt / dt0 + a * dt^2
you get
x1 = x + x – x0 + a * dt^2
= 2 x – x0 + a * dt^2
the original Verlet formula.
The true derivation is based on Taylor formulas
x(t-h0) = x(t) - x'(t)*h0 + 0.5*x''(t)*h0^2 + O(h0^3)
x(t+h1) = x(t) + x'(t)*h1 + 0.5*x''(t)*h1^2 + O(h1^3)
and now eliminate x'(t) from these two formulas to get a Verlet-like formula
h0*x(t+h1) + h1*x(t-h0) = (h0+h1)*x(t) + 0.5*a(t)*h0*h1*(h0+h1) +O(h^3)
which makes a propagation formula
x(t+h1) = (1+h1/h0)*x(t) - h1/h0*x(t-h0) + 0.5*a(t)*h1*(h0+h1)
= x(t) + (x(t)-x(t-h0))*h1/h0 + 0.5*a(t)*h1*(h0+h1)
so that indeed the corrected formula is the correct one.
Note that if you use velocity Verlet steps
Verlet(dt) {
v += a * 0.5*dt
x += v*dt
a = acceleration(x)
v += a * 0.5*dt
}
then each step is indepentently symplectic, so that the change of step size between steps is absolutely unproblematic.
Notice that the main advantages of Verlet and other similar symplectic schemes over Runge-Kutta methods etc. crucially depends on using a fixed step. In detail, the modified energy function (and other more than quadratic constants of motion) that is largely constant under the numerical method is a modification of the exact energy where the difference scales with the step size. So when changing the step size a different modification gives a constant energy. Frequent changes of the step size allow thus, possibly, arbitrary changes of the energy level.
I decided to quit being lazy and show some kind of derivation of how the original Verlet method looks with a variable step size. Because it seems like this faulty adaptation by Dummer is more pervasive than I thought, which is saddening. I also noticed that, as the above answer points out, the correct version is now on wikipedia alongside the Dummer one, though it was added after my "suggested correct answer".
When I look at Verlet method, I see that it looks a lot like leapfrog, velocity Verlet, implicit Euler etc., which look like second-order versions of modified midpoint, and some of them may be identical. In each of these, to some degree they have a leapfrog idea where integration of acceleration (into velocity) and integration of constant velocity (into position) are each staggered so that they overlap by half. This brings things like time-reversibility and stability, which are more important for the 'realism' of a simulation than accuracy is. And the 'realism', the believability, is more important for video games. We don't care if something moves to a slightly different position than it's exact mass would have truly caused, so long as it looks and feels realistic. We're not calculating where to point our high-powered satellite telescopes to look at features on distant objects, or future celestial events. Here, stability and efficiency takes priority here over mathematical accuracy. So, it seems like leapfrog method is appropriate. When you adapt leapfrog for variable time step, it loses some of this advantage, and it loses some of it's appeal for game physics. Stormer-Verlet is like leapfrog, except it uses the average velocity of the previous step instead of a separately maintained velocity. You can adapt this Stormer-Verlet in the same way as leapfrog. To integrate velocity forward with a fixed acceleration, you use half the length of the previous step and half the length of the next step, because they are staggered. If the steps were fixed like true leapfrog, they would be the same length and so the two half lengths sum to one. I use h for step size, a/v/p for acceleration/velocity/position, and hl/pl for 'last' as in previous step. These aren't really equations, more like assignment operations.
Original leapfrog:
v = v + a*h
p = p + v*h
With variable time step:
v = v + a*hl/2 + a*h/2
p = p + v*h
Factor a/2:
v = v + a*(hl + h)/2
p = p + v*h
Use previous position (p - pl)/hl for initial velocity:
v = (p - pl)/hl + a*(hl + h)/2
p = p + v*h
Substitute, we don't need v:
p = p + ( (p - pl)/hl + a*(hl + h)/2)*h
Distribute h:
p = p + (p - pl)*h/hl + a*h*(h + hl)/2
The result is not as simple or fast as the original Stormer form of Verlet, 2p - pl + a*h^2. I hope this makes some sense. You would omit the last step in actual code, no need to multiply h twice.
I am trying to figure out how to solve this problem;
Now make a new sinusoid with amplitude 1 and frequency 1000Hz.
Calculate the dot product of this sinusoid with your complex tone
using vector multiplication between the heterodyne and the transposed
complex tone signal.
So far no good. I have managed to represent a complex tone by:
octave:65> t = [0 : 441];
octave:68> A = 0.25;
octave:69> x = A*sin(2*pi*t*441) + A*sin(2*pi*t*882) + A*sin(2*pi*t*1323) + A*sin(1764*pi*t*2);
And the new sinusoid
octave:66> y = sin(pi*2*t*1000);
Now I find myself trapped with the heterodyne concept and its application. I can tell that the vector multiplication would be like;
octave:75> abs(y*x')
However, parameter 'y' which needs to be the the heterodyne of 'y'(I guess), is driving me nuts...
Any suggestion would be appreciated
Refer to the figure below and this link.
Regarding Figure 2.3, I understand why M (multiplier) and N (multiplicand) are in those orders that are listed in "Partial product..M..L" that's in the rightmost column. It comes from how we were normally taught to multiply:
I understand why the figure is 64-bits long, because it's 32-bits times 32-bits.
I understand the addresses go from P~P+7 that way because the H.O. bit of the final product starts at P and L.O. bit of the final product ends at P+7.
I understand why each large rectangle is split into an upper and lower half, because the HCS12 can only handle a maximum of 16-bits times 16-bits at a time.
My problem: The way each small rectangle (lower and upper halves) are arranged is confusing me. Apparently, it's supposed to mimic the simplified multiplication process, which I can understand how is being done. I just don't understand entirely how it translates into the figure. The link from my first line also shows a similar process. I don't want to guess or assume what I think is happening. Can someone please explain in large detail (preferably steps) how you figure out which small rectangle goes into which column and row; or in other words, can you tell me how the multiplication process translates into the figure?
The equation you have is
( MH<<16 + ML ) x ( NH<<16 + NL )
with << meaning "shift left by". Note that a shift left by 16 is equivalent to a multiplication by 65536, and two shifts by 16 are equivalent to one by 32.
If you multiply this out, you get
ML x NL +
MH<<16 x NL +
ML x NH<<16 +
MH<<16 x NH<<16
If you pull the shifts out:
(ML x NL) << 0 +
(MH x NL) << 16 +
(ML x NH) << 16 +
(MH x NH) << 32
Now the shift amounts show the number of bits each block is shifted by left in the graphic.
I'm playing with per pixel lighting shaders and i don't know one thing: What is half vector of light source ?
vec3 halfVector = normalize(gl_LightSource[1].halfVector.xyz);
I would like i you can explain it in math rows, i understand math better than words :)
From this post:
A "halfway vector" (if you mean that by "half vector") is the unit vector at the half angle between two other vectors. Normally the halfway vector [...] is computed between the vector to the viewer v and the light source l:
h := ( v + l ) / || v + l ||
The half vector therefore is the unit angle bisector of view- and light vector.
Edit: For a complete explanation of the lighting model including the half vector, just see the Blinn-Phong wikipedia article
The the answer by Dario is correct, but since the question was for GLSL, here is the appropriate code:
vec3 hf = normalize(v + l);
Generally the "THE" half vector is the vector between the light and the view vector. It is generally used as input to the specular bit of the Blinn-Phong equations.
this was my solution:
vec3 halfVector = normalize(lightDirection + viewDirection);
EDIT: it is not 100% correct but working when you want to do it more simple.