OpenXcom Forum
Modding => OpenXcom Extended => OXCE Support => Topic started by: Ostrich-Hungry on June 12, 2021, 11:04:57 pm
-
I want to create flags for new nations!
So, I keep geting this message "OpenXcom supports only 8bit images"
I pressume its because the colours are too bright. Can I download them from some place, or convert mine with some internet page or program?
-
This is have nothing with "too bright", OXC use palette graphic not typical RGB ones.
There is some info about programs that correctly handle 8bit graphics:
https://openxcom.org/forum/index.php/topic,2676.0.html
-
The easiest way to start is to take an existing flag and change it with a graphic editor which is able to keep the same palette, like Photoshop or Aseprite (or GIMP if you know what you're doing).
-
The easiest way to start is to take an existing flag and change it with a graphic editor which is able to keep the same palette, like Photoshop or Aseprite (or GIMP if you know what you're doing).
I wonder, which palletes should be used for editing the pngs for OXCE in GIMP? I have seen a link to github directory with several palette files, and it's not clear which one to use for the following use cases:
- ammunition items (for the soldier equipment screen; I assume the same sprite is reused for Ufopaedia)
- base facilities
I also wonder, if it is possible to use large facility images for 2x2 facilities, or the sprite needs to be split in 4 (consecutively numbered in image ref index, presumably).
Finally, I would like to learn, which option should be used for saving PNG in GIMP. I'm getting the error noted by original poster, that "OpenXcom only supports 8bit images" when using "8bpc RGB". Other options are "8bpc GRAY", "8bpc RGBA", "8bpc GRAYA", "16bpc RGB", "16bpc RGBA", "16bpc GRAY", "16bpc GRAYA". My guess that neither of those are the case, and a special paletted PNG mode should be utilized. Is this correct? Is this the only available option with the OXCE engine?
I'm also confused by the fact that I have seen the images with alpha channel in XCom Files, as base facilities. The Ruleset Reference mentions that only transparency index of zero is supported. Does it mean that alpha channel is indeed supported, but it's only 2-bit? Are the aforementioned images in XCom Files therefore universally supported by the engine, assuming they only have full-transparency in the alpha channel?
Does the use of images larger than 32x40 lead to a segfault? I'm getting some segfault, without meaningful log message to debug further, when trying to view the base with my larger 2x2 facility image. If that is the case, then this is a bug in the implementation, since a program shouldn't crash on the bad input. A graceful exit with an error message is an expected behaviour.
Since the original game used the large under-construction facility frames, what is the right offset reference to use for those? Is it 9? When I used it without referencing the master (xcom1), only as 9, and not { mod: master, index: 9 }, I got the right result. Now, I'm confused, since my mod does not have an offset 9, and the numerical namespaces for graphics reference indexes are disjoint (that is, they are tagged with their respective disjoint namespaces). Why did this work at all:
- type: STR_LARGE_HANGAR
spriteShape: 9
spriteFacility: 100
and why did this not yield a reference error?
UPDATE
Apparently, GIMP tried to be too fool-proof by doing the right thing (= using indexed PNG mode whenever the image is already in the indexed mode) when "automatic pixelformat" option had been utilized at the time of export. Eek!
-
1/ use palettes provided in the oxce package, in the 'common' folder
2/ ammo uses PAL_BATTLE_COMMON
3/ base facilities use PAL_BASESCAPE
4/ large base facilities need to be split
5/ only 8bit paletted pngs are supported
6/ alpha channel is completely ignored by the engine... you can use transparency if you want your images to look better outside of the game, but for the game, you'll need to use index 0 as well
7/ images larger than 32x40 don't lead to segfault, but there is also no reason to use bigger images
8/ you can use index 9 without referencing master, because it's an original UFO1994 resources and it is shared across mods (I exaplained it to you yesterday: https://openxcom.org/forum/index.php/topic,6017.msg149070.html#msg149070)
-
1/ use palettes provided in the oxce package, in the 'common' folder
2/ ammo uses PAL_BATTLE_COMMON
3/ base facilities use PAL_BASESCAPE
4/ large base facilities need to be split
5/ only 8bit paletted pngs are supported
6/ alpha channel is completely ignored by the engine... you can use transparency if you want your images to look better outside of the game, but for the game, you'll need to use index 0 as well
7/ images larger than 32x40 don't lead to segfault, but there is also no reason to use bigger images
8/ you can use index 9 without referencing master, because it's an original UFO1994 resources and it is shared across mods (I exaplained it to you yesterday: https://openxcom.org/forum/index.php/topic,6017.msg149070.html#msg149070)
Thank you. This really helps.
I have attached a sample mod that causes the segfault in my case.
The images are correctly getting displayed when the building is built, but when the large hangar building is ordered to be built, a segfault occurs. Could you possibly have a look at the mod, and help me with debugging, and fixing the issue?
I also noticed that the GIMP is not exactly doing the right thing when saving the colormapped image. In my case, after reducing to the pallette extracted from the original indexed base tile image (from the XCF mod), and stored in the GIMP pallettes, I got a weird output. The file utility says it's a 4-bit indexed image. The feh displays correct colored output. The OXCE displays a tiled inconsistently colored gray image, with different squares having slightly different tint. (The relevant PNG files are in large_hangar subdirectory).
UPDATE
I got the constructed facility to display properly by adjusting the GIMP use routine. However, I'm still getting the segmentation fault when attempting to construct the building. I'll see if I could inherit the boundaries from XCF in some way. Is the spriteFacility flag responsible for displaying the boundaries of a facility being built?
-
I don't know the details of what GIMP does by default.
But it is NOT a recommended tool, it likes to be "too smart".
There are other recommended tools, search under Tools subforum.
-
I don't know the details of what GIMP does by default.
But it is NOT a recommended tool, it likes to be "too smart".
There are other recommended tools, search under Tools subforum.
I almost fixed the GIMP issues, so at this point issues related to it specifically are hardly worth our attention.
I'm more concerned with the segfault. I think, there's some implicit assumption made about how to draw the boundaries for a 2x2 facility. Is there a way to specify this explicitly? I noticed that the following definitions in XCF don't really specify anything remotely close to that:
- type: STR_GENERAL_STORES_2
spriteShape: 309
size: 2
buildCost: 1000000
buildTime: 24
monthlyCost: 16000
aliens: 40
prisonType: 4
storage: 275
mapName: XBASS_06
listOrder: 6860
- type: STR_LIVING_QUARTERS_2
spriteShape: 301
size: 2
buildCost: 2250000
buildTime: 24
monthlyCost: 35000
personnel: 200
rightClickActionType: 6
manaRecoveryPerDay: 4
aliens: 5
prisonType: 4
storage: 50
mapName: XBASS_02
listOrder: 6910
- type: STR_LARGE_WORKSHOP
requires:
- STR_LARGE_WORKSHOP
spriteShape: 320
size: 2
provideBaseFunc: [WORKS]
buildCost: 4600000
buildTime: 48
monthlyCost: 200000
aliens: 5
prisonType: 4
storage: 25
storageTiles:
- [0, 5, 1]
- [0, 15, 1]
- [11, 3, 1]
- [11, 17, 1]
workshops: 250
rightClickActionType: 2
mapName: XBASS_36
buildCostItems:
STR_ALIEN_ALLOYS:
build: 40
refund: 20
listOrder: 6983
Yet the hangar definition in XCF is slightly distinct:
- type: STR_HANGAR
spriteShape: 9
spriteFacility: 9
size: 2
buildCost: 200000
buildTime: 25
monthlyCost: 25000
crafts: 1
mapName: XBASE_16
workshops: 5
storage: 25
aliens: 10
prisonType: 4
storageTiles:
- [0, 8, 0]
- [0, 10, 0]
- [0, 12, 0]
- [1, 11, 0]
- [1, 9, 0]
- [0, 16, 0]
- [0, 18, 0]
- [1, 17, 0]
- [2, 16, 0]
- [2, 18, 0]
listOrder: 7260
The spriteFacility == 9 doesn't make too much sense to me, though.
UPDATE
Same result (= segfault) with
spriteFacility: { mod: x-com-files, index: 305 }
-
However, I'm still getting the segmentation fault when attempting to construct the building.
You need 8 images: 4 for a built facility and 4 for a facility under construction.
extraSprites:
- type: BASEBITS.PCK
files:
100: Resources/large_hangar/01.png
101: Resources/large_hangar/02.png
102: Resources/large_hangar/03.png
103: Resources/large_hangar/04.png
104: Resources/large_hangar/01.png
105: Resources/large_hangar/02.png
106: Resources/large_hangar/03.png
107: Resources/large_hangar/04.png
-
You need 8 images: 4 for a built facility and 4 for a facility under construction.
extraSprites:
- type: BASEBITS.PCK
files:
100: Resources/large_hangar/01.png
101: Resources/large_hangar/02.png
102: Resources/large_hangar/03.png
103: Resources/large_hangar/04.png
104: Resources/large_hangar/01.png
105: Resources/large_hangar/02.png
106: Resources/large_hangar/03.png
107: Resources/large_hangar/04.png
I wonder, if there's a good way to reference image data from another mod, and assign in a different local index. That is, 104 .. 107 should map to x-com-files::[305 .. 308]. Is there a way to achieve this?
I see now how it's done in the XCF, with its original resources, where the path string is repeated multiple times. However, in my mod, there's no XCF image data present; I would like to avoid an un-necessary image data copy.
UPDATE
Thank you! The segfault is now gone!
-
I wonder, if there's a good way to reference image data from another mod, and assign in a different local index. That is, 104 .. 107 should map to x-com-files::[305 .. 308]. Is there a way to achieve this?
no
-
no
So, is copying the image data the only way to attain the desired outcome?
-
So, is copying the image data the only way to attain the desired outcome?
If the desired outcome is to reference two different number ranges from a parent mod in a single number range in the child mod, then the answer is yes.