Messages

Understood. I can test it after fix if you need me.

Check this image. The blue line on the roof is mouse position and the other lines below are actual drawn lines. There is a huge gap between them.

https://ibb.co/ct02YL

I've just tried it with patch 6 and the result is the same. There is a huge offset between clicking point and drawing point. Offset amount is like a half of the screen. Drawing tools are broken for walkable areas and regions and hotspots. Walk behinds work properly.

Test resolution : 1920*1080
Room resolution : 1920*1080
Tried with zoom : 100%
Broken modes : Walkable areas, regions. hotspots (ID 1,2,3)
Working modes : Walk behinds

Crimson, I've been tampering 3.5.0 alpha 5 and I have a problem. How do we draw any line or fill the area in the room editor? Nothing seems to work.  I can draw a filled rectangle but it renders the rectangle too away from my click point.

90k imported sprites and more than 2 GB files? Wow! That was my dream and I knew it that one day my dream would become reality. If I make a new game, I will definitely import more than 30k sprites. Thanks a lot, Crimson.

To clarify, does this happen all time/often to you, or only happened few times? Have you tried running with Direct3D?

* OpenGL is new and may have some unknown bugs.

Yes, this may be too.

I encountered it two times of over 30 hours testing. They both happened when the room was loaded and if you don't quit the game, it continues. I haven't tried Direct3D yet. I will try it with Direct3D.

Update: I've realized it now. Direct3D is faster than OpenGL. With OpenGL, FPS frequently drops when a GUI is visible, characters move, etc.

My guts tell me that you made a mistake and uploaded a version of the game that has a bug (in your script), or that the bug was there all the time but you never noticed it before.
Alternatively, it might be because the version hosted on steam has its settings set to 32-bits and you were testing your game in 16-bits or something like that (different graphic settings between your test environment and the package hosted on steam). It would be worth running winsetup.exe and compare the settings. Also, are you running the games on the same computer?

I'm 99% sure Steam has nothing to do with it.

You may be right. Maybe the bug was there all the time but I didn't encounter it. It also happened outside of Steam so I updated the title. I have some ideas :
* The room size is too big and the engine sometimes can't handle it to load properly.
* Possible hard disk failure?
* OpenGL is new and may have some unknown bugs.

It couldn't be that because I didn't change the name or anything but I have a solution. I will create a new walk-behind base that covers the whole remaining area and set the baseline to -1, so that no empty space will be drawn white.

I had a strange bug today. I tested my game on my local disk and everything was fine. Then I uploaded it to Steam and downloaded it again and tested it. At a point in the game, the room faded out (intentionally) and after fade in, the room background was completely white. Interestingly, walk-behind areas were shown normally which are the part of the background image. I've never had a strange error like this before. Is it related to the Steam API or something? By the way, I'm using the AGSSteam plugin and everything is normal about it. I mean achievements pop.

AGS version: 3.4.1.12
Game resolution: 1920*1080
Room resolution: 4320*3150
Renderer: OpenGL
V-Sync: On
Sprite cache: 512 MB

Update : Steam has nothing to do with it.

I meant 72 GUIs with functions but never mind, I get it now. I remember the last working of my game was just before 128 module scripts. I guess I have to combine my present and future scripts to avoid them exceeding 128 in total. Thanks CW.

I have 133 module scripts + 1 global script + 72 GUI. 12 module scripts in repeatedly_execute function.

Everything is included in 256? Gui functions, module functions, room functions ?

This happens when the game starts.

I get this error message after creating more than 100 module scripts but I'm not sure it's related to that :

https://ibb.co/hcU0OT

Anyone knows this error?

Great job CW as always. Is there a limit of number of module scripts you can create ? Sorry if it was removed before. I couldn't follow it on the previous versions.

* When you manually run Game Setup and change some settings, you cannot override them from "Default Setup" pane.

When engine runs the game it first reads default config, then reads user config if its exists, and replaces any matching options with values found in user config.
You can "override" this by deleting a user config located in %USERPROFILE%/Saved Games/Name of your game/.

Maybe it may help if there were an option to delete user config for the game from the Editor?.. Idk if that's a good idea.

Actually it's not a problem for users who are familiar with AGS but beginners may be confused. It may be resolved by removing "Run game setup" from build menu ? So users understand that the only way to reach settings is "Default Setup" pane. Just an idea.

Hi CW, I'm using this version (3.4.1) currently and I have few things to report - feedback :

* When you manually run Game Setup and change some settings, you cannot override them from "Default Setup" pane.
* Mouse movement seems better in OpenGL mode in full-screen game mode.
* The engine still doesn't compile more than 2 GB sprite file (previously known issue).
* Performance of the engine, scripting, compiling, view pane are visibly faster and more reliable than 3.4.0.

I last tried it with AGS 3.4.0.

Could you specify which 3.4.0 exactly (what is the fourth version number)? The mouse fix I was referring to was added somewhere in the midst of 3.4.0 development.

Just in case I opened ticket for this issue: http://www.adventuregamestudio.co.uk/forums/index.php?issue=849.0

Although, first of all set of conditions has to be established. For example, you are saying that you use 32-bit color gfx - and I assume - high resolutions? - in your game. Do other people who play your game experience same problem? Or, on contrary, do you have same issue when you run low-res games made by other people?

I tried other AGS games and I realized that cursor movement is better at 60 FPS. I also changed my speed to 60 and cursor is better now. AGS 3.4.0.13. eri0o was right. Thanks.

It isn't a speed issue. The issue is the mouse cursor is laggy all the time regardless what FPS the game has (windowed or full screen). It looks like the mouse cursor is fixed to 15-20 FPS. I even tried incredible game speeds like 250 FPS. The game was fluent but the mouse cursor was still the same. I last tried it with AGS 3.4.0. I always use 32-bit colors and alpha blending in my games, so I actually don't know what the result is in old school games like 256 colors palette and very low resolutions. May be most of the developers here use old school techniques so they may not have an issue like this and they don't see any problem to report.

I also tried UpdateCursor() function and it didn't help.

What is it about smooth cursor movement?

It's like mouse cursor (in a game) doesn't move properly like Windows cursor. It's slower and laggy. This exists since v. 2.72.

Nice release I hope we will see smooth cursor movement soon