Jump to content

Openxcom MODS


luke83

Recommended Posts

As the development of Openxcom continues, more modders are starting to find themselves onto the forums, As such i have changed my personal mods storage site to a General Modders storage site to give a home to the ever increasing items showcased on the Openxcom Forums.

 

As such Moriarty started showcasing his work on https://openxcommods....s.weebly.com/��, please head on over and check out his new flying suit smile.png

 

Also there is some x-com modding guides stored under "How-To" on there also, they may not be written very well but it should be able to turn any x-com fanatic into a Openxcom modder.

Link to comment
Share on other sites

You could make a suit like that , the detail levels would be very low but a descent resolution inventory image would allow people imagination to fill in the gaps.

 

Does anyone have a exported copy of this sprite from Apoc , i would be willing to make a trial run to see how bad it looks with EU pixel count?

Link to comment
Share on other sites

  • 3 weeks later...

Just a update , We have increased our "How To" section on my site and it now has SOMETHING on my Favourite programs needed to mod x-com, Sure there is still plenty to add ( especially since a BB_Toolkit section has been created) but we are trying to show just how easy it really is to make your own maps and sprites to be used in game.

Check it out https://openxcommods....com/how-to.html

 

Also for those not sneaking around the OpenXcom Site , Version 0.4 should be officially released at the start of next month.

https://openxcom.org/

Link to comment
Share on other sites

That's all kinds of awesome. A couple of notes on my stuff:

 

an interesting effect: when I tried gif2pck the first time, the sprite order in the resuting .pck file was all wrong. It might have been because I was running it from a USB memory device: apparently the tool did not actually sort the files itself, but instead relied on the file system to provide them in the correct alphanumerical order. once I moved the whole directory structure to the HDD, everything worked beautifully.

You're spot on about this; Java supposedly gets the file listing from the OS, and for whatever reason it's not alphabetically sorted when dealing with external drives. In fact, if memory serves, it's reverse order for those. I've no idea why. Perhaps I should apply an alphabetical sort of my own.

 

One problem is: the converter is a little bit too smart for our good and actually creates the .gif files with a reduced palette, omitting any colors that the current sprite doesn't use.

Er, which converter are you talking about? When converting to GIF with my tools, you should get the whole palette in the resulting GIF file, all 256 colours worth.

 

That said though, if you DO increase the colour depth and start editing, you could then tell GIMP to pack the image back down to GIF without palette matching yourself, then pass the result to gif2pck. It'll do the matching for you (though if you never increase the colour depth you'll avoid accidentally using colours that'll convert poorly, this function is handy if you want to copy'n'paste in art from other sources).

Link to comment
Share on other sites

In fact, if memory serves, it's reverse order for those. I've no idea why. Perhaps I should apply an alphabetical sort of my own.

[/Quote]

Actually, for me it started at an offset. I think it was 30. It makes me think that instead of actually being sorted alphabetically (or alphanumerically) they might simply have been added in the actual physical order of appearance on-disk, being a fat-32 USB memory device in this case. Though why they would be in that order specifically eludes me.

 

Er, which converter are you talking about? When converting to GIF with my tools, you should get the whole palette in the resulting GIF file, all 256 colours worth.

 

That said though, if you DO increase the colour depth and start editing, you could then tell GIMP to pack the image back down to GIF without palette matching yourself, then pass the result to gif2pck. It'll do the matching for you (though if you never increase the colour depth you'll avoid accidentally using colours that'll convert poorly, this function is handy if you want to copy'n'paste in art from other sources).

 

My little experience comes from pck2gif, and the resulting images did not have a full palette. Or definitely not all of them. The colors that are used are there, but some or all of the unused ones are either changed to #000000 or missing entirely (if the number of colors used is 16 or less, I guess).

I'll try and check again ASAP, to see if I've made a mistake or else if I can provide some more information on the matter. :)

 

BTW, did you find the bullet/projectile sprites yet? I checked today and found the data in the openxcom source code (they adopted the hardcoded approach for now), but I lack the programming skills (or the patience) to convert the raw bytes into a gif or pck :(

Link to comment
Share on other sites

What I suspect's happening is that you opened some of the GIFs in some other editor (Paint or something) and re-saved them. That might've dropped the colour depth in a bid to reduce file sizes. (Not much point though, as these particular images use less then a typical cluster anyway; thanks to slack space, they effectively can't be shrunk.)

 

Sorry about the bullet sprite thing; I'm easily side tracked these days. I've now found the post I'd been thinking of.

 

To explain how it works: Each bullet is composed of a number of 3x3 sprites (up to 35 of the things, it seems). When you fire, the game figures out an angle, and starts processing a line from your unit that gets longer and longer each frame. Near the end of that line it draws the bullet sprites, close enough together that most overlap. Some of the sprites are empty, signifying "gaps" in the bullet trail, and some sprites aren't part of the bullet at all (they may be used to show the smoke that trails behind a rocket for eg). Using this system, bullets can be rendered in a way that looks "natural" regardless of the angle of fire.

 

As far as modding the things goes? Well, the easiest way would be for OpenXcom to load the sprites from an image file, like the one Volutar posted. In fact I've gone ahead and shrunk that one down to just the sprites, dropped the resolution and colour matched it:

 

bullet sprites.gif

 

The idea is that OpenXcom would come with a file like this that'd it'd load on startup. If you wanted to edit bullets, you'd simply edit this file. Pretty similar to how the old WinAmp skins work (or how MineCraft texture modding works, if you've ever messed with that).

 

Of course something could be coded up to rip the sprites from the original game to such an image (or dump it back into the EXEs). In terms of OpenXcom, this'd mean that it wouldn't need to include the original graphical data - if it couldn't find the sprite image file on startup, it'd create one from the user's copy of UFO, then use that from then on.

Link to comment
Share on other sites

Thanks for the bullet sprite info! I suspected something like that. I agree that it would be best to externalise that as an image file somewhere... let's see if the devs agree :P

 

as for the GIFs, no, I definitely did not open them in any other editor before that.

 

I just re-tested it: I took the original game files, used "pck2gif handob" and here's the resulting image for the first rifle sprite, to the right of it the actual palette of that image as shown by GIMP, no additional steps in-between. maybe java has changed since you programmed it first? are you using a routine that may have been "upgraded" to do things automagically?

https://www.weebly.com/uploads/1/1/8/4/11849982/9522003_orig.png

Link to comment
Share on other sites

No, I'm not using any in-built Java routines for the GIF encoding. I wrote them from scratch.

 

So I'm going to blame GIMP. That particular image only uses colours within the first 16 indexes of the palette, and so it decides the rest is superfluous and omits it (presenting the file as 4-bit). But I bet if you right click the files my tool is outputting in Windows Explorer, bring up Properties and check the Summary/Details panel, it'll tell you they're 8-bit.

 

Dunno if it helps you narrow things down, but I can tell you that the complete 8-bit palette takes up 768 bytes of data; for the PCK sprites, you'd expect the overall filesize to be something like 800-1,200 bytes all up. For a 4-bit image it'd only be 48 bytes worth of palette data, so the file sizes would be more like 150-400 bytes all up.

Link to comment
Share on other sites

No, I'm not using any in-built Java routines for the GIF encoding. I wrote them from scratch.

 

So I'm going to blame GIMP.

 

you know what, I think you're right. I never thought it possible, but I tried opening the same file with irfanview and saving the palette info from there, and it gives me the full palette as .pal text format.

I'm going to write a message to the GIMP dev community. I can only see this as a bug. There appears to be no way of making the GIMP show the actual palette. Even if you use it to export the image's palette, it gives you the reduced one.

 

I'm sorry for suspecting your converters when in fact the GIMP was the culprit :)

Link to comment
Share on other sites

Can't say I blame you; I'd be inclined to blame my messy-looking stuff too (if I didn't already know exactly what it can and can't do). ;)

 

It's possible it's on oversight, but I'm thinking someone somewhere wants it to work like that. If you submit a report, be clear on the current behaviour in addition to the expected behaviour, and why you want it to act the way you do.

Link to comment
Share on other sites

No, I'm saying I can extract data from TacData. ;) I've spent the last few evenings figuring out (what I hope to be) the bulk of Apoc's sprite formats.

 

But I probably won't have all the armour sprites pulled until sometime tomorrow. Some of the blighters don't want to come out yet and it's getting late here now. There's a lot of them, too - over a hundred images for Marsec helmets alone, for eg.

 

I'm interested to see what they have to say about the colours thing. Thanks for the link, I'll keep an eye on it. :)

 

Out of interest, if you:

  • Load one of the affected images
  • Apply the full palette to it
  • Save as a new GIF and quit GIMP
  • Restart it and reload the new file

... does it drop the colours again? What about using other palette-based formats the program might support (eg 8-bit BMP)?

 

To be clear on how the palette in an image file works, it has to be of a length equal to a power of two. For example, 256 is two to the power of eight; 16 is two to the power of four (see where the terms "8-bit image" and "4-bit image" are coming from?).

 

What I'm assuming is that while GIMP loads the image, it keeps track of the highest colour index used, then loads an amount of indexes from the palette equal to the lowest power of two it can get away with (instead of loading whatever the file header tells it to load).

 

For eg, if the highest colour used is 13, then it loads the first 16 colours (it doesn't really care if all those colours are used in the image, it just thinks it doesn't need more then that - two to the power of three is only eight, so it has to jump to two to the power of four, which covers 16). If the highest colour index was 43, it'd load the first 64 colours (two to the power of five is only 32, but two to the power of six is 64), and so on.

 

However the file header DOES state exactly how many colours are in the palette, and so GIMP should respect that and load the lot. The catch is this means a larger file size when it doesn't seem to be needed (hence why I think someone somewhere thinks this is a feature).

Link to comment
Share on other sites

I'm interested to see what they have to say about the colours thing. Thanks for the link, I'll keep an eye on it. smile.png

 

Out of interest, if you:

  • Load one of the affected images
  • Apply the full palette to it
  • Save as a new GIF and quit GIMP
  • Restart it and reload the new file

... does it drop the colours again? What about using other palette-based formats the program might support (eg 8-bit BMP)?

 

To be clear on how the palette in an image file works, it has to be of a length equal to a power of two. For example, 256 is two to the power of eight; 16 is two to the power of four (see where the terms "8-bit image" and "4-bit image" are coming from?).

 

What I'm assuming is that while GIMP loads the image, it keeps track of the highest colour index used, then loads an amount of indexes from the palette equal to the lowest power of two it can get away with (instead of loading whatever the file header tells it to load).

 

For eg, if the highest colour used is 13, then it loads the first 16 colours (it doesn't really care if all those colours are used in the image, it just thinks it doesn't need more then that - two to the power of three is only eight, so it has to jump to two to the power of four, which covers 16). If the highest colour index was 43, it'd load the first 64 colours (two to the power of five is only 32, but two to the power of six is 64), and so on.

 

However the file header DOES state exactly how many colours are in the palette, and so GIMP should respect that and load the lot. The catch is this means a larger file size when it doesn't seem to be needed (hence why I think someone somewhere thinks this is a feature).

 

I've done some further testing and updated the bug report... apparently, the GIMP only loads the palette up to the last used color. everything after that is simply dropped. I think I remember an occasion were some colors from in-between have also been dropped, but as of now I haven't been able to re-create that.

Link to comment
Share on other sites

  • 1 month later...
  • 3 weeks later...
Thanks mate , the site is being built slowly as i still have other projects to do also ( this weekend i spent trying to work out how to make Youtube videos to support the community, the only thing i learnt was my voice sounds bad when recorded) , plus some of the new members are planning extra tutorials when they get time also so it should continue to grow.
Link to comment
Share on other sites

Just wanted to provide some new experiences in a classic game , i can tell you many, many hours have gone into making these 2 sets so i hope someone else uses them someday.

 

Once this entire UFOs are done i may try my hand for something similar for TFTD as there does not seem to be many mods for that around.

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...