Opened 12 years ago

Closed 11 years ago

Last modified 5 months ago

#8650 closed patch (wontfix)

DXA Player: double size scaling option

Reported by: SF/robinwatts Owned by: sev-
Priority: normal Component: Video
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)

diff (4.6 KB) - added by SF/robinwatts 12 years ago.
Patch to allow DXA to double if required
diff.2 (4.9 KB) - added by SF/robinwatts 12 years ago.
Corrected patch to allow DXA to double if required

Download all attachments as: .zip

Change History (22)

Changed 12 years ago by SF/robinwatts

Attachment: diff added

Patch to allow DXA to double if required

comment:1 Changed 12 years ago by SF/robinwatts

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

Changed 12 years ago by SF/robinwatts

Attachment: diff.2 added

Corrected patch to allow DXA to double if required

comment:2 Changed 12 years ago by SF/robinwatts

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 Changed 12 years ago by Kirben

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 Changed 12 years ago by sev-

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 Changed 12 years ago by SF/robinwatts

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 Changed 12 years ago by joostp

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 Changed 12 years ago by eriktorbjorn

> [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 Changed 12 years ago by SF/robinwatts

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 Changed 11 years ago by sev-

OKay, so I committed slighly modified patch. The modifications I made were to bring code formatting in order.

comment:10 Changed 11 years ago by sev-

Owner: set to sev-
Status: newclosed

comment:11 Changed 11 years ago by Kirben

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 Changed 11 years ago by Kirben

Status: closednew

comment:13 Changed 11 years ago by SF/robinwatts

> 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 Changed 11 years ago by Kirben

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 Changed 11 years ago by Kirben

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 Changed 11 years ago by sev-

Owner: changed from sev- to Kirben

comment:17 Changed 11 years ago by sev-

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 Changed 11 years ago by sev-

Owner: changed from Kirben to sev-
Resolution: wontfix
Status: newclosed

comment:19 Changed 11 years ago by sev-

So I am closing this patch. Unfortunately this feature request/patch is not universal enough to be processed properly.

comment:20 Changed 5 months ago by digitall

Component: Video
Note: See TracTickets for help on using tickets.