ZDoom

Thanks, I have thought about this a lot - my own project potentially uses only 1 palette per map anyway. Originally I felt it was useful only to combine areas with different palettes as one map for ease of maintenance/scripting of events between the two areas. However, I now think it could be useful for adoption of this feature with mainstream resources. Using standard Doom resources the mapper may be able to find about 5 palette shades that are never used in a map, if they are lucky, and rewrite those for some custom sprite - which is kinda limited. Changing mid level, the mapper only has to consider a much smaller area for spare palette entries, and so the flexibility will be increased.

Anyone have any tips on writing additional ZMAPINFO code?
Currently I am trying to get my code tidied up to use better colormaps than the current hack I introduced, and then I will submit code for one palette per map. Any more will have to follow when I've learned more.

When thinking about this feature, I had only ever imagined different maps using different palettes but this is swapping palettes within a level. Frankly, I don't know how much more useful that makes it (which is a neutral statement: it could be very useful, it may not be). Either way, it still gets a :shock: and a :rock: from me.

Is there a direct way to get the (now variable) size of PLAYPAL without going through FWadCollection?

Yes it was deleted while I fixed minor grammatical errors and then my internet dropped out. Sorry. Uploaded version is now the final one. I didn't want to imply that a single linedef was all that had been changed.

EDIT: The first texture was actually converted using the wrong palette, it could look better than that.
Could someone delete the other two video links to just leave the working one in my post?

Thanks, Gez :)

Try this one:
[youtube]TPTR_HyUvFk[/youtube]
And if it gets deleted again, look here:
http://www.youtube.com/user/albiongeck

[quote="albiongeck"][youtube]X_s3crq1uEg[/youtube]

The video uses a Doom-in-Hexen map to give access to LineSpecials, but the actual PaletteChange() in no way depends on this format.[/quote]
I can't watch this video, because YouTube says that, it was deleted by the user.

I needed a (very) long break as I couldn't concentrate anymore but I've come back to finish what I started last year.

Here I have a working concept video for the palette change code. The code is tidier and the other changes over the last year seem to have really helped.
This is by no means the end, there are many caveats to be worked out - but I feel I've done enough to ask for a little help, and maybe people can start thinking about uses for it.

[youtube]z0yK4uWaiDw[/youtube]

The video uses a Doom-in-Hexen map to give access to LineSpecials, but the actual PaletteChange() in no way depends on this format.

What works:
What you see in the video. There are just under 930 colours used here. You can change palettes (almost) seamlessly IF you don't use color 0 in your resources. As predicted there is a split-second glitch to the display on changing, (too slight to show in the video at 15 FPS). I advise against changing the palette during combat but otherwise I find it acceptable. I suspect you could find inventive ways to hide or explain the glitch to make it seem more polished.
[b]EDIT:[/b] All standard Doom powerups seem to work.

What doesn't:
Fonts don't update correctly. They load correctly with the first palette only. The code looks awkward and I haven't worked it out yet.
[b]EDIT:[/b] Underwater translucency will crash out unless actors are reloaded as described below. Otherwise they work fine.

Color[0] rempping:
As predicted this is troublesome. However, I have found that it can be fixed by saving, loading a different map, (to clear the cache) and reloading the save. This fixes all Things and Textures, but not Decals. I feel it should be possible to write a function to Serialise(), re-render and DeSerialise() the game with a pause of only a second or two. I have attempted to write code for this, but I can't make the required delay between Save and Load, and I can't find anything to override the caching of the current map. I need help with this.

The alternative is simply to make sure your resources do not use color[0] to begin with, (as seen in the demo).

Blood decals:
Don't load correctly at all. I have read they are hard coded and have seen a request for them to be converted to normal decals. It would save me a lot of time to have some advice with this.

Other decals:
Load correctly for the palette used at creation time. They mismap when the palette changes but are correct if it changes back. I feel this is should be fixable.


As ever, I can only test so many things. If you are concerned about a feature breaking, or just want to help please post a test wad with untested features and I will video the results.

If you'd like me to upload my code so far, please advise me how you'd like it.

EDIT: had to delete the video and re-post, Youtube doesn't support replacing video files in-place.

The main idea is to set it from MAPINFO, and maybe also from ACS or from console commands. Nothing forces to use PLAYPAL as a base.

Plus, a PLAYPAL lump contains many palettes. So you could say something like "Palette = "PLAYPAL", 72" to use palette number 72 in the PLAYPAL lump.

How should it be called the lumps? I know that PLAYPAL uses 7 letters, and if we add a number near it we have only 10 combinations ( "PLAYPAL0-PLAYPAL9" )...

Sorry randi, I hadn't noticed I was talking to the site admin. It was late and I misunderstood what people meant.

Thinking about using this for individual rooms in a level, even without all the problems Graf just pointed out, it would be tricky to implement - the palette switch could be done on crossing a lindef easily, but what happens when the player looks across that linedef from one palette into another? I think there'd have to be a transitional corridor between the rooms (palettes) which either gradually blends between palettes or uses only the colours both rooms have in common. Otherwise the destination room (palette) would need to accessible by teleport only.

Today I linked the functions together so they're callable in the console. Swapping of palettes and colormaps is now working, except various minor bugs which I will tidy before posting code. In testing, the switch over still seems instantaneous, I couldn't write a testing loop which had any apparent delay.

If anyone can think of features not in stock Doom2 (all I've tested so far) and can link wads for testing, that would be more than welcome.

[quote="Gez"]But try to get paletted blending in Doom to match the effect of the rad suit palette in this file... That pretty much won't happen.[/quote]
It could if blending had desaturation capabilities. The only reason you should need to change the full palette for a flash is if you wanted to blend parts of the palette differently, and these effects are exactly the kind that Graf and Randy want to avoid.

You do realize that ZDoom does the blending by palette swapping already right? `testblend "00 FF FF" .5` yields a nice cyan blend for me on the pure software renderer.

[quote="Graf Zahl"][quote="Gez"]Since a truecolor renderer is truecolor, it can keep using blending effects without color deterioration.
[/quote]
Not if the palette is abused to handle them.[/quote]
I don't think you understood what I meant.

There are limits to how much blending can emulate palette swaps when you keep the same palette. Not in truecolor. So, in truecolor, you can keep using blendings instead of implementing palette swaps.

But try to get paletted blending in Doom to match the effect of the rad suit palette in this file... That pretty much won't happen.

This is why I see merit in having palette swaps for flashes in a paletted software renderer, without implementing them in hardware or in a truecolor renderer that might happen one day.

Of course it should be mentioned that with true coloe rendering the entire palette switching stuff will be strictly limited to textures that use the palette that gets switched.

It won't even work that well with the software renderer because if properly implemented these textures all will have to be discarded when the palette changes. These images will get remapped to the game palette by color matching so if you first match the image and then change the palette will yield completely different results than first switching the palette and then color matching the image and you could end up with an unpredictable mishmash of converted textures.

So, in the end it's probably best to do this strictly per level and not allow changing on the fly.

...yeah, I've been saying a lot of dumb things this evening. One of those things including misreading your last point. I am a moron.