Messages

Don't consider this too complicated. The point is, no matter what format you save your graphics files in, it makes no difference in the game's size, as long as the image is the same. So, don't waste your time in finding plugins/programmes that tend to pack an image better to produce a smaller file.

Take this as an example:
You save the same image as a BMP file and a PNG file. As the BMP format is not compressed (99% of the time), the BMP file will obviously be larger in file size in comparison to the PNG. However, if you import the image as a sprite in AGS, the file size would be the same regardless of the format the original image was saved in.

If I understand correctly then, if I import an uncompressed png (120kb), AGS will compress it as if I already did it manually with an external program (like png gauntlet)...and ends up, say, 60kb...so If I imported tha compressed png into AGS, that sprite wont be further compressed cause its already at its maximum compression...right?

It does not really work like this. It will just take whatever the image is like (not the file) and compress it with its own algorithm. So, for your "that sprite wont be further compressed cause its already at its maximum compression" part it's practically incorrect. What AGS does, is that you may assume it first expands the images to their uncompressed, raw format and then compresses them with its own algorithms. Since AGS uses RLE for sprites, which is a far, far inferior scheme than those used in PNGs, you'll expect that the sprites would take up more space in the game than the original PNG file.

... optimizing png
...plugin

That doesn't matter, if you're making an AGS game. This is because AGS would use internally its own compression algorithms on its graphics (RLE for sprites, if 'compress sprite file' is checked, and 'something better' for backgrounds), so no matter what you use for storing the graphic files for import it won't affect the size of the AGS game. Of course, still, graphics with large area of flat colours would make a smaller game.

I having read the codes, but if you want the d3 part to be in front of the player, maybe you can draw them on another DynamicSprite instead of the background?

Maybe you can also use FollowCharacter() to let the engine automatically align the sprite with the character.

I reread your codes and I know what's the problem now.

The problem is this, when your character is facing right (loop 2), you animate him using loop 1. So, as the codes are in repeatedly_execute(), in the next game frame, the if (playing.Loop==1) part would be run again, i.e. forcing the animation to face left (as when you press a key the duration would quite possibly be longer than a game frame, so the IsKeyPressed() part will still be taken in the next frame).

There're many ways to fix this, one suggestion is to use some variables to keep track of whether a key was pressed in the last game frame and don't do any more thing if the same key is still being kept pressed in the following frames. A simpler solution is, however, do not use loop 1 and loop 2 in those action animations.

Hmmm. Where are the codes that you use to set/change the loop of the character?

Confused me as such too, but I think his "until it's possible" part meant that "it's not possible with the current version of AGS yet, but I'll do such a thing when this can be done in a future version". However, if this can be done in a future version, that means AGS ould support joysticks natively already, unless that said dll-less plugin (which should be called a script module instead) does management jobs like whether a button is held for a while or whether a QCF motion is detected.

You may use a loop to check the entries of the listbox until a match is found.
For convenience, you may write a function like this (untested):

Code: ags

function FindInListbox(String text){
  int ii=0;
  int index=-1;
  while(ii<listbox.ItemCount){
    if (listbox.Items[ii]==text) {
      index=ii;
      ii=listbox.ItemCount;
   }
    ii++;
  }
  return index;
}

This function will return the entry with the first occurrence of the "text" parameter and return -1 if it is not found.

So, your code could be like:

Code: ags

if (FindInListbox("blank")>=0) {
}

They're actually AGS games that couldn't be played even on some system of the same era.

Some older versions of AGS had certain bugs (possibly memory bug) that would make the games crash on some system. Some games just had bad scripting.

[Edit:]

So you can be sure that Chinese calendars will ALWAYS start on Mondays. Its also way more logical than naming your days after Celestial bodies, Norse Gods and Roman Gods.

No. I haven't really dug deep into the topic (i.e. maybe just reading the Chinese Wikipedia article would give better explanation), but as far as I guess these one, two, three, etc. stuff were possibly adapted from the western counterparts.
In ancient time, we Chinese DID use Celestial bodies to name the week days. This practice is still used in Japan (and possibly Korea) but we changed that (with the exception of Sunday that we still use Sun/Day (Sun and Day are interchangeable terms in Chinese for obvious reasons, so are Moon and Month, funny, eh?) to refer to it and it's a bit incorrect to say that Tian refers to 'Heaven' as it's probably used in the context that it means Day) probably just because of convenience.
Also, 99% of calendars would put Sunday on the first column.

In Hong Kong here, it is actually enforced that Sunday is the first day of the week (though some people would use this incorrectly like saying 'from Monday to Sunday'), but I think it's probably mainly a British convention. When we wrote textbooks we made sure that we taught children that a week starts from Sunday. When I inspect the exercises from say item banks, etc. I also make sure that this rule is followed.

Edit:
All right. I've checked the Wikipedia article. The Chinese version is short but it is straight to the point (if only its information are all accurate). We have the transition to using one, two, three... for only about 100 years. When we still used Celestial bodies for the names there was no confusion (i.e. Japanese and Korean should still be okay with this as they hadn't changed this practice). Sun-day was the first day of a week for sure. But after that change in names certain people have changed their preference, leading to the confusion in some districts (seems that there isn't any unified standard for Chinese speaking people now and this confusion mainly lies in the Mainland). Hong Kong is never affected as it uses British convention. Sad thing is, the ISO-8601 standard now uses 1 to represent Monday and 7 for Sunday.

Famicom uses 8x8 2bpp tiles/sprites and colour 0 of each pixel is transparent (for sprites; for background tiles it's always shown as the colour 0 of the first background subpalette). Thus each pixel in a sprite can only have 1  transparent colour and 3 solid colours.

You're not always limited to this for your characters and stuff in a game though. As I mentioned you can use overlaying to create more colourful graphics (Rockman is a very good example), at the expense of using more sprites, since the hardware can only display 8 sprites in a row simultaneously. If you break this limit flickering (or stuff disappearing, which is considered bad programming by some) occurs.

In some games, especially RPGs where characters/monsters are static most of the time, stuff are usually drawn as background tiles. In such case people may even put one or two sprites on top of the background to make them more colourful. DQ4 certainly did this (possibly in DQ2 and 3 as well, but not in DQ1). I think FF3 might do this as well as its enemies were mainly backgrounds. (Note that from what I see in Mobygame's screenshots, I'm certain that the player characters have 3 solid colours only, as the background colour is black, which would create the illusion that the characters having an additional black colour for their outlines).

Another usual way of making stuff more colourful, is that say if a character is 16x16 pixels in dimension you can apply different subpalettes to the 4 8x8 (or 8x16 depending on the mode used) sprite cells used, which is what you described in your post (unfortunately due to the stupid design of the PPU subpalettes are assigned to every 16x16 blocks in backgrounds, and that's one reason most Famicom games have maps assembled by distinctive 16x16 blocks).

[import]

To clarify the use of import it does not have to be in a script header at all.

Yeah, of course. If you only want a function declared in say, the global script to be used in only a few rooms of the game you can just import that function on top of these rooms' scripts. I do this all the time. However, for a normal user, it's simpler to do this in the headers so that all the scripts have access to the function.

I think you can just post in their own forums, especially the international section. They even have a thread for this. (Oops. That thread is for translating from English to French)

Though MMM games are mainly made with AGS, most of the episodes were initially in German (or some European languages, such as French, other than English) and the people involved seldom really talked about their games or posted progress here (I know that some of them did post here, just didn't talk much about the MMM games, not until an episode is translated to English at least), therefore AGSers who don't dig much outside of this territory (like me) won't know much about what they have done.

To translate an AGS game you'll need to have a translation source file from the game's author and after you fill in the text you'll need to send the file back to be compiled as an usable translation, so your best bet is to post in that forum aforementioned.

[Edited:]

As Nightwatch was made in 2008 it's highly possible that it's using the Windows engine already, so there is no point to try it with DOSBOX (I'm quite surprise that it even starts to run at all in DOSBOX).

If for some reasons you cannot run it with a "modern" Windows system all you can do is to try out the compatibility modes or virtualisation.

In fact, for old games made with versions of AGS not old enough (i.e., V2.13 and later) to have only a DOS engine, another method worth trying is to run those games with the Windows engine (instructions here and to setup the games just read this). The engine executables could be obtained by downloading the corresponding AGS package of the correct version.

Edited: Oh, it seems that you're talking about the RON game and it seems that some people did have problems trying either method. I think it's all about luck then. SOme people may be able to play it and some may not.

Hmmmm. As I didn't pay extra attention to how stuff progress at the time I could be wrong, but this is my guess:

For RON, people actually came together wanting to make games, so it's already been a given that they knew what kind of materials (style, etc.) they're going to create as a collaboration effort at the beginning. And thus people had the momentum of really start making games. It's only until later when more people attempted to join and more games were released that made it troublesome to keep the continuity of the story.

But for InstaGame, its initial goal was to make a selection of read-to-use generic materials (whether they're supposed to be used as place holders or actual content is irrelevant IMO), so the artists may not even have planned to use these stuff in their own games themselves (so they'd just lost interest in contributing after a while) and that unlike RON that you have some basic settings to follow, it is actually more difficult for people to make good use of the theme-specific materials in InstaGame with their own made-up universe (like Ali mentioned it's difficult to make 'general use' stuff for adventure games).

Right now I'm making the first scene tiles. I do everything with nes restrictions in mind. If I should finish this mock-up I will upload it to Pixeljoint.

Counting the (green) transparency colour the character has 5 colours, which don't fit into the Famicom's sprite format, unless you do sprite overlays (like what they did in Rockman's face).

Related to Insta-Game, why do the files download with .pcx extensions? I can view them, but if it's not just me it's a weird format to have them in.

Because it's the best format the editor support before it's dropped. Originally the editor supported only PCX and BMP and PCX was obviously a winner, especially when dealing with 8-bit graphics. Then PNG came (and also the ability to use Alpha blending sprites). It was just an unfortunate event that the editor dropped PCX support when it's moved to .NET .

I'm talking about specific AGS members how-tos.

Actually I don't understand a bit what you meant by this.

You can create optional parameters to a function (to some extend) as long as this function is:
1. declared in the Global Script or in a Script Module; and
2. is imported in the Global Script header (or the header of the Module).

So, say, you may declare something in the Global Script or in a Module like:

Code: ags

function blah(int haha, int wawa){
  ...
}

And in the corresponding header you put:

Code: ags

import function blah(int haha, int wawa=-1);

Then, if you call the function blah() in your game and ignore the parameter wawa its value would be assumed to be -1:

Code: ags

blah(10);  //haha=10, wawa=-1

...

Did you mean... like this huge list?

One problem was, as you mentioned, lack of contents in the pack.
There were only a few backgrounds and characters, limiting the setting. The few released games looked identical, which was a bit boring.
Eric and Sylpher did planned to expand the pack and at one time other people did mentioned they're interested in contributing to it but at the end it seems that people were just busy with their own stuff and things didn't happen.

This is sort of superseded by this thread but unfortunately it wasn't as successful and is not so active now.

One problem with the thread is that the free stuff aren't unified in style, and there're usually only a few pieces of art of each style, so if you want to use only pre-made materials from it you'll just end up with a game which contains randomly mixed-up graphics/sound/animation/interface/whatever and it certainly wouldn't look good.

I think a pack with a wide variety of ready-to-use materials but of matching style is a good idea, but making stuff is no easy business and it takes time. Talented artists may choose to work on the art for their own games other than spending their time creating loads of stuff for others to pick up.

(OT)
Hah. You reminded me that I drew the same background in Apple ][ a while ago.

(Based on the original version, not the VGA remake.)