AGS 3.0 Final - it's been a long road

[Ashen]

Minor bug - can't see it reported anywhere, but apologies if I missed it.

The Object Y coord as reported in the Editor is wrong. The 'StartY' property seems to be the top edge of the sprite, while the Object.X script property and Object.SetPosition both still use the bottom.

[Pumaman]

sometimes I accidentally move one or more sprites out of place. When the sprites all look similar, it's hard to find out which one goes where. Thus, it would be nice to be able to sort by number, which would put everything back into the proper order

This would be reasonable to implement, but I'm not sure if anyone else would find it useful?

Also, since new sprites will get assigned the first available number, there can be huge jumps because of deleted sprites. So to make the sorting practical, it would help if the numbers started over in each folder.

This is not possible, as others have pointed out if you had a line in the script like:
object.Graphic = 46;

there'd be no way to distingiush between which folder you wanted to grab sprite 46 from.

Could you also include an option in preferences to override the OS default setting?

Certainly.

Well, it's a bit difficult to explain, but i'm having troubles with RC1: every time i import a new sprite, it is immediatly replaced by my sprite 0

Ok, why don't you tell us exactly what you did -- which menu options you chose, in what order, and what happened at each stage.

See: there are two walkcycle generators, and I can't tell which is which... can we make that dialog resizable or scrollable or something?

Hah, I'll look into it.

Where did the exact palette import for 8-bit backgrounds go? Did I overlook something?

Due to the very small number of people using 8-bit these days, not all of its features have been ported across. If it's something you really need I can look into re-adding it.

The Object Y coord as reported in the Editor is wrong. The 'StartY' property seems to be the top edge of the sprite, while the Object.X script property and Object.SetPosition both still use the bottom.

Hmm yeah, this has always been the case in the editor. It's probably about time to bring it in line with the script.

[MrColossal]

oh my! 8 bit going the way of the dodo, but it's only 2007! I personally would enjoy further 8 bit support... I'm sorry for not reading the entire thread but are there other 8 bit specific features that haven't made their way across the 3.0 divide?

[subspark]

This would be reasonable to implement, but I'm not sure if anyone else would find it useful?

If you can manage to allow AGS to reorder sprites both in the sprite editor and to update any slots in the pane editor (excluding assigned slots in scripts) then I would find this very useful.
Too many times have I gotten things out of order as those big numbers below my sprites can be very confusing sometimes.  :'(

Cheers,
Paul.

[Gilbert]

Where did the exact palette import for 8-bit backgrounds go? Did I overlook something?

Due to the very small number of people using 8-bit these days, not all of its features have been ported across. If it's something you really need I can look into re-adding it.

Yes, it's of utmost importance to me, but since I don't have time to play around at the moment, unless someone else really need it I think it's not very urgent. (Moreover, I'm still using the V2.6 branch actually.)

I'm sorry for not reading the entire thread but are there other 8 bit specific features that haven't made their way across the 3.0 divide?

Well, at least I'll say the current lack of immediate slider control in the palette tab makes it very difficult to tweak the palette in 8-bit. Instead of just clicking on a colour and move the sliders you hav eto popup the colour picker on the right, which is very inconvenient as I always accidentally choose a pre-defined colour but there's no undo feature, that makes me very difficult to find out what the original colour was.

[subspark]

Can AGS import palettes from say, Photoshop or Paint Shop Pro?

Paul.

[Gilbert]

Yes, but it's still inconvenient to tweak individual entries.

[subspark]

Oh I get you. Yeah that does sound like a rather tedious process.
Perhaps Chris will still re-add the 8 bit palette support for the minority?

Paul.

[RickJ]

Also, since new sprites will get assigned the first available number, there can be huge jumps because of deleted sprites. So to make the sorting practical, it would help if the numbers started over in each folder.

This is not possible, as others have pointed out if you had a line in the script like:
object.Graphic = 46;

there'd be no way to distingiush between which folder you wanted to grab sprite 46 from

There have been discussions about similar features to achieve these same results before.   Personally I liked the idea of associating sprite numbers with enums possibly generated from the file name the sprite was imported from.   Anyway. I think it's a little late for anything like that to make it in this verson.  Maybe next time.

[Gilbert]

Hmmm I'll suggest, that rather to make it as confusing as starting over in a folder, maybe we can add a option (can be unchecked, so can still revert to previous behaviour) to set a base number to each folder, so that when you import a sprite in a certain folder, it will search for the first available slot starting from that base.

Like, for example you assign a base 0f 3000 to a certain folder, and slots 3000, 3001 are already used. If you import one more sprite into that folder it would be #3002. If you further tile (batch) import 10 sprites in a row, they'll be #3003-3012.

This can tidy up stuff a lot, like in the default template, the roger sprites in the default folder are numbered 2000 onwards, which is quite clear and tidy. To renumber the sprites one by one using the right-click method currently is quite annoying IMO.

This is useful especially to people like me, who dig hard into using the numbers in the codes (so I wasn't really benefited by the OO changes, they just made my codes messy), like for example there're 4 sets of sprites, each with 6 sprites arranged in order, I'll just number the sprites used in the 1st set 101, 102, ... , 106; the 2nd set 201, 202, ..., 206; etc. Thus, if I want to locate the kth sprite in the nth set I just need to use the formula (100*n)+k, which is efficient especially when you have a large number of sprites that you need some structure in the order of their numberings.

[Shane 'ProgZmax' Stevens]

I've found a very minor bug with adjusting gamma in D3D mode.  If you abort the game (alt-x/ctrl-q) before resetting the gamma the screen will remain at that setting until you close the confirmation box.  This doesn't occur with directdraw.

Edit:

There's also a bug in the sprite import that I keep forgetting to mention, but it definitely prevents me from importing a good portion of my sprites without a lot of re-working.

You can see that everything looks fine so far and the sprite seems ready to load in


And then it loses the true black elements. 


This seems to happen when palette index 0 is the same color (though at a different index than) another color used in the sprite -- in this case 0,0,0 at index 18.  If I change palette index 0 to a unique color it imports fine, but this shouldn't really be necessary if it is reading the color indexes properly since index 0 is saved as transparent in the gif(and the other index is not).  It also shows up clearly in the preview.


Something that happens in 3.0 and does not in 2.72 is when setting transparent color to palette 0 and quick importing sprite animations it displays the index 0 color as the background.  In 2.72 it properly recognizes it as transparent and leaves it out.

Additional weird behavior:  you have to physically load a single image in order to adjust the transparent color (palette 0, top-left, bottom-left,etc) because the Quick methods do not allow you to set these options like they did in 2.72.  Perhaps the import sprite window should show up for Quick imports (or at least have the transparent color drop-down).  Another option would be to have a menu toggle for this so you can save your transparent color setting and select it outside of the sprite menus?

[Elessar]

Hmmm I'll suggest, that rather to make it as confusing as starting over in a folder, maybe we can add a option (can be unchecked, so can still revert to previous behaviour) to set a base number to each folder, so that when you import a sprite in a certain folder, it will search for the first available slot starting from that base.

This can tidy up stuff a lot, like in the default template, the roger sprites in the default folder are numbered 2000 onwards, which is quite clear and tidy. To renumber the sprites one by one using the right-click method currently is quite annoying IMO.

I like that idea. I got annoyed at having to renumber every single sprite, so I gave up. But now I have lots of "random" numbers in my folders, which makes it hard to figure out what is what.

[Pumaman]

oh my! 8 bit going the way of the dodo, but it's only 2007! I personally would enjoy further 8 bit support... I'm sorry for not reading the entire thread but are there other 8 bit specific features that haven't made their way across the 3.0 divide?

Well, the 8-bit support is still there but a couple of the advanced import features in the editor (like Exact Palette Background Import and the palette settings when importing animated backgrounds) are no longer supported.

To be honest, I'm not even sure how well the 3.0 editor works with 8-bit games. I haven't given it much testing myself, and I'm not sure if anybody else has really tried this?

Yes, it's of utmost importance to me, but since I don't have time to play around at the moment, unless someone else really need it I think it's not very urgent. (Moreover, I'm still using the V2.6 branch actually.)

Well yeah, the other option is to recommend that people stick with 2.72 if they want to make an 8-bit game. I'm not sure at this point.

Hmmm I'll suggest, that rather to make it as confusing as starting over in a folder, maybe we can add a option (can be unchecked, so can still revert to previous behaviour) to set a base number to each folder, so that when you import a sprite in a certain folder, it will search for the first available slot starting from that base.

This sounds like a good suggestion to me. Probably too late for 3.0 though.

I've found a very minor bug with adjusting gamma in D3D mode.  If you abort the game (alt-x/ctrl-q) before resetting the gamma the screen will remain at that setting until you close the confirmation box.  This doesn't occur with directdraw.

Hmm, this looks like it's going to be difficult to fix due to the different ways that the D3D and DDraw drivers shut down. I don't think it's a major problem so I won't worry about it for now.

This seems to happen when palette index 0 is the same color (though at a different index than) another color used in the sprite -- in this case 0,0,0 at index 18.  If I change palette index 0 to a unique color it imports fine, but this shouldn't really be necessary if it is reading the color indexes properly since index 0 is saved as transparent in the gif(and the other index is not).  It also shows up clearly in the preview.

Could you post a GIF file that has this problem so that I can experiment with it and get this fixed?

Something that happens in 3.0 and does not in 2.72 is when setting transparent color to palette 0 and quick importing sprite animations it displays the index 0 color as the background.  In 2.72 it properly recognizes it as transparent and leaves it out.

Do you mean Quick Import Animated GIF, the Quick Import Multiple Sprites or both? What colour depth is your game?

Additional weird behavior:  you have to physically load a single image in order to adjust the transparent color (palette 0, top-left, bottom-left,etc) because the Quick methods do not allow you to set these options like they did in 2.72.  Perhaps the import sprite window should show up for Quick imports (or at least have the transparent color drop-down).  Another option would be to have a menu toggle for this so you can save your transparent color setting and select it outside of the sprite menus?

Well, my reason for dropping this confirmation is because of an assumption that nowadays 99% of the time everyone uses top-left pixel, and that prompting for the choice would be more annoying in 99% of situations.

Is this a valid assumption to make?

[SupSuper]

If it's supposed to be Quick, maybe it'd be better adding a Preferences option for the Quick Import methods.

[subspark]

I like the trend of steamlined userfriendlyness that is inherrant with AGS 3.0.

Pehaps we could have an option to 'Update Sprite' or 'Update Folder' if AGS could remember the image's file name and directory upon import. All sprites are still compiled into the exe of course.

Paul.

[Shane 'ProgZmax' Stevens]

Is this a valid assumption to make?

I often need to change the pixel locations or choose palette 0 depending on the sprite (square inventory items are one example where I would import as palette 0 rather than top-left pixel) so I would definitely like some kind of easy way to select between them again; perhaps a right-click menu setting with a transparency tree?

Do you mean Quick Import Animated GIF, the Quick Import Multiple Sprites or both? What colour depth is your game?

Quick import animated gif.  16-bit so I can ignore individual palettes/use transparency.

Could you post a GIF file that has this problem so that I can experiment with it and get this fixed?

Certainly.  Here is the one I used in the example: http://members.cox.net/progzmax/joeyfloatdown.gif

Any other one I try that uses the same color values as index 0 has the pixels made transparent on import (using the top left type settings) while palette 0 just leaves the background solid.  If you try this sprite in 2.72 you'll notice that when importing a quick gif animation with palette 0 selected it will properly import it.  The color index confusion issue existed in 2.72 but I just got around it with palette 0, which is probably why I never thought to bring it up before .  If you need more gifs just ask.

[SupSuper]

Speaking of transparency options, I've always wondered: why isn't there an option to import sprites without transparency?

[subspark]

SNAP! I was so going to ask that at one point. I hate having to add one pink pixel to all of my GUI sprites.
Would this be reasonable to change?

Paul.

[Rui 'Trovatore' Pires]

Well, usually import without transparency is using colour 0 - true black doesn't seem to be often used, and if you're going hi-colour then it becomes "true horrid pink", thankfully never used, much. Any more than that becomes relatively specialised.

[SupSuper]

Well obviously you can work around it (I do use black a lot so I usually just import with unused transparent space and have AGS crop it to fit) but it'd be nice if you didn't have to.