Jump to content

Munkey's page


Munkeylord

Recommended Posts

hey whats up, anyhow i got another computer that is slow enough to run xcom. found some cool stuff that i'm gonna put up on the site within the next week. stuff i completely forgot about. but other than that yea......don't know if i'll do this for long
Link to comment
Share on other sites

  • Replies 112
  • Created
  • Last Reply

Top Posters In This Topic

I wrote a program that can take an image drawn via one palette, and redraw it so that it will look the same on another palette. For example, if you drew a picture of a guy in uniform, then redrew the same picture using a different palette so the uniform changed color, you could run it through this program so that the image was the new color on the original palette.

 

I've also written a couple of PCK reading programs, which could pass the image data to the palette interpreter. That's how I turned the PCK files to GIF files a while back.

 

Would such a thing be any use to you?

Link to comment
Share on other sites

  • 2 months later...

I'd need to do a bit of code chopping to turn it into something easily used, but before I do, lemme ask: would it be used for battlescape images?

 

If so, then I'd need to do a bit more coding. You see, the game darkens pixils depending on lighting and stuff. If I wrote a program which just chose what it thought was the nearest color, the game might then map those pixils to something else entirely when it applied it's lighting alogrithm and then the whole image would go messy-splat... Which means more coding to prevent that happening. Which I wouldn't mind doing, but knowing in advance would be nice. ;)

 

Speaking of lighting, anyone know the rules for how tiles are shaded? I've just re-written my Map Viewer's graphical engine so's it can handle lighting, but I'm not sure exactly how to use my softwares new capability... :cool:

Link to comment
Share on other sites

When I look at the game palette, I can see that a majority of the base colours are sorted in groups of gradients of 16 light levels. With the lowest value being the darkest and the higher value being the brightest. That gives us... well, 16 light levels.

 

My guess is that for every pixel, the game modifies the pixel by the light level of the cell by subtracting the light level from the pixel's palette index value (0 being full daylight and 16 being absolute darkness - or maybe 16 - light value, I forget). Of course, you'd need to have a check that prevents the colour from bleeding into the previous colour set. If it goes beyond the current colour block, then just set it to the lowest possible value in that colour set (I guess you could check if the new value is within the same set of colours with the help of the modulus function (modulus of 16 or somesuch), and then checking the modulus of the resulting function)

 

That's just how my mind seems to suggest a solution for reinventing this wheel. :cool:

 

(Are you going to be grabbing the light values off termp.dat and sourcemp.dat for tactical games?)

 

- NKF

Link to comment
Share on other sites

I gather termp.dat and sourcemp.dat both store light source info, but I've no idea in what format. I suspect wglob.dat has a value which says what time of day it is, but I've yet to test the value I'm suspicious of.

 

Without the knowledge of what each tile should be shaded to, I've only been able to use minimal testing on how shading might be implemented. I found that adding to a specific color index would darken colors simply enough, but it soon starting bleeding colors and the result didn't look good at all. (This after adding a mere value of 5, mind you!)

 

I figure if I put in a bleed checker it'll produce the same effect as the game. If so then I could probably leave bleed checking out of a palette converting program, as it would all be handled at run time by both the original code and my own.

Link to comment
Share on other sites

the format for termp.dat and sourcemp.dat is incredibly simple.

 

Each byte represents the light level for a single tile in the map. For some reason the game stores a few extra bytes, but all you need is to load mapwidth * mapheight * map elevation's worth of bytes in (grab these from wglob.dat, of course). I wouldn't bother too much with the extra 4 bytes. (possibly a fencepost error when writing the light overlays)

 

You could make a small black and white bitmap out of the light overlays. Just pass the value of each byte along to your pixel drawing function and fill all the R G and B values with that value (edit: multiply it by 8 or 16 to make the values more visibile - no point in getting 16 values of very dark grey :cool: ). Naturally, use the map width in the wglob.dat to determine the bitmap width.

 

Once drawn on the screen, you'll clearly see how closely it mimics the lighting in the battlescape - with the topmost level being at the top and the ground being at the bottom. (Use a night battlescape test game - the Skyranger, soldiers and street lamp lighting tends to be easy to spot)

 

Now I wish I'd kept the source code for viewer I'd made. Well, it was inverted (easily fixed), but heh.

 

Note, seemap.dat is very similar, but it doesn't have the extra 4 bytes and its file size is a very accurate representation of how many tiles there are in the map) . Only this is used for the fog of war bit that blackens unseen tiles. (Hah, I can envision an 'overlay' checkbox to toggle this in a viewer...)

 

seemap.dat basically only uses yes/no answers, but for some reason it has slightly different values for corners. Values range from 0 - 7, but the effects are rather binary - the tile is either black (set to pitch black - or full darkness), or you can see it (based on values from termp.dat or sourcemp.dat.

 

So, in the end, you have to pass 3 extra values to your tile blitting function that help determine the lighting level.

 

- NKF

 

P. S: Termp.dat and sourcemp are both light levels, but one is for static lighting and the other is for temporary light sources that can move about, like units, flares and fires

Link to comment
Share on other sites

P. S: Termp.dat and sourcemp are both light levels, but one is for static lighting and the other is for temporary light  sources that can move about, like units, flares and fires

 

And no one remembers which is which, from what I gather... ;)

 

Ok, so I assume the temporary lighting values simply override the static ones? Sounds very... simple. Very simple indeed. :cool: I admit I've never actually looked at those files yet.

 

As for seemap.dat, I've decoded that. Each tile can contain four things - floor, a couple of walls, and an object of some sort. Each byte in seemap uses three bits, one says whether you've seen one of the walls, the other details the other wall, and the third bit covers the floor and the object. The viewer I have up for download at the moment (I think) allows you to press 'F' to toggle the effects of seemap.

Link to comment
Share on other sites

  • 4 weeks later...
If you don't already know Monkeylord, your weapons sets are being put into thought as a possible addition for UFO2000 weapon sets. It is suggested from Hobbes that it would be under the name as "Real Weapons" with other real weapons. The .lua file is not made yet, only suggestion right now. It will probably be in .lua file form as soon as mine are made. UFO2000 has progressed a lot for people who tried the #3 versions. The beta is 7.843 right now, so that is pretty high. Everybody in UFO2000 is waiting for the 8.0x stable release though (those who know its coming out).
Link to comment
Share on other sites

  • 1 year later...
If you don't already know Monkeylord, your weapons sets are being put into thought as a possible addition for UFO2000 weapon sets. It is suggested from Hobbes that it would be under the name as "Real Weapons" with other real weapons. The .lua file is not made yet, only suggestion right now. It will probably be in .lua file form as soon as mine are made. UFO2000 has progressed a lot for people who tried the #3 versions. The beta is 7.843 right now, so that is pretty high. Everybody in UFO2000 is waiting for the 8.0x stable release though (those who know its coming out).

 

 

cool, guess i'm a little late on the reply.....sorta stuck in afghanistan

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
  • Create New...