Warum ich kein Demoscenecoder bin

Samstag, 16.1.2016, 10:04 > daMax

zx-spectrum-plasmaWie 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.

| Abgelegt unter 1337, Coding, icke
The views expressed by the author are personal.