Messages

Edit: I've tried to replicate this with a new/empty test project with the same kind of code, and I cannot replicate it. Would you mind if I zipped up my project folder and sent it to you via PM? I can point out how to reproduce it using my project.

Yes sure.

Ah... that is the problem. Somehow this did not click for me either.

But then this note must be added in the manual.

Are you absolutely certain that view 7 is the right one? I may recommend using view names everywhere instead of numbers, similar to how you did with cPersonajeKid.ChangeView function call; that is :

Code: ags

cPersonajeKid.BlinkView = VWHATEVERNAMEIS;

Radiant had decided to "officially" release his FontEdit's sources under LGPL3 license, so now I can post an experimental version source, which allows to create WFN (bitmap) fonts with up to 64k characters, making it usable for Unicode games too:
https://github.com/ivan-mogilko/fontedit

Executable:
https://www.dropbox.com/s/xth28bfzu78vtqi/FontEditUni.zip?dl=0

The version may has some minor functionalities disabled during this update, and I did not have time to go back and fix everything. But if anyone would like to take this on, the sources are available, and also I may accept PRs.

Although, I believe someone should rewrite this on a modern UI framework, to make this program work on other platforms too.

NOTE: There's a Rulaman's FontEditor, also available as the Editor's plugin, but unfortunately I found its source code more complicated to edit and upgrade to 64k chars limit for some reasons.

I just tested out various non-existent variable names like "[udfcjviw]" and "[xujiosygj]" as array indices, and they all compile, yet cause a crash when those lines are executed in the case statement. I assume this means that the compiler does not check whether array indices are valid variables when in switch/case statements?

Hmm, this sounds like a compiler error, as engine merely follows compiler's instructions there, getting into unexpected behavior.

But how do I reproduce this exactly? Trying random array access, compiler does not let this through:

Code: ags

int a[1000];
a[xxx] = 5; // GlobalScript.asc(7): Error (line 7): undefined symbol 'xxx'

It's a first person game with only about 40% of the screen used for what I'd think of as the "room" in a regular 3rd person p&c with the rest being UI. The other 60% of those 5 images is mostly empty white space, with some "noise" behind where the UIs sit to give them some life. I knew this was inefficient when I started but I couldn't see how how to get a room background image to be anything other than stretched across the whole screen, and equally wasn't sure how to animate UI elements, so I padded all the backgrounds.

Padding also counts when loading or drawing images, as pixels are data regardless of whether they represent anything in the game.

This belongs to the tech help forum section, but from a quick glance this may be resolved by either:
1) having a smaller object or overlay on background, and animating that;
2) configuring room's viewport and camera so that the room is displayed exactly the size you want. This will also allow to have rooms of smaller size than the game itself. (See Viewport and Camera sections in the script API in the manual)

As a practical solution, am I understanding correctly that re-doing the graphics at a lower resolution will help, at the very least with the load times? I'd really like to keep the 5 frames of bg animation for each room, though I'm sure thats a bit part of the games bloat as I'm not working in a particularly element way.

What are these 5 frames of room animations doing? Usually I suggest to see if these may be broken into separate smaller objects.

The code seems right, are you sure you don't set BlinkView elsewhere that might override this setting?

instead if you walk on a walkable area now what happens is if you stop at the "wrong places" it can freeze on random walking cycle frame instead, a bit odd. It happens using the gamepad or keyboard modules.

Can you elaborate on this?, I need to look into this as this in case this is a engine mistake.

C and C# mostly.
The basics of functional programming are from C, and the script commands were done in C-style in the old days.
The managed structs, managed pointers, attributes are resembling C#.

Learning other languages might also help, because many concepts are shared between languages even if their syntaxes differ. Besides learning a language on its own, it's also important to learn writing algorithms and structuring the code.

So what you mean is if the player plays in say a windowed mode if they'll save the game it might end up looking...Strange?

No, screenshots in savegame will always will be same. It's the objects that will look different depending on the display mode.

There's currently only one way existing when the object may display in a higher resolution: that is when the "Render sprites in screen resolution" is set in the game setup. This will make scaled object appear to have more resolution, that is - less pixelated.

I don't really know if you were referring to this or not. But this trick is theoretically doable. The problem with this is that the result will depend on the size of the game window that player chooses. Also this currently won't work with "Software" renderer, only "Direct3D" and "OpenGL".

What about this. Having the GUI's code go out to something else in the room instead (Think Room equals the main screen "New Game, Load, Quit, etc". Forexample as a clickable object and have the object act as a "psuedo gui". I'm trying to think of ways to make the same effect as a 1920 x 1200 resolution game setting momentarely. Clearly i could make such a start screen, so wouldn't that be an alternative instead of upscaling everything in the actual game?

I'm sorry, but I cannot understand what do you mean by that, and how this will make the screenshots have better resolution.

If you can type "Game.Camera.SetAt(640x480)" obviously the bakground and everything in the room is now a different resolution from the original Game Setttings (320x200).

No, this is all wrong...
Firstly it's SetSize, not SetAt, but that's a typo. More importantly, this command does not change background's resolution, it scales the room's image, but resolution stays always the same. Resolution means "how many pixels you may have on screen at the same time".

Scaling camera means that room's pixels are duplicated or cut down. For instance, scaling x2 would mean that instead of 1 room pixel there will be 4 (2x2). But the total amount of pixels on the game screen will be the same (320x200)!

The screenshot uses game's resolution. It does not matter how much room is scaled, the game's resolution will be same, and therefore the screenshot will have always same resolution.

Since you can change the resolution now in AGS i do it quite a lot in my game so far actually

What do you mean, how do you "change the resolution in AGS"?

Like i mentioned in another thread, the screenshot is always in the game's resolution, the question is how this screenshot is resized when drawn on gui.

Looking in the template, it resizes the screenshots to the size of the buttons on the Load/Save menu. So the only existing solution is to:
a) resize the buttons, make them larger;
b) adjust script or gui sprites if necessary
I did not find out how it decides which size to use, so I hoped that somebody more familiar with the template could help with this.

Above is the only thing that you may achieve with the template's script. Anything else would require changes in the engine.

By the way, the exploration & learning example from "Monkey Island" that @Danvzare mentioned under the "spoiler", is also, in my opinion, a hint to what was the adventure genre's main problem and a weak spot historically, that is: a lack of a system.

I vaguely remember mentioning this years ago in some other topic, I recall I had this analogy: in a good action game you learn your character's abilities while fighting with weaker enemies first, and then you have to use combined experience when fighting stronger ones. That's the "system". Unfortunately, in a good number of the adventure games i've seen in many years there was no "system", instead there's "randomness". It's too often went down to plain guessing what might have worked, or even what could be in authors heads when they wrote the script.

IMO this is what may make a difference between a bad and good adventure game: letting player learn and figure out something based on learnt. The more complex solution may be figured out by a player this way, the greater will be the enjoyment effect.

There's a serious mistake since Beta 9 (one before the current one) which cause portrait animations to not update. Unfortunately it was reported only now.

I will have to release another update as soon as this is fixed; or re-release Beta 10.

EDIT: done, sorry, please download again.

[Editor:]

Updated to Beta 10
(Please use download links in the first post)

Changes in this update:

Editor:
- "Goto Definition" command in script will now work for most of the game entities too, such as Characters, GUIs, and so forth. In that case it will find a game's entity and open a respective editor panel for it. This still does not work for some types, such as Room objects, and Views.
- Added main menu commands for opening a Project folder and Compiled folder.
- For script's tabs added a context menu command for opening this script's location.
- Added "Scale Character sprite offsets" property to General Settings. This property refers to scaling of Character.z and sprite offsets added by LockViewOffset script command.
- Config will now be saved in UTF-8, letting to support setup program's title text in unicode.
- Fixed GUI editor could display selection rectangle from a different GUI editor pane, if two or more are displayed on screen at the same time.
- Fixed Editor could miss some of the files when cleaning up old compiled files after the Game's Filename property is changed.

Engine:
- Characters will now have their graphic offsets, set by Character.z property and LockViewOffset() function, scaled along with the character's own scaling. This is done so long as the respective game option is enabled in the General Settings.
- Allow to change Character's move speed while its moving.
- When Character is ordered a new move command while already moving, the engine will try to make a smooth transition between old and new moving without a delay.
- Engine will now skip blocking Character.Say commands instantly while skipping a cutscene.
- Deprecated in-game "console", as practically useless.
- Fixed buttons on a non-clickable GUI were still changing to "mouse over" graphic under cursor.
- Fixed Characters may be seemingly "walking in place" for some time when arriving at destination.
- Fixed "Before fade-in" event could be called recursively under some peculiar conditions (this is a regression since 3.6.0).
- Fixed button click not registered if it has been made not visible and visible again during a single game frame (this is a regression since 3.6.0).

Compatibility:
- Fixed a "New Room" command in old-style dialog scripts was preventing "First time Enter room" event to be called.

I was too lazy, but finally opened a ticket with this task:
https://github.com/adventuregamestudio/ags/issues/2155

From technical side, the CRM format consists of "chunks", each with its own metadata (ID, size), which allows to add anything inside.

Whether it's convenient to store things like "thumbnails" inside CRM itself is an open question.
As engine today does not have a mechanic of "preloading" anything from a room file, therefore it's more convenient to have "preview" data as separate assets, either custom asset files or sprites.

The room template (*.art) is a standard ags package (CLIB type), so it already may include additional files, similar to game templates.
BTW this reminds me that in ags4 the room templates should contain Room folders instead.

Personally, I think that it's more beneficial to move towards having 1 package layer (clib format, or else) with assets as files inside, and support subfolders which let group related assets together (for example: room data as file 1, room script as file 2, and any additional data as their own files).