X 240 - Socoder

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|49\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Off Topic -> X 240
Mon, 21 Sep 2015, 09:52
spinal	Can I multiply a number by 240 by bitshifting? or is that procedure possible only with powers of 2? -=-=- Check out my excellent homepage!
Mon, 21 Sep 2015, 09:52
Jayenkai	Can't think of an easy way to do it. If you want to try playing about with numbers, load a decent calculator with bitshifting abilities. Pretty sure Windows Calc should have it, but you'll have to switch it to "Programmer" mode. PCalc on iOS also has bitshifting buttons. -=-=- ''Load, Next List!''
Mon, 21 Sep 2015, 10:38
spinal	I was just trying to think of ways to speed up rendering in frodo. It's quite a pain rendering from a palette array to rgb while rotating everything 90 degrees -=-=- Check out my excellent homepage!
Mon, 21 Sep 2015, 10:49
shroom_monk	A bit-shift by a single bit will multiply or divide the value by 2 depending on direction, so a bit-shift will only directly allow multiplication by powers of 2. However, you could achieve multiplication by other amounts by summing the result of multiple different bit-shifts on the original value. 240 is 11110000 in binary, so: x * 240 = x * (128 + 64 + 32 + 16) = 128x + 64x + 32x + 16x = (x << 7) + (x << 6) + (x << 5) + (x << 4) Although at that point, it would presumably be easier and faster to just multiply normally! What's your intended use case here? (There are some variants, such as observing that 16 is the highest power of 2 to directly divide 240, and then calculating (x << 4) * 15 [or (x * 15) << 4]. But ultimately the utility of this will depend on what you are hoping to achieve.) -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom!
Mon, 21 Sep 2015, 11:27
spinal	Was hoping come up with a way to speed this up -- // get screen buffer u8* bufAdr=gfxGetFramebuffer(GFX_TOP, GFX_LEFT, NULL, NULL); int slider = 22- ((CONFIG_3D_SLIDERSTATE)22); // scroll screen using 3d slider! for(int y=slider; y<240+slider; y++){ for(int x=0; x<384; x++){ int r = palette_red[bufmem[x+512y]]; int g = palette_green[bufmem[x+512y]]; int b = palette_blue[bufmem[x+512y]]; drawPixel(x+8,y-slider,r,g,b,bufAdr); } } --v void C64Display::drawPixel(int x, int y, char r, char g, char b, u8* screen) { u32 v=((239-y)+x240)3; screen[v]=b; screen[v+1]=g; screen[v+2]=r; } --v -=-=- Check out my excellent homepage!
Mon, 21 Sep 2015, 11:52
Dabz	Back in the day I was a huge fan of << >> thinking I was being the optimal coder... Until someone showed me the assembly from gcc, showing the difference between bit shifting and multiplication... And the result was.... None!!! The compiler is quite capable of optimising this sort of guff itself, so my advice would be, leave it as it is... The readability far outweighs anything micro tinkerin will achieve, not even writing the routine in assembly itself will make much difference imo Dabz -=-=- Intel Core i5 6400 2.7GHz, NVIDIA GeForce GTX 1070 (8GB), 8Gig DDR4 RAM, 256GB SSD, 1TB HDD, Windows 10 64bit
Mon, 21 Sep 2015, 12:15
Dabz	Extra bit of reading for gcc optimising flags:- https://www.redhat.com/magazine/011sep05/features/gcc/ Dabz -=-=- Intel Core i5 6400 2.7GHz, NVIDIA GeForce GTX 1070 (8GB), 8Gig DDR4 RAM, 256GB SSD, 1TB HDD, Windows 10 64bit
Mon, 21 Sep 2015, 15:55
HoboBen	Something like this? for(int y=slider; y<240+slider; y++){ u8 dest = bufAdr + ((239-y)3); your_type src = &bufmem[y512]; for(int x=0; x<384; x++){ char color[3]; color[0] = (char) palette_red[src]; color[1] = (char) palette_green[src]; color[2] = (char) palette_blue[*src]; memcpy(dest, &color, 3); dest += 720; src++; } } --v Also try: -- It seems like the destination buffer is being written to bottom-up in reverse column-major order. You could reorder the loop and rotate your source buffer so that both dest and src are being written to sequentially in row-major order. I would expect the gains to be worth the effort. -=-=- blog \| work \| code \| more code