Messages

Thanks for the info, SSH. I'm stumped as to why a reasonable response like yours wasn't posted in the first place.

Paul.

Then again, ever since I got this flat screen... every thing's gotten screwy...

Well I've been running AGS on a 1280x1024 for a few months now, my 30" is being used for other projects right now but I have had these graphical artifacts since version 2.8. While particular forum members are just itching to ostentatiously twist my words because they view my equipment and setup as rare, the reality is that it doesn't matter what resolution I run AGS in as it still presents visual problems.

I'm not after a prettier GUI in any way, I'm after a fully functional GUI and if anyone would care to look at the screen shot I took the time to put together they will notice that amongst other less important problems there are two major bugs that obstruct my work flow in a number of ways. While SSH would prefer to spend his time putting me into a turgid category, I imagine Chris would more likely spend his time fixing bugs that incur a less-than-desirable workflow.

This might surprise you SSH, but AGS is actually a tool for everyone, not everyone -1.
If you want to take this further, I'd be glad to discuss the dangers and history of categorizing people in groups labeled 'other' or 'foreign' over a PM or two as your apparent lack of social intelligence and decency has no place on the forum.

I shouldn't have to explain myself again.

What kind of justification is that? 
Please don't twist my words, SSH. What I am asking for is perfectly reasonable.

Paul.

Using the editor with a desktop resolution absurbly high is just an overkill

I'm sorry but thats a ridiculous statement and one that is unacceptable.
I work IN the games industry with licensed engines such as Unreal 3 and CryEngine 2 and they run fine at the
standard
my 30" display and DX10 GPU is set on. Hell, even MS Paint works in a resolution independent environment. AGS should be no different as to require 'some' users, to change their desktop resolution and dpi configuration every time the editor is launched. I'm sorry but this is more than a backwards approach and a hindrance to users who are equipped with technology to develop for next-gen games and other high-end applications. Why can't people accept that AGS is not just a tool for hobbyists. I mean I hate to burst your bubble like this but not everybody works in Uncle Sam's Retail and runs a VGA card.
Ask yourself, Gilbot, would you alter your resolution every time you launch your email software. Or perhaps you would like to switch to 800x600 and change your mouse speed, and your color depth oh and I don't know disable your firewall. Do you see where this is going?
I know you mean well and I don't at all mean to be offensive but sweeping statements like that really boil my blood, man. 

Paul.

[Edit:]

suggestion:
A nice feature would be to change the game language in-game. Maybe Game.Translation=String TranslationName;.
We would not need to use to the WinSetup.exe and it would look more professional to change the language from english to spain in the options menu of a game.

In the editor: Right click on a translation: Edit in default text editor. Or possibility to edit it in the editor itself.

What would also be nice: Game.Windowed=true/false; Game.GraphicsFilter=2xNN,3xNN,Hq2x,Hq3x; Game.ForceLetterboxRes=true/false;
These are things that are implemented in ScummVM and would be nice to have in AGS.

This is basically a small part of what I have already sugested, Smash. It has already been suggested by me that the options winsetup offers also be controlled via a scriptable GUI so that they can be changed in-game.

Edit:

The compiler should barf if someone declares a variable or function in a script header as this is almost never what someone actually wants.

'Almost' isn't a very reliable statistic if functionality of the compiler is to be altered now is it. 

Cheers,
Paul.

Tits   

Milk Jugs

I love this game.

I don't think that the amount of time it would take to fix them all would be worth the hassle, though I will take a look at it.

Thanks mate. I very much appreciate it. Although Vista supports any dpi font, 96 and 120 dpi are standards set in XP and support for both would be ideal. People with larger screens and greater resolution tend to use 120 dpi as fonts are remarkably clearer and easier to read.

If it makes any difference, I tried AGS twice on a 96dpi setting and, again, the same issue presents itself. I think it's because AGS doesn't realize the dpi settings have been changed back to 96. The menu bar font is 96 dpi but the contents inside of the editor remain in their 120 dpi appearance.

To be frank and slightly off topic, I honestly don't know how anybody puts up with 96 dpi. I run a resolution of 1280x1024 on my smaller LCD here and its just as minute and unbearable as it is on my 30" Apple Cinema Display running 2560x1600. I challenge any of you to try 120 dpi for a week and see if they can go back. It seems like 96dpi is that magical number thats big enough for the world not to notice and kick a fuss but just that little bit too small for those who have already tried it's larger counterpart. "I really do hate you and your tormenting mind games, Microsoft!"

Cheers,
Paul.

Damn can we get this fixed?
Why the downtime anyway? Did anybody explain why the original servers needed a holiday?

Paul.

Releasing two versions of the game both with a winsetup executable that allow you to choose which aspect ratio to use for the game is a great temporary solution. I imagine this would indeed be a reasonable prerequisite for future control over screen layout for a single release.

Thumbs up.

Cheers,
Paul.

Ahh! Sorry you posted before I could reply. It's a grand idea GarageGothic and one I choose to support you on.
I'm sure Chris can see the importance of this feature and I imagine it will eventually come to be.
I was getting worried when this topic ended up on the second page of the technical forum :o so I had to revive it. I'm sure glad we both feel it is important and must be addressed at some point in the near future.

Many cheers,
Paul.

[Edit:]

We've spoken about this before actually. I'll admit my entire suggestion is spread over two threads but its basically outlined above. Most of what I suggested lies in the suggestions thread rather than this one but I'll quote myself for clarification's sake:

By allowing us to customize those to either resolution, we could make the best of both aspect ratios.

GarageGothic is right and as I have suggested a few times already I think we need to be able to control 'screen layout' in the editor along with the other features found in the default game setup exe.
Paul.

On quite a few occasions already, I have reinforced this idea with suggestions on how to go about such a feature. My point is, this idea would be an important part of a greater feature set in an effort to overhaul the resolution system.

Ironically, as much as we both crave resolution independant development, I imagine the easier task on Chris' part would be to code in support for automatic resolution detection.
So again, I agree with you; First things first. 

Cheers,
Paul.

Edit: We are chasing the same animal GarageGothic .
http://www.adventuregamestudio.co.uk/yabb/index.php?topic=33896.msg440632#msg440632
We're both suggesting the same thing in other words, however, I have thought ahead a bit and added a bit more to the idea regarding resolution detection and a GUI based setup screen.
I strongly reccomend these three things should be given equal attention and should be worked on in conjunction with one another. They are essentially directly related features.

Thats all great, but wouldn't my extensive idea I suggested naturally solve those problems for you anyway? If we can kill two birds with one stone, yadayadayada.

As CJ commented, I really do think the resolution system needs an overhaul.

Cheers,
Paul.

Chinese, but I wouldn't care about these minor glitches unless they prevent me to use some of the features.

Well the reason I posted this is because it actually disrupts my work-flow. If you look at my image properly you'll notice that the view/animation previews are barely visible and the radial buttons that are supposed to be on the right hand side of the dialog system are not visible. While I would LOVE to see all these ugly interface glitches cleared up someday, I believe that now is the time to correct the ones that disrupt our development pipeline.

Cheers,
Paul.

Is that right! :o Gee I hope we get this artifact stuff fixed sooner rather than later.
What language do you use, Gilbot?

Cheers,
Paul.

Hey Chris. Listen I know you've already got a lot on your plate but I still have these strange visual artifacts introduced back in the very first version of AGS 2.8. I've put up with it up until now but I feel that my work is being hindered by these visual glitches of the interface. You mentioned once that it was due to using larger DPI fonts. I replied to you back then after testing AGS on a system without 120Dpi fonts enabled and the problems still persisted. I am left wondering if there is anything else that might be causing AGS to appear like the following:

http://www.shuugouteki.net/paul/Development/visual_artifacts.gif

A million cheers mate,
Paul.

Is anyone still interested in or excited about what has been suggested above? I sure as hell am. This topic already seems to be plummeting into the abyss of forgotten threads. :'(

Cheers,
Paul.

Hmm, I'd forgotten that limit was there. Seems like you're the first person to need that many scripts Wink
I'll take a look at it.

Thanks Chris. I tend to modularize my scripts too. Neat is good .

Cheers,
Paul.

Wow! Theres a limit on modules? Explain why to the dumb artist? 

Paul.

Also, I find that sliders would be a bit of an overkill

Why? Sliders are simply another way of displaying the measure of a value. It is notably a more user friendly method as well. Sliders don't have to be adjustable by the pixel. It can be adjusted in chunks of 5% and a label displaying the value below or above the slider would be present. Who in the world needs 42.7% compression for example?

but if you want to use it as a 'target' file size for the whole project

Not the whole 'project', but rather the entire sprite image index.
Let me clarify it's purpose:
A user might want to tweak each sprite's compression separately or might find that simply tweaking the overall compression for every sprite at once is more preferable. It depends on how much time the author wants to spend sifting through hundreds of sprites tweaking individual values. Another reason why a slider would be more appropriate than a text field in which the user is likely required to click on, in order to type in it, and then press enter to lock that value in. I've learned a valuable habit of thinking several steps ahead, particularly with engine design, which is why I chose to suggest it above

Paul.

I think lossy compression is a debatable issue. Here is what I imagine being an optimal approach:

• Sprites are built by Artists and are saved out in an uncompressed or lossless format
  
• Sprites are imported into AGS unchanged
  
• Users control a compression slider for each sprite with an overall sprite index file size measure
  
• Users control an overall compression slider in order to tweak overall project size estimates
  
  I don't know how reasonable AGS would be with decent compression algorithms but I imagine this sort of thing is pretty standard across the board.
  
  Cheers,
  Paul.