[Editor V3+] Glitches or limitations - mainly 8-bit colour related

[Gilbert]

Since AGS was updated to Version 3, the editor was completely rewritten, and it wouldn't be surprising that the highly under-used, publicly-hated and untested 8-bit colour support may no longer work as intended.

I recently got some spare time to update my 8-bit colour tutorials to AGS V3 and I noticed some oddities in the editor. To make sure of this, I made some tests using the newest test version (V3.2 RC3) and found that most of these problems still exist.

1. The "Remap colours to game palette" setting in the sprite import dialogue is not saved properly. When using 8-bit modes seriously this should always be turned off. Currently, when you want to import another sprite you need to uncheck its checkbox again, which is very, very annoying. This is a step backwards, as this problem also existed in V2 initially and was supposed to be fixed since V2.61, but now it resurfaces in V3 of the editor. I haven't tested this extensively, but I have a feeling that the "Lock to room background palette" setting may suffer from the same problem. If this is the case it should also be fixed.

2. When palette entries are changed the effects aren't reflected in the editor immediately. For example, I want to set the palette properly and then import these sprites in their exact details. I first import the appropriate colour slots of the palette by grabbing them from the image file and have this:

Then, I import a sprite using 'exact palette import' (i.e. turning off "Remap colours to game palette"):

We see that the image is okay during import, but after import the image displayed in the sprite list is all messed up:

The colours are correct if you restart the editor or see them in-game. My guess is, that the editor would only use the colours when it first loads the game. Any changes in the palette would not be reflected immediately in the same session.

3. Colours of the backgrounds would not be reflected in the palette. In previous versions of the editor, when you edit a room, the "room dependent" colour slots (i.e. "Background" slots in recent versions) would actually change to match the current room (well, especially for the DOS versions of the editor this was trivial, as the editor operated natively in 8-bit mode, loading a room would force the system palette to change to match the room), which could be checked by (temporally) changing the room-dependent slots to "Gamewide". This was actually a good feature in verifying whether a background is imported correctly, but since V3, when you change the "Background" slots to "Gamewide", you'll see that these slots only carry some random colours (probably whatever colours that were assigned in the initial palette). Say, when you import this background into a room, which has the following palette:

You'll expect that after import the last two rows of the palette contain a red slot and a gradient of green, but after changing the "Background" slots to "Gamewide" I only see this:

At first, I thought that this was because of the change in interface of the editor, so that we can edit two different rooms at the same time (in previous versions, only one room could be loaded each time) and if this is the case it would be impossible to have the palette accurately reflect the room colours. However, after further testing I find that the current editor cannot edit two rooms at the same time either, so it's still reasonable to have this feature. The editor can edit the scripts of two different rooms at the same time though.

4. After importing a sprite with the "Lock to room background palette" setting turned on, the sprite may not be displaced in its correct colours when you put it as an object of a room. For example, I want to import this sprite to use in a room having this background. However, when I place the sprite as an object in the room I get this:

I think this is somehow related to problem #3 above, that the object is not using the correct palette colours (current "Gamewide" slots + "Background" slots matching the current room background). Again, when you restart the editor and reload the room, or test the game you can see that the colours are perfect.

Since the above annoyances do not prevent games from working properly and I don't know whether they can be fixed in the current incarnation of the editor, I'm not sure whether they should be considered glitches or limitations. Anyway, as they're introduced since the editor rewrite and the problems are somehow related, I'll just make this new thread instead of reporting them in the beta version thread (some of these may have been reported already but I think it doesn't hurt to have related problems put into one single thread).

P.S. I notice that SaveScreenShot() stores files in the save game folder (this is now written in the help file), but DynamicSprite.SaveToFile() stores files in the game's folder. I understand the reasons for this, as the DynamicSprite one could probably be used to store some temp. files for future loading, etc. (though personally I think that BOTH functions should write to the game folder instead). The problem is, it's not written explicitly in the manual where the DynamicSprite one would store the files, so it would be good to have a reminder on the entry just like the ScreenShot one.

P.P.S. I understand the reasons to discontinue support of PCX files in favour of BMP and PNG. However, because of the following problems PNG is not (quite) usable in 8-bit modes, so instead the awful BMP format unintentionally becomes the preferred format for development of 8-bit games (as seen in my updated tutorials):
  a) In the palette editor of the editor, you cannot use PNG to import or export the colours, only PAL and BMP are supported. When making 8-bit games it's common practice to just import the colour slots directly from the image files (PAL files should be avoided as they're too ambiguous and it just makes you do an extra step to save extra files), so you're forced to save your images as BMP.
  b) The funny thing is, however, in the game engine the use of PCX files is still supported (check SaveScreenShot(), DynamicSprite.SaveToFile() and DynamiteSprite.CreateFromFile() ), but not PNG files (I understand that this may be related to the more complex compression schemes used by PNGs and this is to prevent the loading and saving of PNGs from impairing the games' performance).
Thus, I think if possible, it would actually be a good thing if PCX sees a comeback to the editor (as in fact, some good native 8-bit editors such as DP2E support saving and loading of PCX files but not BMP).

P.P.P.S. In the past, colour slots #0 through #16 were considered as "Locked" and they were used by stuff like system messages, debug mode overlays, etc., so they cannot be changed from the editor. Since V3, we don't have "Locked" colours any more, so every slot can be changed any time at will. Actually I like this much more as there are more freedom. The problem is, it seems that the manual is not fully updated to reflect this change yet. It doesn't mention what "Locked" colours are any more but in some pages (say, the description of the SetPalRGB() entry) it still mentions "Locked" colours, which is a bit confusing, and I think we should also put some warnings in it so that people won't get messed up when say using the debug functions after changing these colours.

P.P.P.P.S. The colour values in the editor have since been changed to use 8-bit per channel values (0-255) to work with the Windows colour picker, but for 8-bit games, SetPalRGB() and the palette[] array are still using the 0-63 range. This is a bit inconsistent and confusing but I don't have any better idea, so I'll say just keep this at the moment.

[Pumaman]

These are all good points, thanks.

However, the fact that so few 8-bit games are made nowadays means it's just never going to be a high priority to implement changes like this. Is anyone actually making an 8-bit game?

[Babar]

Am, (and tried in past 3+ incarnations), but because of the problems, I'm using 2.72 for that particular project.

[Shane 'ProgZmax' Stevens]

Personally, I think the 8-bit mode is extremely outdated and just not necessary at all if one addtion to the engine were made to accomodate those who like using palettes:

allow users to import palettes for sprites/characters/objects at any time, allowing them to in theory be able to have a traditional 8 bit game or a hybrid game that allows on-the-fly palette swapping.  For instance, imagine you have a character and would like the player to be able to choose between, say, 6 color variations for his outfit.  Instead of making 6 variations of the sprite or having to adjust the palette colors manually you could merely load an entirely new palette for that character.  Support for the Microsoft RGB palette format would probably be suitable for 95% of people even interested in this sort of thing, and on a commercial game I'm working on this would actually be quite useful!  The benefits of being able to load up a new palette for each game entity extends beyond simple outfit color-change as well; it's also an easy way to do color cycle animations or change out color selections for a background if you wanted to simulate changes of season or times of day without using regions or animations.

[academiken]

I have an 8-bit mode game that I started a good 6 years ago (!) that was on the shelf for a long time that I'm dusting off.  I'm quite excited about finishing my project.  There's a lot in the new editor that I love, so it was worthwhile to upgrade my project.  But, there are funny things that had been happening with newly-imported sprites color-locked to my new room.  In my case, my background has 192 colors that are different than my 64 global colors.  Some of the colors in the background palette are not used in the background; rather, they are there for the benefit of objects that share the same 192-color palette.  When I try importing the sprites with the "Lock to room background palette" option turned on, some colors are remapped incorrectly.  Now, here's the interesting part: if I replace my background with one using the same palette, but I intentionally use all 192 the colors in the background, then the imported sprites work fine.