yvsarkisyan / keeperfx

Automatically exported from code.google.com/p/keeperfx
0 stars 0 forks source link

Added new test parameter #580

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
added new commandline parameters for purpose of test:

-desktopres: always use current desktop resolution and scale game graphic to 
fill the screen, instead of changing actual resolution of monitor.

-directdrag: allow mouse dragging without ctrl key pressed.

To prevent mistaking click as dragging, I added minimal time limit of 
recognizing dragging, and used some trick to prevent the feeling of lag, please 
tryout and see if it works fine.

Original issue reported on code.google.com by HeMeng86@gmail.com on 23 Apr 2015 at 2:43

GoogleCodeExporter commented 9 years ago
-desktopres works, but why isn't that the default? Using current desktop res 
looks better and doesn't mess with your desktop. I'd make a parameter for 
changing monitor resolution instead.

The directdrag parameter itself works. The left-mouse drag feature without 
control doesn't really work though. When using it I accidentally dig out pieces 
of land and I still accidentally move the screen when trying to pickup 
creatures for example.
As for right-mouse, I've opened morkardar and tried to slap the imps around the 
heart, alternating between them. Sometimes my screen is suddenly reversed. The 
rotating itself for me also has the issues as described on issue #554.

Original comment by Loobinex on 24 Apr 2015 at 7:06

GoogleCodeExporter commented 9 years ago
desktopres is not default because in the discussion we had about screen 
resolution and scaling, mefisto seems to prefer the old way. I am aware that 
this is controvosal so I plan to make this more easy to change, i.e. merge it 
to cfg file.

About dragging:
1.I know there are some cases you dig tile unexpected, this will and can be 
fixed 100%.
2.About mis-detect of dragging, I added a time threshold to reduce 
mis-detect(you need to press the mouse for more than xx miliseconds to be 
considered dragging), I will try to add some other tricks to further increase 
accurarcy. This is the main part I would like to test with this parameter.

Original comment by HeMeng86@gmail.com on 24 Apr 2015 at 7:21

GoogleCodeExporter commented 9 years ago
Mefisto, could you please take a look at what was said at Issue #573, you've 
seemed to have missed the last part of the discussion.
- Do you agree that with SDL2 using the desktop res works better than changing 
resoluion?
- What would you prefer to see as the default?

I understand you've made direct control an option so we can tweak it. That's 
fine, that's why I give feedback on how it feels right now so you can use that 
information.

Original comment by Loobinex on 24 Apr 2015 at 7:28

GoogleCodeExporter commented 9 years ago

Original comment by Loobinex on 24 Apr 2015 at 7:28

GoogleCodeExporter commented 9 years ago
I think that "desktop resolution" parameter should still force 1:1 blitting, 
and not any kind of scaling.

When this is done, then "desktop resolution" will be the best candidate for 
default setting.

Also, desktop resolution should be chosen from config file (as one of available 
resolutions). How should it be named - I'm not sure. Maybe "0x0x32", or just 
"DESKTOP" word.

Scaling single sprites is another issue, so I won't contaminate this thread 
with it.

Original comment by mefistotelis on 24 Apr 2015 at 9:16

GoogleCodeExporter commented 9 years ago
You can try how that feels like now by doing this:
1.turn on the parameter
2.in cfg file, set the resolution to your desktop one, if your resolution is 
not 4:3, use the nearest one, (for 1280*1080, the value is 1280*960)

Then you will get exactly the effect #5 is proposing.  Since we are totally 
relying on in-game scaler in this case, artifacts will be quite big on menu 
panel.

If you agree this is the thing we want, I can change the code easily(except the 
config UI)

Original comment by HeMeng86@gmail.com on 24 Apr 2015 at 9:41

GoogleCodeExporter commented 9 years ago
Why are you proposing 4:3 ratio? Is it for menu?

As I already stated, I don't want any post-composition scaling.
I could accept such scaling for movies only, and as a temporary workaround 
until we use open-source FMV player.

Original comment by mefistotelis on 24 Apr 2015 at 4:19

GoogleCodeExporter commented 9 years ago
 I propose 4:3 because "we don't want any post-composition scaling", and I am not sure the innate FX can render well in other ratios(I saw the intro picture and main menu scaled to fit non 4:3 monitor before. On the other hand, if we use 1280*960 for 1280*1080, blank will be left but no scaling will happen.). if you are sure that FX can compose any ratio, I don't have problem with it.

Original comment by HeMeng86@gmail.com on 24 Apr 2015 at 4:29

GoogleCodeExporter commented 9 years ago
I have to say, I quite like the look of the game with -desktopres in high 
resolution in r1735. Both 1280x1024 and 1280x960. The menu doesn't look too 
hot, but the rest looks nice and sharp.

Switching between those two resolutions shows the workaround(issue#573 c15) 
that the desktop isn't destroyed and gives you anomolies at the top and bottom 
screen.

Original comment by Loobinex on 24 Apr 2015 at 10:58

GoogleCodeExporter commented 9 years ago
The 3D engine of KeeperFX can render to any aspect ratio, and will scale GUI 
accordingly.

Same goes for fullscreen map - it adjusts to game resolution.

For other menus - there is a scaling code, but I haven't tested it on non-4:3 
ratios. It is possible that background and buttons will be scaled with 
different ratios, or that something won't fit visible area - that needs testing.

If there will be issues with menus, I think these should be fixed to allow no 
"post-composition scaling".

Original comment by mefistotelis on 25 Apr 2015 at 8:53