Messages

It in general good practice to remove unnecessary transparent borders.

This is true, although it's very handy to leave some space on all sides of sprites that are being animated, in case you decide to make a character move his arms around or something. I've often made the sprite borders too small and it's come back to bite me in the ass many times. Thanks for the reply.

I'm just wondering... If I've got a large sprite with a huge transparent area (that pink colour in the editor), will the transparent area make your game bigger or does AGS have a method of removing / compressing this irrelevant data? A bitmap image will be huge in size even if there's just one colour in there... Do you have to be careful to crop away parts of sprites that the game will view transparent?

You've got to be prepared to do some scripting to get your alignment system up and running, but you can find all that in the manual or by using common sense (seeing as you familiarized yourself with another game making program). Just a heads-up.

Does anyone NOT use scripting when making an AGS game these days? It's awfully slow to use those pulldown menus to make a game...

I didn't question his ability, Dual, but I have to admit I don't appreciate his tone. It's a minor point however.

No offense, but he said what everyone else was thinking... You are, however, welcome to share your problems on the board once you've got the art stuff figured out.

In the mean time, why don't you make your game featuring crude mspaint art until you've got an actual artist? That's what I do, then just replace all the art when the game's somewhat up and running.

This is a great way to figure out if your spites / backgrounds work or not. You can save yourself a lot of work and heartache by using simple paint art until you've nailed the gameplay elements. It all depends on how polished you want it to be, of course.

You're making a webcomic without any artistic ability? If you're making a webcomic, you're going to have to resort to some kind of art, no? Wouldn't the best thing for the game be to have the game look the same as the comic?

If you're really desperate though, and photoshop and google image search and throw some images together. I'm warning you though... ain't gonna look pretty.

Sure that scene with Ben could be done it AGS. Easiest way, I suppose, is making it with objects. Or just making a talk animation if it's a character like Ben you're trying to animate. You've got to learn the AGS scripting to make cutscenes, though.

Damnit, sometimes I just wanna knock my head into the wall. Thanks KhrisMUC!

Edit: Actually, I used the eEventRestoreGame to interrupt and turn off the camera GUI seeing as it should only be displayed after you have saved, not loaded. Works like a charm.

I've got my own little save and loadgame menus all set up nicely. After I press save, all menus disappear. To let the player know it was a successful save, I've added a GUI with a camera and the text "game saved" that animates in the corner of the screen with a flash sound. It works brilliantly. However, when I load that savegame, the same camera makes another appearance, which makes sense seeing as the game continues right where it left off.

To stop this camera from animating another time after loading, now that's a tricky one. Is it doable? I can't quite find some piece of code or function to detect whether or not the game was just loaded or not. My best guess is to interrupt this GUI by turning it off via repeatedly_execute_always in the main global script... But then again, how to detect it? 

Aha! Thanks you guys, it works perfectly now that I'm using savegame indexes 101 and so on! It's amazing how much you guys know about this little editor...

I've got four savegame spots that each creates its own savegame file ranging from 1 to 4. If I save games at savegame spot 1, 2 and 3, agssave.001 through agssave.003 will be created. However, if I delete savegame number 2 through the game, AGS rearranges my savegame files so agssave.003 becomes agssave.002. Is there any way to stop the engine from doing this? It's causing problems.

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...

Seeing as how I converted from 16 bit to 32-bit by mistake somewhere along the road, a lot of my sprites are imported in the highest colour mode. If I try to run my game in 16 bit it will run, but a lot of sprites have a nasty tendency of just disappearing randomly from the screen (and never reappearing) when playing. Does this make sense at all?

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

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,

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. Thanks for all the help guys, I guess I'm gonna have to ditch the flashy thing and come up with something else. Consider this thread solved.

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 drawed 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...

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?

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.

The manual says you should throw that function in there before the calling RawDrawFrameTransparent... Either way, if I comment it there's no change...

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

Tried this too, nothing new happens. It still does not fade the background the second time.

Why not have a fullscreen GUI on top of everything with your all-white BG and then change the GUI's transparency?

I've tried this with both an object and a GUI but it totally butchers a 2.4 ghz PC. The game's in 640x480 24 bit.

Code: ags

   
// script for Room: Player enters room (before fadein)
SetBackgroundFrame(0); // frame 0 is the normal background
RawSaveScreen();

   

Code: ags

   
 // script for Hotspot 6 (Hotspot 6): Use hotspot
RawRestoreScreen();
SetBackgroundFrame(1); // frame 1 is a totally blank frame, indicating a strong flash

int trans = 99;

while (trans > 0) {
	RawDrawFrameTransparent(0, trans); //fade in the normal background
	trans--;
	Wait(1);
}

SetBackgroundFrame(0); // go back to normal frame
RawSaveScreen(); // save current frame (don't know if this is necessary after already saving it in the before fadein script - either way it won't work the second time)

This code is supposed to be a quick flash of white that will fade into the normal screen. However, the fading script will only work the first time, and not the following times. Any ideas why?

Covering all the topics in the manual would take years, so I think that's out of the question. Have you tried searching the forums and finding a topic that covers your problem? Scripting in AGS can be quite advanced for beginners, it will take time to learn all you want to learn.

I'm using 2.72 still, as I've been working on a project for a couple of years. I tried importing it into 3.0 but it gave too many error messages, so I'm sailing this boat ashore and jumping ships later.

Or:

Code: ags

function RandomPointOnRegion(int reg) {
  int x = -1;
  int y = -1;
  while(Region.GetAtRoomXY(x, y) != reg) {
    int x = Random(319);
    int y = Random(199);
  }
  // use x, y
}

Thanks a lot guys for helping out. Question for you though KhrisMUC: Won't your code slow the engine down? Especially when running your code with small regions?

Ah, sorry about not being clear enough. Let's say there's a rawdraw line going across the screen. Now, if I want AGS to select a random coordinate on this rawdraw line, how do I proceed? Also, is there a similar way to draw a random coordinate from a region?

I'm just wondering what the best way of drawing a random coordinate that lies on a Rawdraw line is? Is there a way for the engine to select a random coordinate from a region also? I've tried for quite some time but I don't quite know where to begin.

Edited to clear things up a bit...