Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - Crimson Wizard

Pages: [1] 2 3 ... 429
I think in the end it may be worth to not rely on engine's defaults and have a set of utility functions that init objects of different kinds. For example in the racing game I've referenced above I had function that setup a racing car object and it sets pivot to (0.5, 0.5), because it lets you to trivially apply rotation around sprite center.
This makes sense for a racing game, but I wouldn't want the average user to have to create utility functions for a point&click game. The engine should be geared with defaults that apply to the most common use-cases for point&click (or in the future, like we discussed, we might have templates with different defaults, geared to that specific template use case).

You may find different use cases for the Origin (I will use this term, which is equivalent to Pivot at the moment) within same game or even within same room. For example:
Origin with Y = 0 will be convenient when setting up objects that need to be on "floor", because you want to align their feet/bottom to particular place there.
Origin in center (0.5, 0.5) is convenient for top-down views, but may be also useful if you are making small flying objects like projectiles, visual effects etc.
Origin with Y = 1 might be useful if you align things in top to bottom order on screen programmatically (e.g. GUIs). And also if you have something walking on the ceiling, I guess :).
I think in general that whenever you are aligning objects programmatically alot in your game you may want to make sure they have convenient origins for that.

Otherwise you'd had to do extra maths in all non-default situations. AGS does not have custom origin, so I had to do additional calculations to position car "characters" in my racing game, converting from physics coordinates into AGS character coordinates. In MonoAGS I simply set the pivot.

I think in the end it may be worth to not rely on engine's defaults and have a set of utility functions that init objects of different kinds. For example in the racing game I've referenced above I had function that setup a racing car object and it sets pivot to (0.5, 0.5), because it lets you to trivially apply rotation around sprite center.

This reminds me, when I last saw (several months ago) both alignment and rotation was performed around pivot, and there was a suggestion to split properties into one determining position alignment and another for object's own transform operations:

Also, the Y axis pointing up makes it inconvenient to work with GUI, since you have to position, for example, menu items vertically in opposite direction (first item having largest Y). I wrote a class for the game menu that does calculations internally to simplify things for myself:

I think I was asking if it's possible to implement a surface with custom axis direction, but don't remember what was tzach's decision on that.

I'm just having trouble positioning the object. Using the original coordinates from the AGS game does not work. How is the position determined? Is there a proper way to calculate from AGS to MonoAGS coords?

Y axis is turned other way, pointing up :)
Also, in MonoAGS object's image related to Position is determined by Pivot (or was it Anchor? I may not remember correct property's name).
So, if your AGS object was located at X,Y your MonoAGS object should be located at X, Y = AgsRoomHeight - agsY, plus some extra offset depending on pivot/anchor.

I made this function to port AGS scripts:

Advanced Technical Forum / Re: Crash on restoring game
« on: 22 Sep 2018, 20:18 »
Thanks. The odd thing is that restoring a saved game normally works fine, but in one particular instance it crashes. I suspect there is something unusual about one particular room, and games saved in that room cannot be restored. I'll see if I can get more details from the player.

Is it possible to get that savegame? If you also tell which game this is I could test this under debugger.
Unfortunately it does not look like I have necessary PDBs to read that crash dump. Things got messy during 3.3.0 development and there were multiple updates and hotfixes which were not archived anywhere. Only final 3.3.0 version is still available on ags fileserver:

UPD: Oh, actually found some old 3.3.0 archives in server backup folder, going to check that one.
But I still need to have the game exe to be able to use crash dump.

UPD2: Did not realize at first, but the crash dump dl link in the first post is dead.

Advanced Technical Forum / Re: Crash on restoring game
« on: 22 Sep 2018, 20:04 »
Hmm, somehow I missed this earlier.

0xC0000094 is the "division by zero".

Tag +2051 does not exist in newest code anymore... I'll have to get old engine code first.
UPD: Ok, this is loading a save.
I don't remember if we have old PDB files for this version anymore, brb.

I think this can probably be raised as a bug (unintended behaviour), if clicking on an inventory item does nothing and clicking on buttons does something.

Popup GUIs are supposed to be hidden after click regardless of what the click was on.

But my impression was that by "nothing happens" Babar meant that inventory item is not selected, not that literally nothing changes.

My guess is that built-in inventory click handling was hard coded to work with the standard Sierra interface.

I made a test, and it works for any InventoryWindow control too. The built-in rules are:
1) Item gets selected into cursor if you left click with "Interact" mode only.
2) Right mouse click always triggers "Look at" interaction.
3) If nothing from above, then current interaction mode runs.

@Babar, you have to choose whether you want to script inventory interaction yourself or use built-in one. Don't forget to set "Override built-in inventory click handling" in General Settings correspondingly.
If you are going with custom script, the script you posted above has nothing related to inventory handling at the moment. Room.ProcessClick only works on room and its contents (objects & characters). There is a GUI.ProcessClick counterpart (but not necessarily useful in your case). Important thing is, as Khris said, to catch clicks on inventory items you need to check (button == eMouseLeftInv). You may get the last clicked item either with "InventoryItem.GetAtScreenXY" or "inventory[game.inv_activated]".
I think BASS template may have an example of custom inventory script.

General Discussion / Re: Winzip or 7Zip
« on: 21 Sep 2018, 13:52 »
How universal is 7Zip regarding people being able to open and extract a game?

7Zip is a program, but this program may create both zip and 7z archives. You can use 7Zip to make zips too and everyone will be able to open them.

If I understand what you want correctly, can't you just add 50 black pixels at the bottom of your background image?

I think OP's problem is that he or she has a scrolling room, and since by default AGS centers view on character having whole screen in mind, character may be seen too close to GUI in the lower half, while author wants to see character centered inside the remaining upper half of the screen.

If it's what I think, by coincidence I am working to add this feature into engine right now, but it will take a while.
Meanwhile the only way is to write custom camera code. Use SetViewport() in repeatedly_execute_always() and point to your player character. Then you will be able to apply any kind of adjustments and constraints.
Have something like this in GlobalScript.asc, or any custom module:
Code: Adventure Game Studio
  1. #define CUSTOM_VIEWPORT_WIDTH 320 // game's width
  2. #define CUSTOM_VIEWPORT_HEIGHT 150 // game's height minus GUI height
  4. // Notice I am using late_repeatedly_execute_always, it is run after game updates itself (contrary to just repeatedly_execute_always which is run before game update), and this way you will be getting most up-to-date player's location.
  5. function late_repeatedly_execute_always()
  6. {
  7.    // First get the point camera should be targetting
  8.    int x = player.x;
  9.    int y = player.y;
  10.    // NOTE: add some offset to x and y to take character's size in account, because x,y point to character's feet
  12.    // Now center the player in the custom viewport
  13.    x -= CUSTOM_VIEWPORT_WIDTH / 2;
  14.    y -= CUSTOM_VIEWPORT_HEIGHT / 2;
  15.    // Make sure coordinates don't go below 0 (don't remember how AGS reacts to that)
  16.    if (x < 0) x = 0;
  17.    if (y < 0) y = 0;
  19.    SetViewport(x, y);
  20. }

EDIT: but indeed you still will have to have 50 px dummy border in the room if you want character to walk all the way down the active background.

Engine Development / Re: AGS engine Linux port
« on: 20 Sep 2018, 10:32 »
Anyway, this inspired me to try and get AGS' OpenGL renderer working on Linux. I don't have previous OpenGL experience but was able to crib from enough tutorials to get it working in windowed mode.

Code is at , see the commit message at for more detail.

I've only tested it with one game (Lamplight City) on one system (Ubuntu 18.04, Intel graphics) so far. Fullscreen mode isn't working yet. Somewhere in AGS the system tries to resolve the game's 640x400 against my PC's 1920x1080 and comes up with 1728x1080 (game res * 2.7). I fail to set this as a fullscreen mode and AGS falls back to windowed mode. I guess the driver is supposed to realize the system won't do 1728x1080 and ask the windowing system for 1920x1080? Does anyone know?

Hello, toojays. It's really nice to see someone tried doing this. I kept hoping to look into this myself but never found a moment to research the OpenGL working on Linux (also, there was ongoing Nick Sonneveld's SDL port attempt, but it seems to get delayed again).

Can't answer to the fullscreen problem right away, this is something to investigate. I may mention one thing though (and also the main reason that was stopping me). Since OpenGL does not support "dedicated fullscreen mode" on Windows I had to emulate fullscreen mode (probably this is how everyone do this) by switching desktop resolution. This is not done in ali3dogl.cpp itself, but in the "platform driver" class. You may find calls to "platform->EnterFullscreenMode", "platform->AdjustWindowStyleForFullscreen" and "platform->ExitFullscreenMode" in OpenGL renderer. The implementation for Windows is located in acplwin.cpp. But I honestly do not know if we should follow same procedure for Linux or not (also don't know X11 very well, I wrote literally couple of functions using it before).

Am I right that you are using "glew" library, that helps to bind function pointers to dynamically loaded OpenGL object? OpenGL renderer was originally written in such a way that on Windows we manually getting function addresses, and that would be actually a nice thing to get glew used on Windows eventually too (not sure why I never tried, maybe was worried to break something that was already working).

I have a proposal, since this forum thread is too long already and contains all kinds of various discussions, could we continue on github instead, by opening an issue ticket in our repository? I believe that would be more convenient especially since you already have account and some code in progress there.

Modules & Plugins / Re: MODULE: Hint Highlighting
« on: 20 Sep 2018, 10:13 »
EDIT : Was- Was the github address at the top of the first post the whole time? :X


AGS 3.5.0 - Alpha 5

Zip archive:

Has all content from AGS (Patch 4).

Common features
 - Raised imported sprites count limit to 90000* and removed total sprite count limit (this means you may have around 2 billions of dynamic sprites).

 - (needs more testing) Fixed that existing Editor plugins could not load up with the new Editor.
 - Don't display missing games in the "recent games" list.
 - Fixed crash when deleting a room object.
 - Fixed audio.vox and speech.vox not building correctly.

KNOWN ISSUES: Editor crashes on exit. This may be same bug eri0o reported a short while ago. The crash takes place only after game is saved and window closing and seem to not make it loose any changes.

(*) Technically engine now can handle up to 2 billion of sprites, but there is certain problem that makes non-trivial to allow user to set very large custom index to sprite (for example, have sprites number 1,2,3,4 and then 1000000). For the time being I found compromise in increasing the limit of imported sprites to some reasonable number (still 3 times higher than before). FYI the details of this problem are explained here:
The total number of sprites (imported + dynamic sprites) are now limited only by number stored in 32-bit signed integer (over 2 billion).

Modules & Plugins / Re: EDITOR PLUGIN: WFN-FontEditor
« on: 19 Sep 2018, 18:06 »
I tried using this plugin with the recent editor, and there are two problems:
1) I have no idea how to save the work, or when it is saved (when I save the whole game? close the font editor tab?  whenever when I put a pixel in a letter?)
2) I noticed that AGS does not have the font preview updated after font is edited, only closing and reopening whole game fixes this. Was it always like that? Might be a problem of communication between AGS and the plugin.

Also, Rulaman, if you are still around and have time, could you put the source code on a more suitable hosting, like github or bitbucket? The above link on "filedropper" is dead.

Assuming it's sprite number (470) that it's reporting my guess is that could be Direct3D and OpenGL failing to create textures for some reason.

First of all, to make this clear: you are running exactly same game in Windows 7 and Windows 10 and on Win7 it crashes like that?
What graphics renderer you choose in setup, and have you tried using different ones?
Have you tried running the game outside of editor?

Something that may hint a reason of a problem:
"program pointer is -3" means the game is loading the first room.
"gtags (470,200)" depending on circumstances can mean either GUI (if you have GUI with id = 470), but also initializing a sprite (in which case it is sprite #470 which is 200 pixels in width) (AGS error reporting is a bit mysterious).

Oh, I think I am beginning to understand.

One more question: is it possible to make this change as a hotfix now? If it actually lets to use plugins again not likely it may make things worse than they are. I'd like to release an update to ags 3.5.0 soon and it would be wonderful if this issue is also solved even if with some temporary code.

A small note, the latest Alpha 4 made in August has number of mistakes that may prevent building game correctly under certain circumstances: noteably building speech.vox or audio.vox (I was actually surprised no one reported these, but guess not much people actually test this version yet).
I was going to upload an update that fixes them, but decided to wait a few days more to see if the above issue with editor plugins will resolve.

I am afraid I don't fully understand the above, do we have to add this "resolve" part to the Editor code, or is it the plugin that has to have this?

Am I correct guessing that this will substitute the unsigned AGS.Types demanded by plugin with signed one?

Maybe it is best to open an issue on GitHub, since future changes to the plug-in system are probably determined by the choice made here.
Could you also elaborate a little on this, what changes to plugin system will be determined by this (or how)? Just want to be sure that I understand the situation well.

This is indeed the default behavior for "Y popup" GUI style, emulating Sierra games, because the only purpose of iconbar is to choose 1 icon by clicking on it and then make next click on the room.

But also, if you do a GetProperty() call for a non-existent property name, I don't think it will crash, just return a 0 or null (for text properties).

It will display error "there is no such property", and I actually think that's not a bad thing in current situation, since there is no other way to tell if it exists. At least user will be warned early instead of wondering why script does not work correctly.

Pages: [1] 2 3 ... 429