COLOR PALETTE SCROLLING

[Mad Compie]

Hi,
in DOS we could perform some great animation effects by simply changing the 256 color table values (Borland C, assembler, ...). Nowadays, in Windows, we also have to redraw the whole damn thing!
Anybody knows how do achieve the same result without redrawing?

[Zero]

The only way you can do it is if you use DirectX. I know you can do it in 256 color DX modes, and I'm not sure about 16, 24, and 32 bit modes. If you're running it in a window, you're screwed. The only other way to do it is to actively search out the pixels of one color and replace them with another color.

~Zero the Inestimable

[Mad Compie]

Hm, seems like Windows forgot something that in DOS worked very FAST and fine...

[Vuen]

What you could do is have the backbuffer 256 colors and then it doesn't matter what the primary surface is, in colors, and windowed or fullscreen, and you could do the effect, but I guess that would count as redrawing huh...
But this way you wont get the flicker that you would sometimes get from scrolling in dos. And it's way better than passing through all the colors manually, that is slow like crazy.

Anyways, if you know how to edit the palette colors in a surface than could you teach me? I need to know how to change palette colors on a 256-color surface for my game.

[Mad Compie]

Hm, that was also my problem. In DOS this could be done very fast, but in Windows?

[Fox]

Sure, use DirectX. Also supports hardware acceleration so you get much more speed than in DOS ;) Palette animations are possible whenever you use a 256 color buffer (coz you need to make a palette there). But I assume you're doing it in C/C++ coz in VB you usually won't get the same speed even using DX...

[Mad Compie]

Unfortunately, I'm not very familiar with DirectX.
I have the DX SDK on my disc and tried to understand the VB implementation. It seems that a simple "Hello World" on the screen using DX requires a lot of code...

[Fox]

Less than a simple DX Hello World program in C++ *hehe*

But well, since DX 8.0 the code shrinked down alot (especially initialising). Well I just wanted to point you to the right direction, coz the powerfull DirectX (alternatively OpenGL) APIs bring you much more than DOS... Think you know that if you ever played new games such as Quake3 or Ultima9.

But still the key to fast graphics is a mix of these APIs and ASM coding so you won't have any chance in VB :( even since DX is officially supported under VB ...

[Vuen]

Uh, thanks for the tip dude but I already use DirectDraw (in VB).

I found this page that shows how to edit a palette on a surface (in directdraw), but when my program creates the surface it doesn't create it in 256 color but rather in 24-bit color, no matter the bpp of the bitmap it loads the surface from.

So my question is how to I make a surface 256 colors? Thats all I need to know (except it has to have the palette of the original bitmap it's being loaded from.)

So should I use StretchDIBits as though I'm getting it from a resource file? I'm gonna do that and see if it lets me use the palette.

[/\/\isanThr0p]

I think you can change the bbp in the surface descriptor, before acutally creating it. I am not really sure about it. can you give me the URL to the page?

[HarryW]

I have found the solution, at least using DirectDraw in C. I expect it's more or less the same in VB.

It was the IDIRECTDRAWPALETTE::SetEntries() function (C++ notation). I just tested it out and itworks beautifully :)

I can't say for sure what you need in VB, but I have some code in C you can look at. It should look pretty familiar, since it's still DirectDraw, just a bit more complicated. Take a look here (http://forums.vb-world.net/showthread.php?postid=200223#post200223) and see what you think.

[Mad Compie]

Very impressive, Harry.
I think I'll have to take a better look at DirectX development...

[Jotaf98]

In the DDraw demonstrations that come with the SDK, there's one called DD Blend. One of its features is that the palette is constantly rotating, giving a nice animated effect to it. That part is commented too so you shouldn't have trouble finding it ;)

[Mad Compie]

Nice plasma, Jotaf!
I'll take a better look into this source code.
PS. I recently didn't know what to do, so I programmed a scrolling palette look-a-like (using BitBlt), which I submitted at planet source code.
http://www.planet-source-code.com/xq/ASP/txtCodeId.14375/lngWId.1/qx/vb/scripts/ShowCode.htm

Thanks for responding.

[Jotaf98]

Excellent code! People that make BitBlt games now can use palette color rotation too ;)

[Mad Compie]

Thanks fore the compliment!
Some of the code could be simplified to speed up some Blt, but there's one little problem: if I use a TTF font, like Arial or something (which could be anti-aliased, if installed), the font grayed outlines are drawn in another darker color.
I did not yet figured that out, but anyway, this little program shows that we can do a lot more with BitBlt than just showing images...
Bye!

[Jotaf98]

An idea would be to print it to a different picture box, and then replace all the pixels that aren't background/foreground colors to one of them...

[Mad Compie]

That's what I also had in mind. I'll try it out.

[Vuen]

NO DONT its horribly slow like that. I tried makin an rts than blitted the sprite to an offscreen surface, getpixeled each pixel and setpixelv it if it needs to be color-replaced. The game ran at like 7 frames per second with only 3 units on-screen. Thats slow like crazy. You can't do it like that it wont work fast enough.

[Jotaf98]

Hey, we're talking about DX here :)

If you access the surfaces using arrays, or even make a fast C++ DLL to do it (becausae VB loops are a bit slow), it could be fast enough...

[Mad Compie]

In my example the text is static, not dynamic. So I can calculate the positions of pixels that are not black and save them to an array after Form loading. Hence I won't need to GetPixel and SetPixel during the iteration process.

[/\/\isanThr0p]

Hey you can make this real fast if it's in 8bit mode
you can just make a lookup table.
It will be fast enough for realtime movement of the text

[Vuen]

Okay so how do I access my surface via an array? Is it possible to have a whole multi-dimensional array of just the values of RGB(A)? If so I want to know how to access it that way so I can just step through it with a loop. And I don't have C++ so I can't make a DLL that will do it faster for me. That's why I want to know how to make my surfaces paletted.
Does anyone know how to do this? I want to create a paletted surface, and I'm not gonna change the screen's bpp or use CreateSurfaceFromFile to do it. I'm using StretchDIBits to get my sprites from a resource file (like a .mpq) and pasting them onto offscreen surfaces made from scratch. I need to know what flag to set to make it paletted, and how to access this palette.

[heh, forgot to mention I'm using DIRECTDRAW (7)]

[Jotaf98]

Vuen... huh... you should take a better look at the demo I told you about... :rolleyes:

Unless you don't have the DX7 SDK... because it has exactly what you're asking for. If you want, I can e-mail you this demo.

Just curious: how do you compress it in a resource file and use that StretchThaBilts function? :)

[Koralt]

Just a comment on 256-colour palette scrolling ... well, frankly, that was useful back in the days of 8 mHz machines, but now a-days it's a bit less important. 256-colour scrolling looks nice, yes, but not as nice as a series of equivalent frames, with the actual bitmap data changing. That is, a scrolling-palette water fall may look nice, but a 24-bit waterfall with actual animation looks nicer, and is perfectly feasible. With the right optimizations (which, I'm well aware are tough to achieve in VB), the 24-bit version can become nearly as efficient as 256 colour -- only you have more colour depth.

[/\/\isanThr0p]

Hm I think Koralt is pretty right on his comment.
But Koralt I don't think you could ever reach the efficience of 8 bit with a 24 bit bitmap, because it is just 3 times as much data. If you do this in fullscreen with a backbuffer, that allready uses most of the video mem.

[Vuen]

Yes, I badly need that demo thing, and I have a less than 56k connection (*smack*). I can't really download the sdk cuz it's HUGE but yeah.

And about getting the bitmap from a resource file, it's not compressed, the bytes of the file are within the resource file exactly as they would appear in the original file. I got the info on how to do it from http://rookscape.com/vbgaming/, click tutorial and its under directdraw somewhere.

And about that color scrolling, if you want to make a nice waterfall that would look just as good with the color scrolling as without except for the fact that you would have to palette the primary surface, then I would make the primary surface 24-bit but load only the scrolling part of the waterfall (so you wont lose any color depth at all) in a seperate 8-bit surface. Then each time you want to blit it, just change the palette before you blit. That way you would take WAY less memory than if you had the waterfall 24-bit sprites (for example, if the scroll is across 8 colors then you would take 1/24th the space in memory), and you would lose absolutely no color depth, because anything that doesnt scroll colors isnt paletted, and anything that does scroll colors is paletted in its own surface. So the 8-bit scrolling looks exactly the same as the 24-bit sprites, except you take up WAY less memory. Thats how I would do it anyways.

Anyways, please if you could email me that demo at vuen@lycos.com please thanks!

[Koralt]

Well, in EDF ( http://www.edf-project.org ... sorry, the site's a bit old now ), my graphics format for tiles and sprites is based on a similar concept. Basically, the actual bitmap data is 256-colour indices. Of course, it's not BMP format -- far from it! The format is based around the fact that isometric graphics have a lot of unused space; it just has a run of n pixels drawn, then skips a run of n pixels, and has a "carriage return" command -- all very quick when implemented right.

So, anyway, the 256-colour indices refer to RGBA palettes (the palette has the alpha info in it) ... yeah.

[/\/\isanThr0p]

Hey Koralt
I have been to your site before, and I really don't want to mess with that :)
Do you have any code? I am really thinking about a tileformat like that.

[Jotaf98]

Hey, I think I have an idea for it: the width of the tiles wouldn't be larger than 16px, right? So we can use a byte for the color of a pixel and half a byte (4 bits - 16 possible combinations) to define how much pixels to the right of that one would be the same color.
Just like in GIF images, except that GIF compression uses one byte for the color and another byte for the "width" of the horizontal line.

Another thing: the tiles would fill ALWAYS the same pixel positions, right? I mean, we can have pre-calculated that the first pixel should be at (7,0), the second at (8,0), the third at (5,1), the fourth at (6,1) (that's just an example). So we could get the pixels all straight into their right positions, instead of waiting 'till we hit a carriage return or something... what do you think?

[Koralt]

Misanthrop, do you ever use c++? As I said, the code I've written isn't for VB ...

Jota, to be honest it's very rarely worth doing RLE. Furthermore, the primary point of ISO is that parts of the tile may go above the floor -- which a system such as that would prevent. Also, the "carriage return" my system uses isn't a carriage return keypress, it's an analogy. ;)

Finally, the bulk of GIF compression *isn't* the RLE, but the LZW (Lempel-Ziv Welsch) compression, and it simply isn't worth using half of a byte for much of anything. I mean, what do you do with the other half? What about the time wasted masking it (i.e., AND 15) ?

[/\/\isanThr0p]

Hm I think you are completely right Koralt

But The tile thing with drawing it this way, must be real fast under dos, but since we got DX, it is just a way to save some diskspace (who cares for a meg)

[Jotaf98]

Ok. Forget about that "GIF"-thing I said.

I understood what you were trying to say by "carriage return": when the color of the pixel is the carriage return, automatically advance to the first pixel of the next line.

But since the carriage returns would be always in the same positions of the images, why not making them fixed? Like this:



ab
cdefgh
ijklmn... (continuing)
######
##



In the file it would appear like this:

abcdefghijklmn (continuing...)

The code would automatically position the pixels in the image/when drawing:

ab | cdefgh | ijklmn ...

a and b would start 4 pixels to the right; cdefgh 2 pixels to the right, ijk(...) 0 pixels to the right. The next line, 2 pixels and the other one, 4 pixels. Please consider this method, because I think would be better even for drawing the tiles in the game (using GetLockedArray() ).