320x240 dxa files for Feeble Files

[Zeladin]

Any chance that support and correct scaling for playback of 320x240 dxa files for feeble files can be added. It could be a simple matter of centering screen, and switching off scaling(like the zoom?) if that size is detected.

That feature would really cut down the size of Feeble Files (the video files by a factor of four approx). It would be more economical on cpu time too possibly.

I'm using the reduced size videos for now anyway, even though it makes it a bit of a postage stamp.

Anybody else got thoughts on that? Would mpeg video support be possible? There's already the player.. I had a look at the code, I'm sure it wouldn't be too difficult, if one already has the compiler with all the right libs and etc..

[clone2727]

Anybody else got thoughts on that? Would mpeg video support be possible? There's already the player.. I had a look at the code, I'm sure it wouldn't be too difficult, if one already has the compiler with all the right libs and etc..

mpeg support? That's not done by platform. It has to be added to the game separately.

[eriktorbjorn]

Anybody else got thoughts on that? Would mpeg video support be possible? There's already the player.. I had a look at the code, I'm sure it wouldn't be too difficult, if one already has the compiler with all the right libs and etc..

Possible? Almost certainly. The Broken Sword games support both MPEG and DXA. But supporting both was no fun, since the MPEG player is an annoying hack in so many ways.

The re-encoding to MPEG makes the frames use 16-bit colour instead of 8-bit. The MPEG player can reduce them to 8-bit colour, but the standard mode of operation is to draw 16-bit colour frames on the "overlay", same as the ScummVM GUI uses.

Before they can be drawn at all, they have to be converted from YUV (one luminance and two chrominance components) to RGB (red, green, blue).

The 0.9.0 GUI redesign meant that things drawn to the overlay are no longer automatically scaled, so the player has to do that manually when using 2x or 3x scalers.

The only advantage of the MPEG player that I can think of is that the movies can be made smaller than than the DXA files (at the cost of lower quality).

[Zeladin]

The only advantage of the MPEG player that I can think of is that the movies can be made smaller than than the DXA files (at the cost of lower quality).

In light of that I can see that mpeg support wouldn't be too important/desirable. I had a vague notion on my mind that it was good because it wasn't propriatry - which is perhaps another good point, but I don't think I, at least would bother.

The 0.9.0 GUI redesign meant that things drawn to the overlay are no longer automatically scaled, so the player has to do that manually when using 2x or 3x scalers.

By 'the player' I take it you mean the mpeg player rather than the dxa player. I think I might see what broken sword is like with dxa files. It will probably have the same issues as feeble files with 320x240 video I would guess.

mpeg support? That's not done by platform. It has to be added to the game separately.

I hope I didn't suggest it was.. That would be oddly paradoxical.

Anyway I found Djwillis devkit on the Gp2x archive, so I might see about building my own scummvm... and learning some rudiments of the C++ language. Djwillis hasn't been about has he? Or is there a new release of scummvm expected anytime soon? Obviously my messing about would be little use to anyone else (and possibly not even me).

Edit; not a good start my quote control is gone haywire.

[eriktorbjorn]

By 'the player' I take it you mean the mpeg player rather than the dxa player.

Yes, the MPEG player. The DXA movies use 8-bit colour, like the original Smacker movies.

mpeg support? That's not done by platform. It has to be added to the game separately.

I hope I didn't suggest it was.. That would be oddly paradoxical.

The Broken Sword games share a common MPEG decoder (which uses libmpeg2 to do the actual decoding), but each of them has its own player, i.e. the part that makes sure that the decoded frames are displayed at the correct frame rate, and that the sound is played.

[Zeladin]

mpeg support? That's not done by platform. It has to be added to the game separately.

I hope I didn't suggest it was.. That would be oddly paradoxical.

The Broken Sword games share a common MPEG decoder (which uses libmpeg2 to do the actual decoding), but each of them has its own player, i.e. the part that makes sure that the decoded frames are displayed at the correct frame rate, and that the sound is played.

Ah thanks for the clarification. I was thinking, that is was obviously game specific, otherwise Feeble files would already work with mpeg. But I see now that its more specific than that. Apologies to clone2727 for my misunderstanding. I'm only guessing but I suppose this is related to rendering to the screen. I'm not worried about the mpeg support now anyway, by the sounds of it it would be a bit more difficult than I first thought.

Only, are dxas the same, ie decoded by a seperate module but played back by a game specific player, presumably "built into" the game engine. Just had a closer look in animation.cpp..

Code: Select all

// Resolution is smaller in Amiga verison so always clear screen
if (_width == 384 && _height == 280) {
		memset(_vm->_frontBuf, 0, _vm->_screenHeight * _vm->_screenWidth);...etc

a bit of code like this with addition of setting zoom buttons true and placing the cursor/zoom window.. Should Achieve my goal.

[sev]

In light of that I can see that mpeg support wouldn't be too important/desirable. I had a vague notion on my mind that it was good because it wasn't propriatry - which is perhaps another good point, but I don't think I, at least would bother.

In fact, our current DXA compression is not proprietary anymore. Not that it even originally had some unique technology in it (XORing a frame against previous one and zipping it is not a high-tech). But now it is all courtesy of Benjamin Haisch aka John Doe. and gosh, it's even more superior than original Smacker compression, as it produces smaller files!


Eugene

[eriktorbjorn]

and gosh, it's even more superior than original Smacker compression, as it produces smaller files!

I think I saw a couple of files where the DXA file was bigger than the original Smacker file, even without the sound, when I was re-encoding the Feeble Files cutscenes (2 CD version). But the total size of the DXA files with Ogg Vorbis audio was smaller than the total size of the Smacker files.

(That might not be a completely fair comparison, since Ogg Vorbis is lossy. On the other hand, I doubt the Smacker audio compression is lossless to begin with.)

[Zeladin]

But now it is all courtesy of Benjamin Haisch aka John Doe. and gosh, it's even more superior than original Smacker compression, as it produces smaller files!

That sounds nice... Thus we really, really don't need the mpeg video support for Feeble Files. I think though BS1 and BS2 have been released with the mpeg video though, so it'll probably still be useful (and one can still dl the mpeg videos for them).

Smacker audio compression is lossless to begin with

But doesn't that mean that if compressing from Smacker we'll lose even more quality... Surely a straight compare of silent smk and dxa could be done, just to dismiss that element (not that smk is really an option?)

Anyway been hunting around a bit investigating. I haven't done much programming to be honest, sort work by the philosophy of learning what I don't already know.. Anyway does this procedure

SDL_WarpMouse(x, y);

send the mouse to a particular x,y position, and where is the origin/ more particularly centre screen?

so I would have pseudo (sort of) code

Code: Select all

 if 320x240
leftkeypress = true;
rightkeypress = true;
sdl_warpmouse(x,y); //centre screen assuming the zoom window will follow 
leftkeypress = false;
rightkeypress = false;
Amiga clear screen procedure;

Obviously finding out how to put that in C++ terms will be far easier than say, figuring out how to compile the whole thing... (Which of course I should give a dry run before changing anything). Perhaps I should look for djwillis' zooming bit of code though, doing it using a sdl procedure/thingy might be the better option though... Another thought would the cursor follow, or would I have thrown it all out of kilter..

[eriktorbjorn]

But doesn't that mean that if compressing from Smacker we'll lose even more quality...

Yes. But since it sounds fine to me, I don't consider that particularly important. You could probably use FLAC, if it's important to you.

Surely a straight compare of silent smk and dxa could be done, just to dismiss that element (not that smk is really an option?)

Possibly. But I don't know how to find out how much of a Smacker file is video and how much is audio.

[Zeladin]

Possibly. But I don't know how to find out how much of a Smacker file is video and how much is audio.

I was thinking just a simple resmack of the original smacker without the audio, not sure if that option exists though.

I think I'll abandon this for now, I really don't have the expertise. I haven't even figured out how to compile the thing. I think my approach might have to come from the gp2x backend too which would make things more difficult. I rather suspected that compiling the thing might be a bit beyond me.. Ah well best just sit and be patient for the next release like everyone else. (Really hoping this feature is included). Not to say that I might not have another go..

Does anyone know did djwillis use a vm on windows with windows executable compilers or a linux machine with linux executable compilers? Or am I asking stupid questions?

[DJWillis]

Does anyone know did djwillis use a vm on windows with windows executable compilers or a linux machine with linux executable compilers? Or am I asking stupid questions?

My GP2X GCC build scripts produce working tool-chains from CygWin (hosted on Win32) or native Linux jut fine, they also work fine on normal BSD's and OSX with some work.

That said the build scripts need to reworked ever so slightly for building current SVN head due to some GCC bugs with Pragma packing. When I get a chance I will but the reworked scripts up on Distant-Earth.com and use the newest GCC as a base.

As for me not being about, true, have a few hellish months for various reasons so not been keeping up with my duties as I should have . I hate to admit this is the first chance I have had to look at the forum in ages.

However I did start to play with 320*240 DXA support some time ago and made a little headway (using BS2 as a test game), I will try and pick it up again at some point. I don't own Feeble Files so I can't really comment on that game.

As a side note. I don't see libMPEG2 (MPEG support) making my official builds of ScummVM as while it will compile fine the work to get it running fast enough is just not worth the effort IMHO. Especially as DXA support on the whole is very good and has room for improvement on the GP2X. If another GP2X/ARM dev works on the lib then of course I will reconsider using it .

[Zeladin]

My GP2X GCC build scripts produce working tool-chains

That sounds good, in theory then using these tool-chains I could compile scummvm using your build scripts with little alteration. Are these available on the gp2x archive somewhere? Or do I need to make a closer look at your webpage...

Feeble files is pretty good really, except when you go into oracle. The Dxa videos play back well too. It a pity you don't have a copy, I think its fairly difficult to obtain too. I'm willing enough to test it out. Is it possible to replace the cursor as well, the current (main one, it cycles through different ones showing the different actions with a right click) is only a single pixel wide which leads to it disappearing every so often, due to the pixel dropping scaling I guess.

I think after the discussion here mpeg video support isn't worth spending a lot of time on. The dxa format seems to give enough compression, and is entirely feasible for the gp2x in terms of space and processor, at its native resolution.

Speaking of Broken sword. I took a shot a playing BS1, I think the saves might be currently broken. I tried it on several versions of scummvm so I might have confused it.. Or perhaps there wasn't a version that had both working video and saves... I'd have to check.

Anyway thanks for the reply, and update.