#8650 closed patch (wontfix)
DXA Player: double size scaling option
| Reported by: | SF/robinwatts | Owned by: | sev- |
|---|---|---|---|
| Priority: | normal | Component: | Video |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
This patch allows the DXA movie player to double the size of movies on playback where possible. In particular this is intended to allow the Broken Sword movies (normally 640x400) to be reencoded at 320x200 (the size appropriate for most WinCE devices screens) and yet to playback fullscreen.
[Normally, a 320x200 movie will be played back at 160x100 due to the half-scaling of the screen - doubling to 640x400 and then halving back to 320x200 is inelegant, but works.]
The patch works by offering an alternative loadMovie entry point in the dxa player. Normally loadMovie is called just with a filename and returns success/failure. The new entry point takes both the filename, and the maximum width/height.
This calls the original method to open the file, and if it succeeds, checks to see if the file can safely be scaled up and yet fit within the bounds of the screen give to it. The scale is restricted to either 1 or 2 currently, but could be extended in future if required.
If a scale of 2 is possible, a new buffer, to hold the scaled screen is allocated. If this cannot be allocated, then we drop back to the no scaling case.
The getWidth and getHeight methods new return the width/height multipled by the scale factor, so to all intents and purposes, the scaling operation is invisible to callers of this class.
The only change required of callers therefore is to pass in the 'expected' size of the screen. For Broken Sword 1, this is simply 640x480 - this code has been tested and found to work.
For Broken Sword 2 the screen appears to be centred based on _vm->_screen->getScreen{Wide,Deep}, so I use that information instead; this is untested as yet - I will add a comment here as soon as I manage to test this.
Finally, this routine appears also to be called by the 'agos' engine. I do not have an agos game to test, so can't verify this fix here.
In the absence of anyone being able to test the BS2 or agos alterations, this patch could easily go in without them, but I thought it better to supply them here than to omit them.
Robin
Ticket imported from: #1709219. Ticket imported from: patches/755.
Attachments (2)
Change History (22)
by , 18 years ago
comment:1 by , 18 years ago
Definately ignore the AGOS diff - it doesn't compile. Sorry, should have picked this up earlier, but timestamps on my svn tree must have gotten screwed somehow, so it didn't recompile. The rest of the patch is fine though.
Robin
comment:2 by , 18 years ago
New patch attached that at now compiles with agos support in too. BS1 tested and works fine. BS2 and agos still untested though.
File Added: diff
comment:3 by , 17 years ago
This patch sounds like a hack, and makes no sense at all. Why the additional upscaling (with the current downscaling) of cutscenes, using lower quality cutscenes?
The patch would require extra memory and CPU, due to the added upscaling, and would give worse results due to using lower quality cutscenes. Plus people need to actually re-size and re-encode the cutscenes themselves.
I see no benefit, over using the current 640 x 400 cutscenes, which should be down scaled to 320 x 200 already on WinCE devices, by the sounds of it.
comment:4 by , 17 years ago
This looks like a hack to me as well. Also this arises several questions/problems:
- Who will host those half-size cutscenes - What size advantage will be gained - How to produce such cutscenes from original? I.e. patch to encode_dxa will also be needed
Taking in account current situation with flash memory prices, I hardly see a problem of putting additional 50MB for normal size cutscenes, when whole game takes over 1GB.
comment:5 by , 17 years ago
I freely admit that this is a bit of a hack.
It would be nicer to just decode movies without the upscaling/downscaling rubbish, but given that the downscaling has to happen in the current architecture this is as minimally invasive as I could make it.
The time taken to decode a (2X * 2Y) movie is greater than the time taken to decode an (X * Y) movie and then upscale it - hence overall this saves time.
Thus the patch trades off some extra runtime memory (if the scaling is used) against improved speed and storage memory. If that runtime memory is not available then it drops back seamlessly to unscaled mode - so we never get ourselves into a position where we can't play a movie because of the extra memory required for the upscaling.
I'm currently hosting these half-sized cutscenes, and am prepared to do so for the forseeable future if that will help (http://www.wss.co.uk/scummvm).
The 'full size' DXA downloads are 60 and 113 Meg. The 'half size' ones are 43 and 56 (but mine use MP3 rather than flac). Broken Sword 1 is 350Meg ish, not a Gigish. I'll admit the savings are not as much as I'd initially hoped, but they aren't bad.
No changes are needed to encode_dxa at all - I reencoded using standard encode_dxa and the RAD tools.
The original target for this work was speed on WinCE devices. Maybe with the way the WinCE ports graphics have been accelerated that's not so important now. It might still be useful for other ports though? DJWillis was using this patch on the GP2X for a while - maybe he can see a measurable improvement from it?
comment:6 by , 17 years ago
I think the reason this was proposed in the first place is for 320x200 devices which simply can't cope with 640x400 DXA decoding and subsequent downscaling, whereas a 320x200 DXA would work well, so in that case I don't think the patch "doesn't make sense".
The PSP seems to be able to cope with the 640x400 DXAs well enough (only tried BS1), but since they're scaled down to 480x270 in hardware anyway, we could just as well use < 640x400 DXAs there too to save space. Sure, with BS1&2 the difference in size is basically negligible, but with Feeble Files I suppose it could make a considerable difference.
Just my thoughts on this matter - ultimately I don't care too much if this feature gets added or not, because it works "good enough" for me already.
comment:7 by , 17 years ago
> [Normally, a 320x200 movie will be played back at 160x100 due to the > half-scaling of the screen - doubling to 640x400 and then halving back to > 320x200 is inelegant, but works.]
So, if I understand you correctly, it would
* Decode a 320x200 frame. * Upscale it to 640x400. * Send it to the backend, where it's downscaled to 320x200 again.
Would it be possible to instead simply tell the backend to temporarily turn off the downscaling? It seems to me that this ought to reduce the workload a bit, but there may be technical reasons against it that I'm unaware of.
comment:8 by , 17 years ago
eriktorbjorn> Yes, your description is exactly right.
Temporarily turning off the downscaling would clearly be a much nicer way of doing it, but I believe (with my admittedly limited knowledge of the architecture) that this isn't an easy thing to do without lots more work.
I'm quite prepared to be wrong though!
comment:9 by , 17 years ago
OKay, so I committed slighly modified patch. The modifications I made were to bring code formatting in order.
comment:10 by , 17 years ago
| Owner: | set to |
|---|---|
| Status: | new → closed |
comment:11 by , 17 years ago
Why was the patch added? I thought it was agreed it was a hack, and an alternative method should be found.
The videos in the Amiga / Macintosh version of The Feeble Files and on the OmniTV in The Feeble Files are currently broken. Due to different resolution sizes been used in those situations, which aren't always known before video is loaded.
comment:12 by , 17 years ago
| Status: | closed → new |
|---|
comment:13 by , 17 years ago
> The videos in the Amiga / Macintosh version of The Feeble Files and on the > OmniTV in The Feeble Files are currently broken. Due to different > resolution sizes been used in those situations, which aren't always known > before video is loaded.
Are you saying that these videos don't work *because of this patch* ?
This patch shouldn't ever cause videos not to play that played before, nor should it use more memory.
We can always remove it if anyone figures out a way to do it less hackily...
comment:14 by , 17 years ago
Correction to my last message: Actually it is just the OmniTV videos in The Feeble Files that are effected, the smaller video files used by the Amiga version of The Feeble Files are still alright.
Specifically only part of the OmniTV videos are displayed, due to scaling been triggered. The OmniTV video are small (width 56 height 104), and displayed on the TV screen when held prisoner in the Cygnus Alpha.
comment:15 by , 17 years ago
I committed fix for the OmniTV videos in The Feeble Files for now. The problem is the destination size always must be sent, before any video file is loaded.
Which is an issue for any game that will display videos of various sizes, The Feeble Files is the only game effected so far. But this will become even more of an issue in future game, which uses videos of many difference sizes.
For this reason, I think it would be best if the patch was reverted.
comment:16 by , 17 years ago
| Owner: | changed from to |
|---|
comment:17 by , 17 years ago
Yes, please, revert it, as well as your consequent patch to AGOS engine.
I just did not think about OmniTV.
Alternative approach would be to add special flag to DXA videos which will tell that this video is in original resolution. But this will not work with current cutscene packs. So no, this idea unfortunately is not acceptable.
Also I believe that bunch of HE games which use Smacker videos for acotrs got broken with this patch as well.
comment:18 by , 17 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | → wontfix |
| Status: | new → closed |
comment:19 by , 17 years ago
So I am closing this patch. Unfortunately this feature request/patch is not universal enough to be processed properly.
comment:20 by , 6 years ago
| Component: | → Video |
|---|
Patch to allow DXA to double if required