Messages

A poorly drawn treasure map

Odd. I saw a dead old man with long nose and white beard, with his skin turned to green. You've drawn his cheek too!

Is that a True Type Font? I'm not sure, but maybe the font contains some hinting information which somehow makes the text misaligned to the left.

You may try to change the font and see if that changes anything.

Hmmm odd.

Can you upload some small files to demonstrate your problems? (No need to use your real game materials.)

Well, I think most real pixel artists would prefer to do this manually by hand though.

I haven't tried this yet (as I don't use PAIN.NOT), but I think this can be useful in games with pixel art and scaled sprites (like adventure games made in AGS for example). When pixel art are scaled up unfiltered we will have double pixels (when they're scaled down there're other annoyance, but not fixable with this method, so I'll just ignore this case here), like the characters in DOTT for example, which definitely aren't pretty to look at (but if you use filtering you'll just get more ugly blurry sprites), so this routine may be useful for improving scaled-up sprites in such games (good thing is, this won't boost colour count like using filters, so such technique is applicable to all colour depths). I don't know how demanding this process is, so I'm not sure if it's suitable for real time usage. In adventure games though, normally you won't encounter many scaled sprites at a time, so it'd be a nice touch if this could be added to (the character scaling part, at least, of) AGS and anyway we could just have options to disable this feature for slower computers.

I think even plugin support was added to the Linux engine (which I think is not the case) you still need to have the plugins recompiled for Linux for them to work, so the dlls just couldn't be used directly anyway. For games using plugins your best bet is to use Wine or Virtualisation.

[mygame --setup]

    mygame.exe /setup 

But but but... don't you know what winsetup.exe does is only mygame --setup?

I understand the concern that some people may not be familiar with the '--' stuff though.

(Well, SSH beats me but I'd just post anyway.)

[changes.doc]

Well, for the release dates, if you don't trust Wikipedia or even the AGS Wiki, you can always open changes.doc in the docs folder of the AGS directory...

...unless you didn't even (dare) to install AGS, or you thought CJ was lying (if he was lying how could we provide even more accurate information?) or it's a strict human-human communication programme that you're not allowed to conduct any written sources (even reliable ones).

Anyway, you can always do a little research.

Yeah. DX9 is still at V9.0c and it's most probably not going to see an increment in the version number anymore, but M$ is still discreetly updating it from time to time.

Think of it like this, the most "recent version" of WinXP is SP3, but this does not stop M$ from frequently providing hot-fixes and the like via Windows Update without really change the "main" version number.

So, having DX9 V9.0c doesn't mean you are having the most updated version and for unknown (possibly very evil) reasons M$ shipped Vista (and curiously, 7) with a very outdated version of DX9, which was one main reason for some people having loads of compatibility issues with "legacy" programmes.

[9]

I don't think that's the problem, whether it's 10 or 11 it doesn't really matter, as I mentioned before, they're not responsible for supporting software for DX9 or earlier. What matters is DX9. Try to update it (as well as the graphic cards' drivers), though there's no guarantee that this must be able to solve your problems.

[9]

Try updating DirectX9 maybe?

DX10 and DX9 are completely different things and with DX10 alone programmes supporting only DX9 or earlier cannot be run properly.

So, to be able to run these programmes on Vista or 7, actually these new OSes are shipped with BOTH DX9 and DX10. However, from what I've heard, for unknown stupid reasons, the version of DX9 shipped with these OSes was extremely outdated, so programmes may not work properly. This was one main reason people complained a lot about compatibilities of software. Sometimes, after updating DX9 manually the problems were solved.

Why? You weren't joining this community because of the girl scouts? What else would you expect to find here? Adventure games? Are you kidding? 

Well... We have this thread which is pretty deserted right now.

We also have this but obviously there was never enough motivation for people to keep it active.

Last but not least, check out the not so frequently updated wiki.

This is more of a serious error regarding the software itself though (i.e. not specific personal mistakes on scripting and such). I'd rather wait for CJ to reply and say whether this is a valid solution to the problem(and why) before confirming.

Can you upload your game files for us to investigate?

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.

It could also relate to what kind of materials that were used to make the cubicle divisions and how they're mounted.

For example in this old style office I'm working at this particular second, we have old cupboards and wooden boards made to divide our working space, so there's either a board or a cupboard between each two adjacent seats. Some of these boards are actually hanging loose mounted just by a few screws on the tables or cupboards.

We had a co-worker here who actually broke two boards by leaning on them (in each case, one screw which held one side of the board on the table was broken, making the board hanging loosely at that end). These damages are never fixed and we just use some useless scotch tapes to stick the boards back on the table and have since been careful not to touch them again.

But I'll expect modern implementations with better materials and mounting could be more sturdy.

In other words, there is no definitive answer.

Just FYI. The tutorials in the wiki have been updated to work with AGS V3.1.2.
I've found some oddities with the editor that could be classified as glitches or limitations (annoying but wouldn't prevent games to work properly). I'll do more tests, especially on V3.2, and then report them on the Technical forum.

Did you read my reply?

Rooms create at the resolution of whatever the default setting was, which I consider a bug.

I think you can change that just by replacing the default room file with whatever you want. I forget the name of the actual file and I'm too lazy to check it ATM.

I think what the OP meant was that the game window itself is transparent, revealing the desktop behind.
If this is the case then no, that is not possible, probably not even with a plug-in (unless plug-ins can some how pick up whatever graphics are on the Desktop and overlap it with the game's content, which I think is not possible at all).
I'm not sure whether the bloaty fancy display options of recent OSes (or, when using some 3rd Desktop enhancements) would make windows semitransparent, but with AGS alone, it is certainly not possible.