Messages

There's a build that seemingly fixes the fullscreen problem for me:
https://cirrus-ci.com/task/5990403286499328

But eri0o sais that it still happening for him if he "alt+tabs fast enough".

The topic and some of the above comments reminded me of this AGS game:

https://www.adventuregamestudio.co.uk/site/games/game/1059-chatroom/

Ok, I actually reproduced the Direct3D fullscreen problem on both Windows 7 and 10. For some reason this did not occur when running from MSVS, but only when running executable itself. Often it happens on the first time.

There's a preliminary build with a fix:
https://cirrus-ci.com/task/5506153307176960

This is not documented in the manual (or perhaps I did not notice it?), but I really did not test for this when making the stream stuff...

Maybe not... Any writing operation from script, including File.Open (with eFileWrite or FileAppend) and DynamicSprite.SaveToFile, precreate all the subdirectories in the path, that is all dirs following the location token.

This should be true since 3.5.0 (judging by the Changes.txt).

It looks like the rp.Loc.SubDir.IsEmpty() is always true inside ResolveWritePathAndCreateDirs, so it returns true.

Yes, there's some logical error in the ResolveScriptPath that makes it loose information about the subpath.

It is important to find out when the error was introduced, at least test 3.5.1 once again...

ok, so the problem it seems that DynamicSprite.SaveToFile is called with a path that includes a subdirectory before the file name "$SAVEGAMEDIR$/subdir/image.bmp", and this subdir is not being created for some reason. Looking at the code I am not sure how such directory is supposed to be created, I can't seem to figure out which code tells what are these subdirectories.

It's the function ResolveWritePathAndCreateDirs; it uses ResolveScriptPath to find out which part of the path it is allowed to create and then calls Directory::CreateAllDirectories.

EDIT:
It would be nice to have the path with subfolders mentioned earlier, then I would not have to download a 1.5 gb game test...
As soon as I tested the path with subfolders, even on Windows, I immediately get a error with null pointer returning from the DynamicSprite.CreateFromFile in an old build, and a segfault within the new 3.6.0 build.

try add short empty ogg speech files to the text, the text stays on screen as long as the speech files play, if i'm not mistakening.

The players can turn the voice speech off in setup.

According to the engine code, AGS calculates text display time as "time based on TextReadingSpeed" + 1 second. This extra 1 second is always there, regardless of whether text display time is smaller or larger.
Therefore you won't be able to achieve this using Game.TextReadingSpeed.

This may be achieved using SayBackground or custom overlays perhaps (combined with manually animating speech if necessary).

Just tested on linux, the read from file seems fine, the savetofile not so much, it returns a segmentation fault. What I mean by that, is that when the game is reading the savegames doing the "CreateFromFile" for dynamic sprites it seems proper, but when it attempts to save a dynamic sprite to a file it returns a "Segmentation fault (core dumped)
" on Linux, happy to offer any further terminal logs etc. (this was tested with https://cirrus-ci.com/task/4875192413978624

Please try the latest build: https://cirrus-ci.com/build/5168338358763520

I just tested this on 64-bit Ubuntu, and it seems to work (bmp file is saved correctly and reloaded back). Although I don't remember if there have been any significant changes since the version you mention above.

I mentioned this on Discord too, in my opinion there may be a need for two demo games:
1) One that uses default AGS mechanics, based on one of the existing templates, for instance. As this may be useful for the beginners.
2) One that has everything custom, and include non-conventional mechanics and puzzles. This may be useful for advanced AGS devs, and generally illustrating that you do not have to rely on standard features.

It should be

Code: ags

player.FaceLocation(mouse.x + (Game.Camera.X), mouse.y + (Game.Camera.Y));

Hmm, so apparently AGS has a bug. It does not allow to use "goto-dialog" in the if/else block, or rather it does not allow to have any regular script commands after "goto-dialog".

This may be solved by using "return N" instead, where N is a dialog ID.

Code: ags

 else {
option-off 5
      dialogue_nairo += 1;
      return 3; // goto-dialog 3
  }

Edit: ah, actually it doesn't use our packfile at all, it uses allegro load_bitmap directly in Bitmap::LoadFromFile(const char *filename), so it's using allegro's own file method to open the file.

Erm, this is what I've mentioned twice in my posts above... it creates a default packfile with default implementations.

The lseek issue of course explains the problem, it uses wrong file offset flags instead of proper allegro flags (meaning allegro's own compilation config is broken).

In any case, I think we need to either replace with our custom packfile (in order to have full Android streams support), or with fully custom reading anyway.

when i put the goto-dialog 3 i have the following errors:

Dialog 2(84): Script commands can only be used in the area between a entry point and the closing return/stop statement
Dialog 2(85): The command 'return' will be ignored since the script for this option has already finished
Dialog 2(87): Error (line 87): PE04: parse error at 'else'

Please post the larger part of the dialog script, because it's impossible to understand what's going on judging only by the small excerpt.

But I also need to use
goto-dialog and to increment a variable "dialog_char1"

So i tried:

Code: ags

// @1
  else {
option-off 5
goto-dialog 3
dialog_char1 += 1;
  }

Unfortunately it return errors

"dialog_char1 += 1;" is a regular script command and needs to be indented.

I also suspect that "goto-dialog 3" will stop current function, so you need to increment before doing goto-dialog.

Code: ags

  else {
option-off 5
      dialog_char1 += 1;
goto-dialog 3
  }

[option-off]

How do i use these values:
option-off
and
goto-dialog
inside the else bracket ?

All the special dialog commands can be used in the middle of the regular script if you put them without indentation (no space before them).

Example:

Code: ags

@1
  if (something) {
option-off 5
  }

Overall, you may mix both kinds of script commands, so long as you keep the indentation rule (special dialog commands have no indent, regular script commands have at least 1 space indent).

[must]

In the CRM and DTA files, I search for the text. I copy the file with the searched text to the main directory of the game. This will ensure that the game loads this file in preference. I translate the search text in this file. Wiggy is right here - the translated text must be the same length as the "default" text.

Of course, if you edit the compiled files directly, then you have to keep the string lengths, as well as other data length. But this is a completely separate case, and I honestly did not expect you translating the game this way. Normally you create TRS (translation source file), either having an original one from the author, or using a tool that let you extract the text out of the AGS game. Then compile TRS to TRA using a translation compiler, and then AGS can use these TRA files if they are set in setup (or config file). If you do it that way then you don't have to bother with text lengths.

EDIT: thinking more on this, the engine does not translate certain texts automatically; in some circumstances developers are expected to use a script command explicitly (GetTranslation). If this was the case, that might explain why certain strings were not translated even if they are present in the TRA. Although I do not know all the details to say for sure.

@Crimson Wizard do you want to try the bitmap streamer road again? I think it was almost there except for some palette conversion stuff.

Oh well, I guess this could also work as an alternative. But only if it has complete necessary functionality, and there's also PCX support for older games, and a switch based on file extension (may be in a helper function).
Then all the bmp/pcx code could be removed from allegro sources, as well as all the "normal packfile" functions, since the only remaining PACKFILE users is video player and it uses our custom implementation anyway.

I still don't know if it's worth to do right now (i'd honestly rather try one of those image loading libs, like stb_image, if I remember the name correctly... but after 3.6.0 release).

I used a debugger in Linux, and you can see the first comparison to check the type from the bitmap fails, instead o 19778, bfType is 4,294,967,295 (2^32-1). Digging a bit deeper, the getc doesn't use the getc we put in the vtable, and instead it uses normal_getc from allegro's file.c. Not sure if this is happening in Windows too or why it works fine there.

Yes, it uses normal vtable, because it goes through load_bitmap -> load_bmp which creates a default allegro's PACKFILE. On Windows it goes through the same functions, but the read result is correct.

There might be a mistake in how the PACKFILE's buffer is filled earlier (normal_refill_buffer), for instance, or some file operations. Maybe the compilation uses wrong library file functions because of mismatching flags or something; but I have not searched that far yet.

On the other hand, the solution may be to instead not use load_bitmap, but load_bmp_pf and load_pcx_pf, and pass a custom PACKFILE created from ags streams (similar to PackfileFromAsset). This should also make it work from Android package.

@Crimson Wizard do you want to try the bitmap streamer road again? I think it was almost there except for some palette conversion stuff.

No; not in 3.6.0 at least, and there was also PCX format support missing in that replacement, which might be necessary for backwards support.
Overall, I'd rather wish we used some image library that does multiple format reading and writing to save on code maintenance, and only make our own format reading as a last resort.