0000975: Support "custom" resolutions by scaling

Notes
(0002555) Warmonger (administrator) 2012-05-25 15:21	I don't see why this is marked as urgent. Ports are quite complicated and low-priority issue and it's not only about scaling. You can always try to make one on your own ;)

(0002556) Ivan (developer) 2012-05-25 15:40	... Have you read comments in your first report? http://bugs.vcmi.eu/view.php?id=971 [^] This is not just apply scaling to screen buffer and be happy - this is quite complex feature that will need tweaking half of our client.

(0002557) majaczek (reporter) 2012-05-25 18:51	Oops sorry... I thought it sunk during posting. N900 has already linux thought so it's not about android porting. VCMI compiles and run fine on N900 Developer Emulator but only at 800x600 or higher while real device crashes or freezes on any fullscreen resolution other than 800x480 (so i.e. Dosbox run fine on 800x480 but instantly crashes at 640x480). Yeah porting for another systems would be lot of work, but if only endianess is proper, then once having run in native resolution it would work on most ARM devices with linux.

(0002558) majaczek (reporter) 2012-05-25 19:00	Okay it's not so urgent, and yeah software scaling is much slower than hardware one but once having the feature we may try it out. I thought just about drawing on buffer with internal resolution and scaling it just before blitting on screen - this need only one buffer between VCMI GUI and screen surface - equally one image scaling per displayed frame plus scaling of mouse position. If software scaling is not enough to run VCMI enough efficiently, there is another unrelated trick - SDL you use have internal graphics drivers, and Dosbox prooved that "surface" and "overlay" one worked on N900 - and overlay one scales automatically to screen resolution (with drop of proportions ratio) which apparently is hardware accelerated scaling (but it should get probably in another report). I agree it may be not so urgent for you but it is more than normal feature for me. Anyway keep the ticket as you want - it's your house.

(0002564) Tow (developer) 2012-05-25 22:29	>would be to slow we may consider something hardware accelerated, but I believe the algorithm we have si good enough for us. And I don't believe that, N900 has 600 MHz CPU. I guess even without scaling hero movement and battles are lagging. So instead of pointless discussion about beliefs, prove me wrong by presenting us with a patch implementing your idea. Hardware acceleration is IMO the only way to go and I guess we'll sooner or later start working on hardware-accelarated GUI stack, that'll solve the issue. However I fear that won't happen soon, so if you really care about this feature you either have do it yourself or find someone who will do it for you. I'm closing this issue, because it a) is a duplicate of 0000971 b) doesn't refer to a bug or missing H3 functionality or trivial improvement c) requests for an implementation detail If you want to further discuss this issue, please use our forums. Thank you for understanding.

Issue History
Date Modified	Username	Field	Change
2012-05-25 13:11	majaczek	New Issue
2012-05-25 15:21	Warmonger	Note Added: 0002555
2012-05-25 15:22	Warmonger	Priority	urgent => normal
2012-05-25 15:40	Ivan	Note Added: 0002556
2012-05-25 18:51	majaczek	Note Added: 0002557
2012-05-25 19:00	majaczek	Note Added: 0002558
2012-05-25 22:29	Tow	Note Added: 0002564
2012-05-25 22:29	Tow	Status	new => closed
2012-05-25 22:29	Tow	Assigned To	=> Tow
2012-05-25 22:29	Tow	Resolution	open => duplicate

Relationships