Wie der eine oder die andere sicher schon mitbekommen hat, verdiene ich meine Brötchen am Computer. Genauer gesagt mit Softwareentwicklung, mal in Java, mal in Objective-C, meistens aber im Windows-Umfeld mit VB.net oder C# (und wenn es unbedingt sein muss, zähneknirschend manchmal auch noch mit VB6 oder *seufz* VBS), mein Blog mit dem ganzen HTML/JS/CSS-Gefrickel nicht zu vergessen. Das beherrsche ich inzwischen leidlich gut, obwohl ich ehrlich gestehen muss, dass mich die ganze Chose mittlerweile doch wieder mehr langweilt als begeistert. Aber ich schweife ab.
Was ich sagen wollte: gestern Nacht hatte ich eine Idee für ein Easteregg und dazu wollte ich mal sehen, wie man einen Plasmaeffekt codet. Sowas hier. Na, und beim Suchen bin ich über diese Diskussion auf Pouët.net gestoßen, die mir mal wieder deutlich vor Augen führt, warum ich es nie zum Demoscenecoder bringen werde. Die Frage selbst verstehe ich noch, aber schon bei Punkt 3_minus in der Antwort von bdk erscheinen bei mir die ersten Fragezeichen über dem Kopf:
Exploring sw rendering can be a nice thing.
Some quick random hints looking at the code:
1) Always try to use look-up tables when it comes to computationally heavy stuff like sin,cos,tan,sqrt and friends (this should give you a good speed-up...)
2) Using integer math / fixed point math still can improve speed a lot expecially when math precision isn't a must
3_minus)
- multiply for (1/x) instead of dividing for x (if x is constant)
- when doing modulus operations where the divisor is a power of two (x % 2^n) (in your code "... % 256" should be) you can replace it with a faster bitwise AND where "(x & (2^n)) - 1", i.e. x % 256 <-equals-> x & (256 - 1).
- when dividing/multiplying for powers of two (integers) you can use bit shifting (i.e.: x * 32 <--> x << 5). Probably compilers already do these last two kinds of optimizations. (bitwise operations)
Found also this site, maybe you'll find it useful: http://student.kuleuven.be/~m0216922/CG/index.html.
und bei der Antwort von duffman steige ich endgültig aus:
IF the surface width is a power of 2 and the total pixel count is a multiple of 16
IF your buffers are in user memory
then try this
change your loops from this
buf = new int[x, y]
for(int x = 0; x < w; x++)
{
for(int y = 0; y < h; y++)
{
buf[x, y] = code here
...
to something like this
int Log2(int val)
{
ASSERT(val > 0)
int res = -1;
while((1 << ++res) <= val);
return(res - 1);
}
mask = w - 1 //w must be a power of 2 remember
bitshift = Log2(w)
pixelcount = w * h
//initialize buffer like this
buf = new int[pixelcount]
for(int j = 0; j < pixelcount; j += 48)
{
for(int i = 0; i < 16; ++i, ++j)
{
// i is never used
//if you need x and y, here is how to compute them
x = j & mask
y = j >> bitshift
buf[j] = palette[(cls[x,y] + paletteShift)%255];
x = (j+16) & mask
y = (j+16) >> bitshift
buf[j+16] = palette[(cls[x,y] + paletteShift)%255];
x = (j+32) & mask
y = (j+32) >> bitshift
buf[j+32] = palette[(cls[x,y] + paletteShift)%255];
x = (j+48) & mask
y = (j+48) >> bitshift
buf[j+48] = palette[(cls[x,y] + paletteShift)%255];
This memory access method gave me a better speed increase than anything else(in C)
The moral here is, dont access big buffers in user memory sequentially
while((1 << ++res) <= val); Nee ey, das wird in diesem Leben nix mehr.
Wird geladen ...
Artikel als RSS
performs the following steps on an Arch Linux system: LC_ALL=C: Sets the locale…
Und…
