Color cycling?
BlitzMax Forums/BlitzMax Programming/Color cycling?
| ||
| Who remember's the cool color cycling effects from the Amiga? You could cycle easily through the color palette and this way you could create cool animations of lava or waterfalls? I'm currently thinking of how such an effect could be realized with Blitz. Where are my retro freaks? ;-) |
| ||
| Is it worth the trouble? Isn't brute-force copying/moving gfx way more practical? I also have roots in colorcycling, but as far as I'm concerned this was just a trick to get things 'moving' on a system that's too slow for brute-force copying/moving. These days, we can even emulate those systems and their palette-modes.. so why bother. :P |
| ||
| Potential "intelligenter" way than bruteforcing: multiple grayscale images you draw above each other, using SetColor to fake palettes :) |
| ||
| Or draw it pixel by pixel yourself. Prolly not a good idea with the 3D acceleration but I've gotten quite good speeds from straight pixmap modification/blitting :) |
| ||
| In Blitz plus you could redefine the pallet I believe and thus do colour cycling, but this can't be done in Max right? |
| ||
| OO!? w000t? palette in B+? how, for crikey's sake?? |
| ||
| B+ had a 256 colour mode didnt it? If so it had a palette |
| ||
| Wasn't that the slow mode GDI thing? And BlitzPlus was 2D only, while BM is 3D only. |
| ||
| *never* heard/read of any palette-mode until just now :S But I guess it wouldn't 've worked with canvases eh.. The only thing I'd like a palette for is for my retro-drawtools.. it's so much nicer to have audo-updates for a fullscreen pic when moving a colorslider, than to manually redraw it (=slow) .. |
| ||
| yeah I nearly used the pallete thing to do a plasma effect, but I coded it a different way in the end. Right just looked it up, it was the SetGamma command that looked like it could e used for that but I never used it... |
| ||
| Ok, question. BMax works in 8bit mode yes? (Ok so non of the draw commands work, but Bmax can open an 8Bit screen, and then just sit there yes) So it must have asked the operating system/the c+ dll, (I dont realy care, and its not important), either way its been given an 8bit screen. So what ever made the 8Bit screen, wouldnt that have made a pallette as well? If so, you could have a go at finding a Ptr to the backbuffer, and then another to the Pallette and you could knock together a few drawing/pallette commands and have color cycleing. Or Not? |
| ||
| Sadly it's pretty much impossible to do this properly without an 8 bit palletted mode without wasting too many resources to emulate it. |
| ||
| So it would be too slow to grab the screen as a pixmap, o through every pixel and check it's colour and change it to a new one (based on a table I guess) and then draw the pixmap back. I bet this would take quite a few ms and have a crap framework. Worth a try or not? |
| ||
| Well you could change the color when you blit the sprites :) |
| ||
| or seperate the "paletted pixels" onto a grayscale image which you then draw in the desired tone using setcolor :) |
| ||
| Youve said this greysacle thing twice now, and I dont understand what you mean, but anyway, You are talking about a 32bit grey scale image or a 8bit? do you have a link and/or spent a few minutes explaining it. Thanks |
| ||
| Color cycling is based on a paletted image whereby you are interpreting the value of each pixel as an index in a lookup table. Basically that is a `remap` function. As a display device, like on the Amiga, this lookup is performed in hardware and basically translates the pixel values into the values that are stored in a palette lookup-table, on the fly. TrueColor modes don't do that, they show you the actual pixel values in terms of how much of each color component to add, rather than use a lookup table, mainly because the lookup table would be much too big to be efficient. So what you really need to be doing is a remap function, to simulate paletted images with TrueColor. You have to basically make a software remapper that works on the fly. Each pixel in a source image has to be looked at separately and then based on how much offset the cycle is at, add a value to that to get an index, and then look in a lookup table to find the color to draw, which you then output to a new image and render to the screen. It's not really something you can very quickly. In OpenGL you can draw pixmaps and upload images with palette-based remapping on the fly. But it's not very fast and I found it doesn't seem to work or be supported on all systems. In the early days of my blobby objects stuff I did a software remapper which basically rendered the blobby object fields based on a small palette using a different index for each threshold value. This was drawn to a pixmap and then DrawPixmap was used to render to the screen. Needless to say it's not exactly fast even if you set things up to be as efficient as possible. If you have ranges of colors that basically increase in value for each component, like gradient, you can simply render a rectangle with LIGHTBLEND (add) operation and the value that you're adding should appear to shift the gradient as in color cycling, but it probably will not wrap around because (at least in GL) the values are clamped at white. It would be a nice easy thing to do with a shader. Depending on how much of your screen is going to cycle, you could put all the pixels of a given value in its own image as white pixels and draw that image with a given tint using SetColor. you'd have to draw as many images as you have colors in your cycle range and each would be drawn with mask color of black. For 256-color images you'd have to draw 256 images. Like dreamora said. |
| ||
| H&K: What I mean is that you simply use a grayscale image (bitdepth does not mather, TImage will depend on graphics depth) and use the SetColor to colorize it in the desired color. As you used a grayscale, this grayscale will then modify the hue of your color as it is drawn. So you basically could do a whole water - lava thing just with 1 grayscale image. It is not the same as paletting, but depending on what you actually want to achieve, it is a cheap way to do so. But it won't be a full paletting replacement. As Angel said, even using it hardware side won't work, as modern hardware internally always work in 32bit and do not like nor really support 8bit anymore. |
| ||
| The loss of palette swapping is a tad annoying, for me. Mainly because trying to write a football game without it just adds extra headaches. For every frame of animation I need: a head hair limbs two shirt images (shirts have two colours) shorts two sock images (socks, like shirts, have two colours) boots It's quicker than doing straight pixel swap with a single pixmap, I believe, but it's certainly more fiddly to work with. With palette swapping, I'd just be altering a few values and running away laughing. (on the bright side, shading is much easier with greyscale images). |
   |