Parkobj loads rct_gx

[spacek531]

Loading of sprite atlases is not as fast as desired. rct_gx archives seem to load much faster.

Test objects: #16746 (comment)

Will address #15547

[duncanspumpkin]

After my PR this part of the function will change. This will use common code from LoadObjectImages

[spacek531]

will close #15547

[spacek531]

test objects available here: #16746 (comment)

[Gymnasiast]

will close #15547

Not directly - it will provide a way to close it, but we would still need to actually convert the images to gx and ship a new objects release.

[spacek531]

Should a change like this get a changelog entry? I am thinking yes

[duncanspumpkin]

One area of this that is still under discussion is do we actually need a range should it just be a path.

[IntelOrca]

@duncanspumpkin allow both

[spacek531]

$DAT:ObjData/ does not allow a path without a range does it? I'm fine with either, I am wondering if there is precedent.

[duncanspumpkin]

$DAT:ObjData/ does not allow a path without a range does it? I'm fine with either, I am wondering if there is precedent.

There's a slight issue in that objects specify an identifier where as you should be specifying a path i wonder perhaps if the json should be reorged to make this more clear.

[spacek531]

I suppose it is easier to know how many images are in an rct_gx than an object, considering there is ride object import code specifically to guess how many images there are

[duncanspumpkin]

Just looking at the json we are supporting we will now have the following:

    "images": [
       "$LGX:spritefile-rle.lgx[0..4970]"
     ],

and

    "images": [
       "$LGX:spritefile-rle.lgx"
    ],

which will be added to the following supported formats:

    "images": [
          { "path": "images/preview.png","x": 0, "y": 0 },
          { "path": "images/0.png","x": 0, "y": 0 },
          etc...
    ],

    "images": [
        { "path": "preview.png", "x": 1, "y": 1 },
        "$CSG[44289..44339]"
    ],

    "images": [
        { "path": "preview.png", "x": 1, "y": 1 },
        "$RCT2:OBJDATA/PATHDIRT.DAT[73..145]"
    ],

    "images": [
        "$G1[22856..22871]",
        "$G1[22565..22576]"],

[Gymnasiast]

Seems to work as intended. I have not reviewed the code, I just tested it.

@duncanspumpkin I leave the final decision to you (in case you want some changes still).

[spacek531]

Just looking at the json we are supporting we will now have the following:

Is it good or bad to have all these sources? Since they all use the same range format, I don't see the issue - the odd one out is lgx without range. I'm fine with dropping lgx without range because it's the only format that does not explicitly define how many sprites there are, but I can see it as a tiny qol feature to not have to write the range when using a generation tool.

[duncanspumpkin]

Just looking at the json we are supporting we will now have the following:

Is it good or bad to have all these sources? Since they all use the same range format, I don't see the issue - the odd one out is lgx without range. I'm fine with dropping lgx without range because it's the only format that does not explicitly define how many sprites there are, but I can see it as a tiny qol feature to not have to write the range when using a generation tool.

I wrote that message because initially i felt like lgx would be out of place. After writing out all the formats I started to warm to it. I don't think there is anything left to discuss on this and am happy to merge.

I personally think we should only use bmp (nonrle) with this but that will be a discussion to be had within the objects repo.