Messages

20 people seems like a reasonable target, last year we had 17 in Italy so I'd expect about the same again this year as it's still in Europe.

As for length, personally I think 7 days is about right; we might start to get bored if we did 10 days. People can always stay longer if they want (eg. I'd be up for spending a couple of nights in Dublin before/after mittens).

Interesting, thanks for the detail. I'll investigate it further.

Is anyone volunteering to host / book it this year?

Basically, if you search for "string" then you can never, ever use the Find/Replace dialog to then look for "String" instead (without being forced to use a case-insensitive search of course). The Find/Replace cache is persisted into the system memory, so the problem itself persists not only when closing and reopening the editor, but even when opening a new project!

Agreed, I think this is annoying enough to disable the autocomplete in the combobox, so I will do so.

P.S. Is there a free SVN program that can be easily integrated/interoperated with VS Express (2008 or 2010)? I would like to start taking a look at the latest branch of the source, but I've been coming up empty-handed in my search for a program..

VisualSVN will integrate but I think it's a paid-for product.
Otherwise just use Tortoise SVN to get the code onto your hard drive, and open it locally with VS.

What colour depth is the game, and does the problem happen with both DX5 and D3D?

The /Newsite website is not yet operational, it is a beta preview of the new website; you shoudln't be using it.

Where did you find a link to that page?

Ok, this is now fixed and I have uploaded an RC 1 release with the latest changes.

I am planning for this to become the official 3.2.1 release to the website unless anyone finds any bugs now, so please give it a test!

The script editor has to be the active control within the main editor form, but the main editor form doesn't need to be the ActiveForm in the application, I think.

Before it does the actual replace it can switch the focus to the editor window, but it needs to switch it back to the popup dialog before control is returned to the user, I think.

Using an xml file in AppData folder instead of registry -- fine. It probably is easier to maintain and extend that way. Just make sure that all the existing preference settings are preserved and copied across from the registry the first time someone uses the new version.

I think rather than using "object" I'd prefer some sort of Preference<T> class that could be strongly typed to the type of data the preference was storing. Something like:

class Preference<T>
{
 public string Name { get; set; }
 public string DisplayName { get; set; }
 public string Category { get; set; }
 public T Value { get; set; }
}

each component could then register its Preferences on startup, and the core editor code could read/write these from the xml file.

Any thoughts?

It's an issue with the way the compiler parses expressions containing static variables.

It's purely a compiler error, the engine would accept it fine. However the compiler is part of the Native DLL which is not yet open-sourced.

Arg, sorry about this! Restarted it.

Sorry about this, it seems like the server doesn't have enough RAM to run ASP.NET and keeps shutting it down.

I've restarted it for now, but I probably need to upgrade to a better server before we can go live with the new website.

I've also extended the nominations deadline to 1 Feb at 23:30 GMT

this is a general problem with the compiler using static variables inside a non-static, you get the same problem with:

int hour = DateTime.Now.Hour;

It does need to be fixed.

Strange, you shouldn't get any errors like that.

Could you upload the game files so that we can take a look and see what might be wrong?

Ah thanks, yeah that makes sense. Maybe we could add an extra parameter to ZoomToFile, to tell it whether to activate the script editor or not, and pass it in as False when called from the Find dialog?

Checked in a fix for the breakpoint marker issue.

Also added the MarginClick event and enabled toggling of breakpoints by clicking the margin like VS.

Thanks.

Also, with the new scripting I have to say I'm not fond of the the +/- compressing/opening parts of code.  I keep triggering it by accident simply by clicking anywhere along the left pane and would like some way to disable this functionality as A) I have no use for it and B) It's annoying and distracting behavior. 

I agree that we should have an option to disable this, for Calin would you mind just adding this to the existing EditorPreferences class?

However, regarding the code folding, would it be technically feasible to implement it in a fashion more similar to Visual Studio? The way it's currently implemented is actually somewhat annoying to me because it leaves the opening brace behind, which if the opening brace is on a separate line looks rather bad IMO.

It uses the built-in Scintilla code folding; it's possible that upgrading to a newer version of scintilla might improve this.

An example of this is the control-f search and replace gui which after conducting one search loses focus and must be clicked on again.

I agree that this is annoying, can someone please have a look and see if you can work out why this is happening?

Excellent! Glad to hear it, I'll include this in the next release.

Excellent spot, Nefasto!
I've just made the change you suggested, and the problem seems to be fixed.

Can you guys please try this patched ACWIN:
http://www.adventuregamestudio.co.uk/acwin.zip
and see if it resolves the problem?

I would think the floats are either rounded up or down in some cases with DX9.

As Calin says, the fault here is too big to be a simple rounding error ... something else must be going wrong, but I'm not sure what it is.

Why is a shader used for this? Surely using a shader stops old graphics cards from using the dx9 mode?
Why can't a colour value just be passed to the d3d matrix?

As far as I know, a shader is the only way to achieve this type of tint. If you can get the same result without using a shader, then that would be great, but I don't think it's possible.

Then I have another idea. In your shader txt you posted, in the hsv_to_rgb function, would it be better to write the if conditions like this :

I think it's ok, because of this:
float var_i = floor(var_h);
which ensures var_i is rounded down to an integer

I am very confused.
Why are you converting to HSV at the engine level, and then in the shader, converting back to RGB?
Is it possible to keep everything in RGB space?

The way that the AGS tint has always worked is that it takes the H and S of the tint colour, and combines them with the V of the pixel. In order to be consistent with the DX5 tint, the D3D shader therefore needs to do the same thing.

(1) You calculate something you call a luminance, then feed it as the value parameter to hsv_to_rgb. It appears that you are confusing HSL and HSV. It could just be that you are using the wrong names for things, but it's something to double check. Note that S calculated from a RGB->HSV calculation is a different thing to S calculated from a RGB->HSL calculation.

Good point, it is HSV, the GetLuminance function is badly named and should be GetValue really.

(3) To adjust for the transparency, you subtract (1-transp). I would expect instead you to multiply by (1-transp). I can't see that being the cause of your problems, but it's something to check.

I think this is ok, as transparency is actually a float4 where transparency[0] is the transparency, and transparency[1] is the light level; it multiples by (1-lightlevel) to darken the image if applicable.

What does the Allegro side look like?

I think the Allegro code is ok, because the HSV result that it returns seems reasonable in the example I posted above.

This is quite mysterious, Calin how did you discover that 0.947 is being passed in to the shader?

The RGB->HSV conversion in the engine uses the standard Allegro rgb_to_hsv function. I've checked the HSV values being sent into the shader, in the example I tried they were:

RGB(232,134,81) -> HSV(0.1137, 0.65, 0.91)
RGB(232,134,80) -> HSV(0.1140, 0.65, 0.91)

which seems quite reasonable... unless there's some sort of problem with the way one of the values is getting passed from the AGS code into the shader. Not sure how we would debug that?