Messages

I remember there was other way to make racing games in pseudo-3d style; don't know how it is called properly.
The track is stored as polygons in 3d, but in game it is drawn by horizontal lines.
Hopefully what I say make sense, cause I can't figure how to explain this better.

Maybe this: http://en.wikipedia.org/wiki/Scanline_rendering

Editor and engine executables with a fix, if anyone wants to test:
http://www.mediafire.com/?ta43i8g5lvh4qg4
!WARNING! based on 3.3.0 beta, so don't use it with your only real game copy.
There's an extra choice for Alpha gui rendering style in Global settings.

It looks OK as far as I can tell, but it's hard to evaluate with such a weird example. I'd probably just try to overlay two 50%-transparent white sprites on a black background, as well as maybe a blue and a green sprite.

Spoiler

[close]

//------------------------------------------------------
EDIT:
There's a problem with transparent gui parts, this new blender treats magic pink as an actual color, and the result is blending translucent  control parts with with magenta.


//------------------------------------------------------
EDIT2:
Something that worries me is that when I am putting a button with "shadow" (see early posts in this thread for an example) on the translucent gui background, the shadow part becomes brighter rather than darker.

Well, 1024 x 1024 x 360 = 377.487.360.
8-bit sprites: ~400 MB
16-bit sprites: 750+ MB
32-bit sprites: 1.5+ GB

This will make it perhaps the most memory consuming AGS game ever...

But I still don't understand, I remember there was an 3d engine plugin by DKH, why could not you use that for instance? Surely rotating camera over texture would be far less hassle.

Game is really fresh looking and colorful!

I decided to give this another shot, and started over from scratch.
Here's a preliminary demo: download

That's just cool .
Just a small suggestion: set Multitasking Mode while level is loading so that the loading won't freeze if user switches to other window (may be annoying for long load times).

We took out the sprites that caused a 'hole' in the gui, but we still have the ones where alpha is displayed as opaque black.

IIRC the "holes" are caused by inventory items, because they were not fixed by CJ when he added new alpha blending.
Opaque "alpha" bug happens with other controls (e.g. buttons).
If I'll be able to find proper blending algorythm I will need to apply it to both cases, and it will work identical for all gui sprites.

I asked about games because I wanted to make tests and see that I did not screw anything.

Bum Runner?

I added combined opacity as Snarky suggested, hopefuly I implemented his formula right:

Code: cpp

back_alpha = (255 - (255 - geta32(x)) * (255 - geta32(y)) / 255) << 24;
<...>
return res | g | back_alpha;

Here are the comparisons. The control with left translucent part over translucent gui over room:

Spoiler

AGS 3.2.1:
[imgzoom]http://imageshack.us/a/img560/8018/agsalphatest321.jpg[/imgzoom]
My test:
[imgzoom]http://imageshack.us/a/img7/9440/agsalphatest330combine.jpg[/imgzoom]

[close]

The same control over opaque gui:

Spoiler

AGS 3.2.1:
[imgzoom]http://imageshack.us/a/img221/6731/agsalphatestsolidbkg321.jpg[/imgzoom]
My test:
[imgzoom]http://imageshack.us/a/img7/9413/agsalphatestsolidbkg330.jpg[/imgzoom]

[close]

Does it look OK now?


//---------------------------

combined_alpha = 1 - (1-front.alpha)*(1-back.alpha) (where front is the gui control and back the gui). That way, two 50% transparent layers on top of each other combine correctly to 75% opacity, rather than 100%.

This way if the control is opaque, the summ will always be opaque regardless of back surface alpha. Is this correct?

Because from the way I'm thinking of it and what calin is saying.

I haven't seen Calin saying anything that would suggest that there's a problem of fitting everything in one game.
What he said is that AGS script is too slow to program quality rendering in the race game.
Game speed does not depend on how much levels and menus you put into a game, because engine does not update all levels at once, naturally, only current room.

When you create a game with AGS, it makes project files in folder that you specify. AGS 3.2.1 does this in "My Documents" folder by default, AGS 2.72 and lower default was to keep projects in subfolders inside AGS editor folder (but this may be changed). All source code is stored there. Normally, uninstalling or reinstalling AGS should not make any impact on your project integrity.

If you are interested in checking that all your project is in place, these are files that matter:

Game.agf - main project file (AGS 3.+).
ac2game.ags and *dta files for AGS 2.72 and lower.
*.asc and *.ash files - script modules.
*.wfn and *.ttf - fonts.
*.crm - compiled rooms.
*.ico - custom icon.
acsprset.spr - imported sprites.

Anyway, is this really something AGS has to solve? Aren't there already library functions in Allegro or whatever that allows you to combine two graphics with alpha-channels and get the correct result?

Allegro is made as a "wireframe" where you may connect your own callbacks to many of the operations, blending being one of them, so this approach is principally valid.
As for built-in blenders, unfortunately standard Allegro's alpha blender doesn't work, because it copies the resulting pixels with zero alpha value; if drawn this way all the translucent controls will create 100% transparent holes at their places on main gui surface.

Good news though, while examining the Allegro source code and comparing with various CJ's custom blenders I found that I may simply copy default Allegro's alpha blender and modify it so that it will keep alpha value. The result is almost what we need, I think, minus summing the alpha (alpha remains the one of the main gui surface).

Here's code:

Spoiler

Code: cpp

unsigned long _myblender_alpha32(unsigned long x, unsigned long y, unsigned long n)
{
    unsigned long res, g, alpha;

    n = geta32(x);

    if (n)
        n++;

    alpha = y & 0xff000000;

    res = ((x & 0xFF00FF) - (y & 0xFF00FF)) * n / 256 + y;
    y &= 0xFF00;
    x &= 0xFF00;
    g = (x - y) * n / 256 + y;

    res &= 0xFF00FF;
    g &= 0xFF00;

    return res | g | alpha;
}

[close]

//=========================================================
EDIT: how it looks like.
Room background is an AGS editor splash, gui is a yellow rectangle with alpha gradient (lower alpha towards left side), and gui button is poor guy from Laura Bow 2 in sarcofagus (keep forgetting his name, Dr. Carter maybe?). Gui button graphic is divided into 2 parts: left half is translucent and right part is opaque.

Spoiler

AGS 3.2.1:
[imgzoom]http://imageshack.us/a/img560/8018/agsalphatest321.jpg[/imgzoom]

My test:
[imgzoom]http://imageshack.us/a/img832/6765/agsalphatest330.jpg[/imgzoom]

[close]

Wait wait wait, actually nevermind the post above... I probably had brain block.
Main gui surface is rendered over "temporary" bitmap, and then controls are rendered over the same temporary bitmap.

Then temporary bitmap will be drawn over screen.

"additive opacity" refers to the alpha within a surface.

So the GUI is a surface in and of itself and if you have a button with .5 alpha and the background graphic has .5 alpha, then the total alpha should be 1 but *only* within the surface. If the GUI has its alpha set to .5 this does not effect the alpha of the surface itself but rather the drawing of the surface to the back buffer.

Yes... now I remember thinking like that.
And also I remember why there was a problem to do this correctly.
Both the gui and controls are drawn directly over room background, there's no intermediate step which would allow to draw gui controls with their opacity on gui background, then draw main gui on room with its own opacity. When gui controls are drawn, they are drawn over room, which already has main gui pixels over it .

Well, I wasn't aware of what this meant for, that's why I kept summing alphas; the global setting is called "Additive Opacity" after all. But I can clearly see this is not what normally people would like, because when you put an alpha control with e.g. a shadow on top of translucent gui, the shadow part actually makes main gui brighter (or rather more saturated), because alpha is increased.

The method you suggested sounds right. I guess overlaying controls may work in current engine, because controls are drawn with regard to z-order, and their colors will summ up at the main gui surface (or temporary bitmap, to be precise).

Regarding backward compatibility, the question is, were there games with translucent guis and gui controls made with the new blending method in such a way, that would be broken if this method is fixed. This new blending function was introduced in AGS 3.0.2, so it is there for a while already. In the worst case, we may add another option which would select the fixed blender for the game - this would act as a temporary fix before per-control blending property is implemented.

That still does not account for the gui buttons which are of reasonable size.

FYI When cursor over the gui with buttons the cursor changes to pointer then returns old mode when leaving.

Well, can you give some details about them?
How does it work for you and what does not work for testers?
How do you change cursor to pointer (what script command do you use?).
Is the cursor hotspot positioned correctly (on the tip of the pointer, and not in the center)?

How scaling bug may prevent completely from interaction with gui buttons and objects? Unless they are very tiny or something... can't think of any situation when this might be a real issue.

Slasher, just make someone test the problem in both renderers and see if there's a difference.

Am I advised to try and update to D3D (9) rather than sticking to DirectDraw as some on D3D seem to get problems?

I suggest you find a tester who will be able to run BOTH DirectDraw and D3D renderers, and see if there's any difference in your game. This way you will at least know if those errors are even related to renderer.

BTW, another thing, does your game use any plugins?

[@slasher]

@slasher, I have certain doubts the problems you mention may be related to the renderer. At least, it would be quite surprising if they are.
Do you use any advanced drawing methods in your game? Raw drawing over guis, creating dynamic sprites? Any sprites with alpha channels, any objects with translucency?
I really can't think of much here.

Try to separate problems and check every one in turn.
Ask people to list what and how exactly did they do when interaction did not work.

I am giving up my turn, don't have time to find something interesting right now.

Lost Eden by Cryo?
That was my first PC CD game