ScummVM on Ipad 3

paprik · Post by **paprik** » Sat Mar 31, 2012 6:46 pm

Hi Guys, is it possible to get ScummVM on Ipad 3? Is there any detailed description? or is there any .ipa file of scummVM so I can install it through Itunes/Iphone Config? Is there any way to install it without Jailbreak (which is not done yet, guess). Or do you have any working build I can install on Ipad 3?

Thanks!

MajinChibi · Post by **MajinChibi** » Tue Apr 03, 2012 7:28 pm

no jailbreak= no scummvm

if the jailbreak is available, i think the actual scummvm will just work fine.

savagenick · Post by **savagenick** » Wed Apr 11, 2012 11:25 am

Assuming there will be a jailbreak for the iPad3 I have a couple of questions:

1) Will the current build of scummvm use the maximum resolution of the device?
2) Is it likely that the gfx plugins available on the PC and mac (i.e. hq3x) would be ported across in order to use the extra pixels?

LordHoto · Post by **LordHoto** » Wed Apr 11, 2012 11:35 am

savagenick wrote:Assuming there will be a jailbreak for the iPad3 I have a couple of questions:

1) Will the current build of scummvm use the maximum resolution of the device?

Yes.

savagenick wrote:2) Is it likely that the gfx plugins available on the PC and mac (i.e. hq3x) would be ported across in order to use the extra pixels?

No.

savagenick · Post by **savagenick** » Wed Apr 11, 2012 12:44 pm

LordHoto wrote:
savagenick wrote:Assuming there will be a jailbreak for the iPad3 I have a couple of questions:

1) Will the current build of scummvm use the maximum resolution of the device?
Yes.

Excellent!

LordHoto wrote:
savagenick wrote:2) Is it likely that the gfx plugins available on the PC and mac (i.e. hq3x) would be ported across in order to use the extra pixels?
No.

Ummm any particular reason for this?

fuzzie · Post by **fuzzie** » Wed Apr 11, 2012 1:05 pm

savagenick wrote:Ummm any particular reason for this?

It would be a lot of work and it would consume more battery power, and there's no developer interest anyway.

LordHoto · Post by **LordHoto** » Wed Apr 11, 2012 1:44 pm

fuzzie wrote:
savagenick wrote:Ummm any particular reason for this?
It would be a lot of work and it would consume more battery power, and there's no developer interest anyway.

Indeed, if you want to donate an new iPad some developer might take a look at this feature, when it can be jailbroken.

savagenick · Post by **savagenick** » Thu Apr 12, 2012 7:56 am

Sorry, don't have enough dosh to donate an iPad3! - although I *could* donate some of my time instead (Software Engineer) if I managed to get hold of one. Will have a look at the source over the weekend.

fuzzie · Post by **fuzzie** » Thu Apr 12, 2012 9:37 am

savagenick wrote:Sorry, don't have enough dosh to donate an iPad3! - although I *could* donate some of my time instead (Software Engineer) if I managed to get hold of one. Will have a look at the source over the weekend.

Probably the sensible approach would be to use OpenGL shaders instead of trying to port the software scalers. I have a prototype working for desktop OpenGL, but haven't had time to tidy it up.

savagenick · Post by **savagenick** » Thu Apr 12, 2012 11:23 am

fuzzie wrote:
savagenick wrote:Sorry, don't have enough dosh to donate an iPad3! - although I *could* donate some of my time instead (Software Engineer) if I managed to get hold of one. Will have a look at the source over the weekend.
Probably the sensible approach would be to use OpenGL shaders instead of trying to port the software scalers. I have a prototype working for desktop OpenGL, but haven't had time to tidy it up.

Sensible because:
A) You guys are planning on switching to OpenGL (or OpenGL ES for embedded) for the renderer, making the software scalers obsolete
B) OpenGL shaders are quicker/more efficient than software scalers (Seems obvious now I type it)
C) All of the above?

I seem to remember reading on these forums a while back about using OpenGL, no idea about your plans/progress with it.

fuzzie · Post by **fuzzie** » Thu Apr 12, 2012 11:45 am

savagenick wrote:Sensible because:
A) You guys are planning on switching to OpenGL (or OpenGL ES for embedded) for the renderer, making the software scalers obsolete
B) OpenGL shaders are quicker/more efficient than software scalers (Seems obvious now I type it)

Well, some maybe important context: We already use OpenGL ES on iOS/Android, which is why it would take work to hook in the software scalers - and they'd be rendered useless when using any (upcoming!) OpenGL acceleration for modern engines like AGS/Wintermute/Sword2.5 which use a lot of alpha/transformations/etc.

savagenick · Post by **savagenick** » Thu Apr 12, 2012 12:42 pm

fuzzie wrote:
savagenick wrote:Sensible because:
A) You guys are planning on switching to OpenGL (or OpenGL ES for embedded) for the renderer, making the software scalers obsolete
B) OpenGL shaders are quicker/more efficient than software scalers (Seems obvious now I type it)
Well, some maybe important context: We already use OpenGL ES on iOS/Android, which is why it would take work to hook in the software scalers - and they'd be rendered useless when using any (upcoming!) OpenGL acceleration for modern engines like AGS/Wintermute/Sword2.5 which use a lot of alpha/transformations/etc.

Ahhh right, makes alot of sense now lol.

I'm assuming that means that if I wanted to help - making a port of your (currently) prototype shaders would be required, presumably when you're ready to "release" them? Or would OpenGL ES support the ones you've already written?

fuzzie · Post by **fuzzie** » Thu Apr 12, 2012 12:54 pm

savagenick wrote:Ahhh right, makes alot of sense now lol.

I'm assuming that means that if I wanted to help - making a port of your (currently) prototype shaders would be required, presumably when you're ready to "release" them? Or would OpenGL ES support the ones you've already written?

I haven't written any shaders, just the code to make ScummVM use them.

And that is all of about 50 lines of code, mostly to hack our XML parser into reading the convenient XML shader format used at https://gitorious.org/bsnes/xml-shaders ... penGL/v1.0 for a bunch of shaders - but it can't really go into the tree until it's less of a hack.

Apparently it's trivial to convert simple shaders (like the hq2x-style ones which are widely available) to OpenGL ES (apparently it's pretty identical to what WebGL uses, which there are online conversion tools for?), but I haven't actually tried it.

savagenick · Post by **savagenick** » Thu Apr 12, 2012 1:12 pm

fuzzie wrote:
savagenick wrote:Ahhh right, makes alot of sense now lol.

I'm assuming that means that if I wanted to help - making a port of your (currently) prototype shaders would be required, presumably when you're ready to "release" them? Or would OpenGL ES support the ones you've already written?
I haven't written any shaders, just the code to make ScummVM use them. And that is all of about 50 lines of code, mostly to hack our XML parser into reading the convenient XML shader format used at https://gitorious.org/bsnes/xml-shaders ... penGL/v1.0 for a bunch of shaders - but it can't really go into the tree until it's less of a hack.

Apparently it's trivial to convert simple shaders (like the hq2x-style ones which are widely available) to OpenGL ES (apparently it's pretty identical to what WebGL uses, which there are online conversion tools for?), but I haven't actually tried it.

Ahh ok.

With some quick research it looks like all 3 forms of OpenGL use GLSL with the main difference being that OpenGL ES and WebGL only support Vertex and Fragment Shaders. Seeing as the filters we are talking about only use those 2 types of shaders in the first place I don't think it would take too long to "port" standard OpenGL shaders. Hopefully the variables like "gl_position" etc are either identical or similarly-named, don't see why they wouldn't be...

savagenick · Post by **savagenick** » Wed May 09, 2012 9:20 am

"Singron will turn scalers into plugins and will add some new ones"

Is this fella already doing what we've just been talking about?