SLUDGE 2.0 - a work in progress

[Trumgottist]

Hi-res images? Now I'm confused.

Assuming it was a typo, and you meant true colour images, it shouldn't affect performance (compared to the current Mac engine). It already runs that way internally: all graphics are converted to 32 bit when loaded. All that's left to do is adding it to the dev kit (and making the engine read the new format of files). It'll lead to a substantially larger file size, but once it's running there's no difference.

[Erwin_Br]

No, no, I meant the amount of pixels.  Bad Timing's running in 640x480, and now I'm curious how the engine behaves when going for 1024x768 or maybe even higher. The old engine could be a bit choppy especially during scrolling.

Another interesting idea I'm playing with: Wide-screen support.

Maybe I'll want to do something like creating all background graphics in widescreen format, and cropping the image by taking off percentages of the left and right side when a player has a standard screen. Or having the image scroll in that case.

[Trumgottist]

Ah. Then I understand. I think that'll be mostly memory related, too, and not so much to do with speed. Have you been drawing in a higher resolution and resizing down, or would it require you to re-do all backgrounds? (I'm still hoping Bad Timing will be released eventually, you know. )

Another interesting idea I'm playing with: Wide-screen support.

Maybe I'll want to do something like creating all background graphics in widescreen format, and cropping the image by taking off percentages of the left and right side when a player has a standard screen. Or having the image scroll in that case.

I don't think that kind of wide screen support (i.e. changeable by the game) would be straightforward to add to the engine. But more importantly, I don't think it'd be easy to deal with for the game maker (you), making the game run in two aspect ratios. I wouldn't want to deal with it. Maybe in a 3d engine, but even there one aspect ratio would be the better looking one (unless you do a lot of work to make sure both versions are as appealing). There's a reason letterboxing is more common than pan&scan on DVDs. Ok, there are at least two reasons, the other one being the increased availability of widescreen TVs, but I think I have a point there anyway.

It would be possible, but I don't think it's worth it. I say make it widescreen if you want to, but let it play with black bars on 4:3 or 5:4 screens.

[Kickaha]

I tested out with the new download loading an Italian savegame into an English instance and the text all came out in Italian as expected.

[NigeC]

Just out of curiosity is there any perticular reason why the image format is only TGA?, I've never had much success with them, Paintshop pro alway does funky things on save, when I was messing with DizzyAGE I had to drag images through Gimp to get them right


Have you sorted th memory issues?

[Trumgottist]

Just out of curiosity is there any perticular reason why the image format is only TGA?

It's a good format, as it's well documented, lossless, not too complicated and well supported. Most if not all graphics programs support it. (Internally, the engine uses its own format, so it's only for importing the images.)

Basically, the reason is that there has never been any need for anything else.

I've never had much success with them, Paintshop pro alway does funky things on save, when I was messing with DizzyAGE I had to drag images through Gimp to get them right

Oh? I don't know why that'd would have been (I know nothing about DizzyAGE, and I had no problems using PSP when I made Frasse), but I have a guess. There are two ways to store a TGA: One is an extremely simple uncompressed, and the other is run-length encoded. Maybe DizzyAGE only supports the simple format? (SLUDGE can deal with both.)

Have you sorted th memory issues?

The rumour about a memory leak was mistaken. There are some things that could be done to not waste memory that are not being done, but I don't think there's anything that would cause any problems for a normal game. As Tolworthy (the one doing the really huge game, causing him to run into some issues) has left SLUDGE for AGS, I haven't worked on improving that, but the basic fundament for reclaiming the used memory is there (it's used for fonts, just not for other sprites) so it's something that could be added if the need is found. (Or if inspiration comes, but right now I have more interesting coding problems to deal with.) I consider the engine to be in a very stable state.

[NigeC]

I guess the only way is to try! I guess with any software file formats can have a baring on the software used to create content by the original engine designer.. once I've stopped playing with no toys I'll have a go with PSP

[Trumgottist]

Good news and bad news.

First item of good news is that the dev kit is getting one step closer to becoming useable on a Mac each day. Now I can compile games in it, and I can view sprite banks in the Sprite Bank Editor. I can't edit them yet, but the view can be moved, resized and zoomed. That feels great!

The second piece of good news is that Charlie Wolf has been able to build a Windows version of the 2.0 engine. I tried it for a bit on my parents' computer. The sound isn't working, and there's no setup dialogue yet, but it seems to mostly work. I was able to play some Cubert Badbone with it.

The bad news is that Charlie can't play Cubert with the engine that he's compiled. His graphics card isn't up to the task and refuse to load any textures, showing only white polygons. (Looking a bit like the famous painting of Napoleon's white horse in a snow storm, I suspect.) But I have a theory about the problem, and I might also have a solution. I've started working on it, and plan to have it done tomorrow. (I also have a theory on the missing sound.)

[Erwin_Br]

You two seem to be working together very well. That's also good news!

[Kieran Millar]

This is great news! SLUDGE is still my favourite adventure game development kit so I'm glad to hear it's still moving forward. I'd love to help, but I no nothing about programming so I don't know what I can do.

One question I always meant to ask you, but forgot before:
The help file always stated on the setCharacterAntiAliasing page that you can set default anti-aliasing settings for characters which links to the Object Types and Events page (where it mentions things like SpeechColour and walkSpeed), but there's nothing on that page that mentions anti-aliasing. Is there a way to set default anti-aliasing settings that was never documented? I'd look through the source code myself but I wouldn't know what to look for. This would be handy because it saves me from having to constantly call setCharacterAntiAliasing every time I want to add in an object without antialiasing (such as for background objects, otherwise they stick out too much). I tried a couple of commands that such a feature might have been called if one exists, but nothing ever worked.

[Trumgottist]

Yes, there is an per-object setting for it. Use it like this:

objectType thing ("Antialiased thing") {
   antiAlias true, 1, 1;
}

Oddly enough, the first parameter has to be literally "true" of "false". The other two parameters are blurX and blurY, but the blur radius is currently ignored in SLUDGE 2.0.

A word of advice, though. If you don't want background objects to stick out too much, turning AA off has the opposite effect in SLUDGE 2.0, since things like resolution and anti-aliasing is handled differently. Objects are blended into the background and not simply blurred by themselves. This is one of the advantages of utilising the 3d hardware. (I'd like to investigate the possibility of doing something with shaders too, since that'd bring more options but haven't looked at that yet.) But the new SLUDGE is still in beta and nothing is final yet about how it'll handle those things. That's a good topic for discussion, though.

Those of you that have tried the new engine, what do you think? Are the current display options good?

The way it currently works is that any sprite that is marked for antialiasing is rendered with linear texture filtering, and the others with nearest. Backgrounds are always antialiased, unless AA is turned off completely. Games compiled prior to v. 1.6 (the version that added AA) run with AA on backgrounds but not characters.

[Squinky]

So, for sprite banks, will they work the same way as usual, i.e. no built-in alpha channels in the images, and still using magenta as the transparency colour?

[Trumgottist]

That will still be an option, yes, but I'll also add support for 32-bit images with alpha.

[Squinky]

That makes things easier for me. Still TGA, or will PNG be supported?

[Trumgottist]

At the moment, I have no plans for anything but TGA. While it should be straightforward to add importing support for another format, PNG is considerably more complex.

On the other hand, a new internal format for the new colour depths is needed, and PNG does compress well and has libraries available to handle the tricky bits, so it might be worth investigating, and maybe even using internally instead of something home-made. In that case, it'd be quite silly not to support it for input as well.

Is that a feature request?