Messages

[new thread]

Sprite imported with alpha channel shows up with black background in default inventory gui screen.  When you use it, transparency shows just fine. (3.01)

I guess to use transparency you will have to do a custom inventory GUI with a background which has alpha channel applied to it.

Alpha channels on GUIs are certainly tricky, and their support is confusing (at least to me) at the present time.

I started out a new thread regarding alpha channel sprites on GUIs, because I did not want to clutter this space. I invite everyone which is watching this thread to take a look at it, and share your knowledge!

To me, transparency in GUIs is the most confusing aspect of AGS as of now. I dont fully grasp the way AGS does GUIs with transparency yet, so I decided to write this post to see if someone can shed some light on this subject.

I know the first 'stepping stone' is to apply a background which has an alpha channel, but what I want to clarify is what happens when you want other images on top of it, like transparent buttons, mouseovers, etc.

This is what I found, so far (I will correct any wrong information in future posts):

• When you import a sprite, there is an option to use the 'top-left pixel' as transparency, and this, as I understand it, RE-WRITES some pixels as magenta in the RGB channels of the sprite. So, you should only choose 'Leave as is' when you're dealing with alpha-masked sprites. Note: If there is an alpha channel in the file, and we specifically told AGS to use it, why should we bother?
  

• any sprites which DON'T have an alpha channel will INHERIT the transparency from the background The ones that DO have an alpha channel get their transparency used. If you think this is strange, keep reading...
  

• the REAL tricky part is when alpha-masked sprites OVERLAP inside the GUI... well... I couldn't figure out exactly how this works... I *think* the RGB bits of the sprites (including the background) are drawn on a RGB buffer, from 'backmost' to 'frontmost', while the alpha bits gets drawn to a SEPARATE 8-bit buffer. Then, the two buffers are assembled to form a 32 bit image which is sent to the GUI.
  

I hope CJ can clarify the last statement, since I'm not sure...

This feature would be very useful because sometimes we are still adjusting a walkcycle, or animation, or whatever, and to see any modifications we have to erase the view, then erase the sprites, then import them all over again, assign srites to the view, etc etc.

Well, you don't necessarily have to do all that. In most cases you should just be able to import over the existing sprite, and thus all the views will still be intact.

Walking cycles use many sprites, about 10 or sometimes more, and 'Import over the existing sprite' only works one sprite at a time, so, either we select one by one, or do the delete view/delete sprites/import sprites/assign to view routine again.

Neither does it work on 'tiled sprites', because AGS does not remember the coordinates it used to cut sprites from (maybe game.agf can store this information?). When I started coding my game, I was using 'tiled sprites', but I dropped them as soon as I realized that 're-imports' would be very difficult and error-prone.

I'm starting to agree [...] The problem with that though is that it could really slow the compilation down if it was having to reconstruct the file all the time.

A solution would be to cache the acsprset file, and recompile it only if one of the sprite files is modified (or 'full build' option is chosen). This is done with .h headers in C/C++ compilers (and the feature is known as 'pre-compiled headers')

Perhaps simply adding the right-click "update this sprite" option to re-import it from its source image would be a reasonable workaround.

That would be very nice to have, but as long the above one is implemented, this one is unnecessary.

This feature would be very useful because sometimes we are still adjusting a walkcycle, or animation, or whatever, and to see any modifications we have to erase the view, then erase the sprites, then import them all over again, assign srites to the view, etc etc.

The two things are important, in my point of view. The second one is a 'time-saver', but it does not change the fact that two people can't work at the same time on the same game. The first one solves this problem, and also the nuisance in modifying walkcycles, animations, etc.

The problem is that the acsprset.spr file is large, and can easily be over 100 MB in bigger games. Most source control systems have trouble with files that big, and could become extremely slow.

acsprset.set being this big black monolith not only complicates versioning, but it somewhat undermines team work, beacuse it prevents two guys from working on different parts of the game at the same time.

Since it's a binary file, changes can't be easily 'merged'. Well, some can, but some can not. OTOH, Game.agf, being a text file, can be automatically merged, or manually, since it's human-readable, so we can always copy&paste on it. But acsprset.spr is binary, so we can not do this.

I would dare to say that the real solution to this would be to stop depending on acsprset.spr altogether, and start building the sprite index based on the filesystem. After all, the sprite files themselves could be added to version control.

I know there would be many consequences to the engine/editor, but that would be the right way to go. Maybe there is a 'in-between' solution, making acsprset.spr just a 'pointer' to files on the filesystem...   

I guess the real issue here is that for a AGS -> ScummC integration to really unfold, it would be up to CJ's shoulders to carry, since he is the only one that knows the inner workings of AGS.

I would be really happy if we could 'port' our games over to ScummVM, because this engine has been ported to practically anything, including iPhone. As soon as a J2ME port is done, it will cover the entire spectrum of platforms. This is not to be neglected.

However, ScummVM was made to support pre-existing (i mean 'frozen') games, and not to be used as a platform to build new games. I wonder how it would hold up against an engine like AGS, which was built to be as flexible as possible.

So, while I think this AGS->ScummC->ScummVM thing is really really cool, I don't know if it would be a good strategic decision. The guys at ScummVM are the first to state that in their FAQ (see 'can this be used to build new games?'). Actually, that was the first thing that went through my mind, the very first time I played 'indiana jones' in it, so I turned to AGS.

But I would love to see my game next to 'Indiana Jones and The Fate of Atlantis' in the list...

[ImageMagick]

And of course, the old biggies: functions being first class objects and pointers to structs being allowe dinside structs

And pointers being passed as parameters in functions, please... Well, I guess the two things are connected.

I second the pcx-file import. I'm trying to make a RON game and all the backgrounds are in pcx-format. Sure I can convert them but If it isn't too much trouble I'd like AGS to have this feature. 

You can use ImageMagick to convert them all at once, in a single line. ImageMagick is a command line application, multiplatform, very fast and powerful. Also, you can merge sprites together in a single image, apply alpha masking, and many other things.

Since there is such a tool, I don't think PCX suport in the engine is necessary. I would vote only for PNG and JPEG.

I guess this is (unfortunately) the way it is. I started at 16bit myself, and had to move up to 32bit because of alpha masking (only 32bit supports it), so I have sprites at 8, 16 and 32 bits... But as long as I run my game in 32bits, it seems everything is fine.

This would be less of a hassle if AGS had a 're-import sprites at game colour depth' feature. I guess it's on the near future, since the XML file keeps the path to every single sprite.

Well, it's up to you to decide if it's worth the trouble, but you could do some transparency tests on a fresh new game, since your CPU is relatively modern. Maybe it's an issue with your graphics driver.

Well, yes and no. Yes it worked, and no I can't use it. It put too much strain on the CPU to do it.

I remember that, not so long ago, I tried to see how the transparency effects were handled in 8-bit and 16-bit, compared to 24-bit, and I found that the performance was very different between the modes (8, 16 and 24).

Maybe you should also try to change the colour depth in your game, just to see if it affects the performance.

Also, please trim the quotes in your replies... remember this is a forum, not a mailing list, so we can always see the previous messages if we need to...

How do I manually set the image in the background frame back to a spesific sprite? This is the problem, right? That the game is actually changing the original (white) background image?

Maybe... There are lots of ways to restore the original frame back to its original state.

I would advise you to completely erase the 'flash' background, thus leaving only the original room background. Then, create a 10x10 white sprite, and import it into the sprite library. This tiny sprite can fill the whole screen, thanks to DynamicSprite's Resize() method, and can be drawn transparently, thanks to RawDrawImageTransparent().

I'm writing this without testing, so you may need to adjust it, but you should be able to understand the principle:

Code: ags

// script for Hotspot 6 (Hotspot 6): Use hotspot

// replace 'X' with the 10x10 sprite index from your sprite library
short tiny_white_sprite = X;

// create on-the-fly sprite from the 10x10 one
DynamicSprite* flash = DynamicSprite.CreateFromExistingSprite(tiny_white_sprite);

// resize sprite to fill the screen - you may need to adjust the size
flash.Resize(320,240);

// save the current screen in memory
RawSaveScreen();

int transp = 99;

while (transp > 0) {

  // paint the white sprite with transparency
  RawDrawImageTransparent(0, 0, flash, transp);

  Wait(1);

  // restore screen for the next iteration, or for the final step
  RawRestoreScreen();

  transp--;
}

flash.Delete();

The advantage in this approach is that you can use this effect in other rooms too, without need to replicate the background sprite, thus saving space in your final game.

Hope this helps,

Be aware that mixing RawDraw's and SetBackgroundFrame's can be tricky. When you do SetBackgroundFrame(), you're actually changing the 'target' of the subsequent RawDraw's. I guess this is why it's working the first time.

Also, when you RawDraw something with an increasing transparency, like you did, you should restore the background to the original state in the next iteration, otherwise you'll be adding to the previous transparency.

Example:

The 1st iteration will draw the frame 0 with 99 transparency over background 1;
The 2nd iteration will draw the frame 0 with 98 transparency, right above the 99 transparency that was drawn on the last iteration;
The 3rd iteration will draw the frame 0 with 97 transparency, right above the 98 transparency, with was drawn above the 99 transparency;

and so on...

Hmm...  Why do you do RawRestoreScreen() if you do SetBackgroundFrame(1) right after? The RawRestoreScreen() seems pointless to me... maybe you should comment it and see what happens.

Anyway, I guess you shold also place the Wait(1) before RawDrawFrameTransparent(0, trans), so SetBackgroundFrame(1) is guaranteed to repaint the screen.

Everytime I try to change rooms I get an error reading "(no such script in function) trying to run room_leave" I need help!

I guess you manually (or accidentaly) deleted the function which was bound to the 'Leaves Room' event in Room 3.

Look in Room 3 events, there should be a function in the 'Leaves Room' event which is missing in your code. Either clear the name, or write a function with the same name.

Changes in 3.0.1 Final:
* Added System.NumLock/CapsLock/ScrollLock properties

Wohoo!! Problem solved, I guess... Thanks, CJ!

You can possibly detect if the caps lock is on by requiring the user to press the 'A' key at some point, and reading whether it returns 'a' or 'A', and whether either shift key is held.

Actually, this won't work, since the keycodes for lowercase and uppercase are the same (as per the current manual).

I guess there's a bug in AGS 3.0.1 RC2.

I tried to write the following line in my script:

gStatuslineLabel.Text = "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.";

then AGS couldn't parse the script, saying that there was an error:

Parse error in expr near "Lorem ipsum..."
File: room1.asc
Line: 1701079407

then when I removed the line and tried to run it, the following message appeared:

Error: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
Version: AGS 3.0.1.32

System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. ---> System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
   at ccCompileText(SByte* , SByte* )
   at AGS.Native.NativeMethods.CompileScript(Script script, String[] preProcessedScripts, Game game, Boolean isRoomScript)
   at AGS.Editor.AGSEditor.CompileScript(Script script, List`1 headers, CompileMessages errors, Boolean isRoomScript)
   at AGS.Editor.Components.RoomsComponent.SaveRoomOnThread(Object parameter)
   at AGS.Editor.BusyDialog.RunHandlerOnThread()
   --- End of inner exception stack trace ---
   at AGS.Editor.BusyDialog.Show(String message, ProcessingHandler handler, Object parameter)
   at AGS.Editor.Components.RoomsComponent.SaveRoomButDoNotShowAnyErrors(Room room, CompileMessages errors, String pleaseWaitText)
   at AGS.Editor.Components.RoomsComponent.RecompileAnyRoomsWhereTheScriptHasChanged(CompileMessages errors, Boolean rebuildAll)
   at AGS.Editor.Components.RoomsComponent.AGSEditor_PreCompileGame(PreCompileGameEventArgs evArgs)
   at AGS.Editor.AGSEditor.PreCompileGameHandler.Invoke(PreCompileGameEventArgs evArgs)
   at AGS.Editor.AGSEditor.CompileGame(Boolean forceRebuild, Boolean createMiniExeForDebug)
   at AGS.Editor.Components.BuildCommandsComponent.TestGame(Boolean withDebugger)
   at AGS.Editor.Components.BuildCommandsComponent.CommandClick(String controlID)
   at AGS.Editor.ToolBarManager.ToolbarEventHandler(Object sender, EventArgs e)
   at System.Windows.Forms.ToolStripItem.RaiseEvent(Object key, EventArgs e)
   at System.Windows.Forms.ToolStripButton.OnClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleClick(EventArgs e)
   at System.Windows.Forms.ToolStripItem.HandleMouseUp(MouseEventArgs e)
   at System.Windows.Forms.ToolStripItem.FireEventInteractive(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStripItem.FireEvent(EventArgs e, ToolStripItemEventType met)
   at System.Windows.Forms.ToolStrip.OnMouseUp(MouseEventArgs mea)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   at System.Windows.Forms.ToolStrip.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

I had to close AGS, saving the game, and after AGS restarted, all went back to normal.

A quick way to sort this out is to only set the flag after the key is released.

Hmm. It does not solve the 'initial state problem', but it's a good idea. How about this:

Code: ags

  if (IsKeyPressed(426))
    capsdown = true;
  else if (capsdown) {
    capslock = !capslock;
    capsdown = false;
  }

It works, but uses two 'flags'... any other ideas?

...which would work great unless the user starts the program with CAPS already on

Exactly. The ideal test for CAPS LOCK should be like mouse.Mode, or something, otherwise the state of CAPS LOCK is not accurate.

Besides that, IsKeyPressed() returns true only if the key is being pressed at the moment, so if you test for it occasionally, you might not get it, and if you test for it in rep_ex_always, you might risk setting the flag many times.

This naïve approach definetely does not work:

Code: ags

function repeatedly_execute_always()
{
  if (!capslock && IsKeyPressed(426))
    capslock = true;
  else if (capslock && IsKeyPressed(426))
    capslock = false;
}

because since it is executed many times per second, the flag is unset right after it was set, should the user hold the key down for more than 1/40 of a second... and most of us are not THAT fast to hold it for a shorter time.

[Thanks for that insight (would most likely be on a server).]

Thanks for that insight (would most likely be on a server).

In that case, you will need to code the server too... I dont know if RakNet provides a server, but it would be great...

I'm probably going to go with AGS since the knowledge base and friendly folks here seem much better.

That's very true...

I was wondering if there's any way to check for Caps Lock being on/off (like you can check for Shift being pressed)?

I found out that IsKeyPressed(426) detects if the user pressed CAPS LOCK, but I guess there is no way to know whether if it is activated or not.