[Solved] Need help with Flags

[Ostrich-Hungry]

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?

[Yankes]

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

[Solarius Scorch]

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

[zee_ra]

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:

Code: [Select]

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

[Meridian]

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)

[zee_ra]

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?

[Meridian]

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.

[zee_ra]

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:

Code: [Select]

  - 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


Code: [Select]

  - 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


Code: [Select]

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

Code: [Select]

  - 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

Code: [Select]

    spriteFacility: { mod: x-com-files, index: 305 }


[Meridian]

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.

Code: [Select]

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


[zee_ra]

You need 8 images: 4 for a built facility and 4 for a facility under construction.

Code: [Select]

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!

[Meridian]

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

[zee_ra]

no

So, is copying the image data the only way to attain the desired outcome?

[Meridian]

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.