I'm thinking it'll have to be done eventually (sooner than later) considering resolution independence is right around the corner with Vista, OS X and a few Linux distros. Someone should consider putting some time into this because it'll have to done one day anyway.
I'm also thinking about people with 24" screens (which are definitely becoming affordable) and 30" screens who have to suffer the 'black border' syndrome. I'll be one of these people next month.
Scalers
Moderator: ScummVM Team
No! Most certainly: no! There is nothing we have to do. We can do it, we may want to do it -- but the moment you start speaking about what we / the ScummVM team "have to do", you are completely loosing your touch to reality.rented mule wrote:I'm thinking it'll have to be done eventually (sooner than later) considering resolution independence is right around the corner with Vista, OS X and a few Linux distros. Someone should consider putting some time into this because it'll have to done one day anyway.
We are a bunch of volunteers who choose to spend our valuable spare time on developing whatever aspects of ScummVM we like. We take feature requests (there is even a tracker for that), we take patches, and we usually try to fix bugs as they are reported. But we all do that because we decide that we want to do it.
The moment starts telling me that I/we "have to" do something, I usually lower my internal priority of that item. The more often I am told that I "have to" do it, the less likely I am to do it. Mainly because I don't see why I should let others tell me how I have to spend my spare time. I can just as well spend it with my friends, sports, reading, other open source projects.
Guess what, I am using a 24" LCD, and it works just faboulous with ScummVM in fullscreen mode, since both my OS and my screen know how to do scaling, toorented mule wrote:I'm also thinking about people with 24" screens (which are definitely becoming affordable) and 30" screens who have to suffer the 'black border' syndrome. I'll be one of these people next month.
.
Why has it to be done one day? I don't see any reason.rented mule wrote:I'm thinking it'll have to be done eventually (sooner than later) considering resolution independence is right around the corner with Vista, OS X and a few Linux distros. Someone should consider putting some time into this because it'll have to done one day anyway.
-
rented mule
- Posts: 70
- Joined: Wed Jan 25, 2006 5:27 pm
I think I've explained it clearly enough...resolution independance. Higher PPI screen will make it a must for application developers to follow some OS guidelines so that screen elements scale properly or else they'll end up becoming postage stamp-sized.LordHoto wrote:Why has it to be done one day? I don't see any reason.rented mule wrote:I'm thinking it'll have to be done eventually (sooner than later) considering resolution independence is right around the corner with Vista, OS X and a few Linux distros. Someone should consider putting some time into this because it'll have to done one day anyway.
fingolfin misunderstood me...he completely took "have to do" out of proportion by pretending like it meant I was forcing them to do something they don't want to. It's not. Someone will do it eventually because it's a MUST! I'm not the one that's gonna tell anyone to do this...someone will go out of its way to do it eventually because ScummVM will look ridiculous on a 200PPI display on OS X, Linux or Vista.
No...screen resolution changes does not count fingolfin.
I am glad to hear that. Though I was not "pretending" anything. You know, when communicating, in the end it doesn't matter what you *intended* to say, it mattesr what you actually said and how it was received... And I happen to react very allergic when somebody implies that something is a must with regards to ScummVM.rented mule wrote: fingolfin misunderstood me...he completely took "have to do" out of proportion by pretending like it meant I was forcing them to do something they don't want to. It's not.
I don't follow your logic. Those systems will (and to an extent already do) provide legacy support for the gazillions of applications out there which are based on raster graphics, as opposed to vector graphisc (and which hence can't just automatically scale to arbitrary resolutions). So to me it seems the situation will grow better, not worse.rented mule wrote: Someone will do it eventually because it's a MUST! I'm not the one that's gonna tell anyone to do this...someone will go out of its way to do it eventually because ScummVM will look ridiculous on a 200PPI display on OS X, Linux or Vista.
Uhh... Why not? It's a built-in feature of ScummVM to do automatic screen resolution switching when entering full screen mode. And in the end, we are dealing with pixel data here. There is no such thing as resolution independence for that, ever. You *have* to scale it one way or the other if you want to fill it your screen then. And if the OS or the screen itself automatically perform that scaling for me -- how and why does that not count ???rented mule wrote: No...screen resolution changes does not count fingolfin.
Mind you, we might still choose to implement an (semi-)arbitrary scale scaler one day, but likely not for the reasons you named, but rather for the opposite reason -- to support old systems tht run on new hardware and can't do the scaling automatically, or for people running an old system on one of those cheap LCDs that can't do scaling either.
can we get back to the actual issue please?
cutting up the texture is something that is generally done because the original surface is not a power of two texture, for example the mega-drive runs at 320x240, i had to cut it into two parts, 255x255, 64x255, obviously its a little big as well so the quad's are slightly taller than the screen. obviously this is all rediclous. thats why an opengl extension was developed, which most newer cards support (not mine unfortunatly) called ARB_texture_rectangle which lets you have a texture of whatever size you want.
about going over the maximum texture size, its pritty much a moot point most of the time, as long as you keep it under 2048x2048.
the seamms inbetween cut up textures are caused by floating point errors, which are kinda tricky to get rid of, personally i havn't found a way past this yet, i am fairly sure there is a way but seing as i use point based interpolation (as linear interpolation is rather ugly imo) i don't see any seams so its not really a problem.
cutting up the texture is something that is generally done because the original surface is not a power of two texture, for example the mega-drive runs at 320x240, i had to cut it into two parts, 255x255, 64x255, obviously its a little big as well so the quad's are slightly taller than the screen. obviously this is all rediclous. thats why an opengl extension was developed, which most newer cards support (not mine unfortunatly) called ARB_texture_rectangle which lets you have a texture of whatever size you want.
about going over the maximum texture size, its pritty much a moot point most of the time, as long as you keep it under 2048x2048.
the seamms inbetween cut up textures are caused by floating point errors, which are kinda tricky to get rid of, personally i havn't found a way past this yet, i am fairly sure there is a way but seing as i use point based interpolation (as linear interpolation is rather ugly imo) i don't see any seams so its not really a problem.
-
Vinterstum
- ScummVM Developer
- Posts: 580
- Joined: Sun Oct 16, 2005 6:59 am
-
rented mule
- Posts: 70
- Joined: Wed Jan 25, 2006 5:27 pm
Ok well if OSes are so magical can you tell me why there's a black border around, say, Monkey Island 1 at 3x or HQ3x in OS X @ 1280x1024? 'cuz I've got no clue. Secret dev feature? Don't tell me 10.4.7 and this brand spankin' new 20" LG display is old either.fingolfin wrote:I am glad to hear that. Though I was not "pretending" anything. You know, when communicating, in the end it doesn't matter what you *intended* to say, it mattesr what you actually said and how it was received... And I happen to react very allergic when somebody implies that something is a must with regards to ScummVM.rented mule wrote: fingolfin misunderstood me...he completely took "have to do" out of proportion by pretending like it meant I was forcing them to do something they don't want to. It's not.
I don't follow your logic. Those systems will (and to an extent already do) provide legacy support for the gazillions of applications out there which are based on raster graphics, as opposed to vector graphisc (and which hence can't just automatically scale to arbitrary resolutions). So to me it seems the situation will grow better, not worse.rented mule wrote: Someone will do it eventually because it's a MUST! I'm not the one that's gonna tell anyone to do this...someone will go out of its way to do it eventually because ScummVM will look ridiculous on a 200PPI display on OS X, Linux or Vista.
Uhh... Why not? It's a built-in feature of ScummVM to do automatic screen resolution switching when entering full screen mode. And in the end, we are dealing with pixel data here. There is no such thing as resolution independence for that, ever. You *have* to scale it one way or the other if you want to fill it your screen then. And if the OS or the screen itself automatically perform that scaling for me -- how and why does that not count ???rented mule wrote: No...screen resolution changes does not count fingolfin.
Mind you, we might still choose to implement an (semi-)arbitrary scale scaler one day, but likely not for the reasons you named, but rather for the opposite reason -- to support old systems tht run on new hardware and can't do the scaling automatically, or for people running an old system on one of those cheap LCDs that can't do scaling either.
Anyway...10.5 will provide the scaling for windows...not sure for fullscreen.
Cause 320x200 X3 = 960x600... hence the black borders you get on your 1280x1024 screen mode. That's the way fixed scalers work, no voodoo magic behind it. 'nuff said.rented mule wrote:can you tell me why there's a black border around, say, Monkey Island 1 at 3x
Hardware scaling might or might not be implemented in a future far, far away, but you certainly won't make your point by barking at one of the top dogs :)
Well all OpenGL 2.0 (could be a bit too new though) conform implementation HAVE to support non power of two textures, and AFAIK most drivers implement it, maybe you should check your graphics card driver. Also the according extension before was this: ARB_texture_non_power_of_twogord wrote:cutting up the texture is something that is generally done because the original surface is not a power of two texture, for example the mega-drive runs at 320x240, i had to cut it into two parts, 255x255, 64x255, obviously its a little big as well so the quad's are slightly taller than the screen. obviously this is all rediclous. thats why an opengl extension was developed, which most newer cards support (not mine unfortunatly) called ARB_texture_rectangle which lets you have a texture of whatever size you want.
i beleve opengl 2.0 is far far too new yes you could write something to use opengl 2.0 but you'd alienate a lot of people, i think for something like ScummVM its best to stick to what works on the most ammount of setups within a reasonable degree. and no its not something that can be fixed on the driver level, graphics cards either support non power of two textures or they do not. mine does not... its rather old. i beleve it was created around the time charles dickens produced a book about a small boy that was far too greedy for his own good.
you could write something to use opengl 2.0 but you'd alienate a lot of people, i think for something like ScummVM its best to stick to what works on the most ammount of setups within a reasonable degree. and no its not something that can be fixed on the driver level, graphics cards either support non power of two textures or they do not. mine does not... its rather old. i beleve it was created around the time charles dickens produced a book about a small boy that was far too greedy for his own good.-
eriktorbjorn
- ScummVM Developer
- Posts: 3561
- Joined: Mon Oct 31, 2005 7:39 am
That sounds overly optimistic to me. I've encountered several OpenGL applications where I've gotten nothing but a white window instead of the intended graphics, and they were probably running at 640x480 or 800x600 or something like that. I would guess the textures they were using were still a lot smaller than 2048x2048.gord wrote:about going over the maximum texture size, its pritty much a moot point most of the time, as long as you keep it under 2048x2048.
(My graphics card? Oh, it's a Matrox G400. 16 MB memory, as I recall it.)
Not that I expect to use an OpenGL ScummVM renderer on this computer, since changing screen resolution works well for me whenever I feel like running a game in fullscreen mode.
I don't see why one has to go through OpenGL to get the image stretched properly to fullscreen. As I see it this is a 2D-2D operation and relying on (potentially) 3D APIs does not feel right. There are still ways to do 2D gfx properly, as scummvm demonstrates with SDL.
Of course, supporting arbitrary scalers or not in scummvm is another issue, given especially the complexity of an arbitrary upsampling/downsampling filter. Complexity in terms of computational complexity but also in terms of image processing algorithms. Fortunately though, we could use resampling filter kernels from other open source projects (VirtualDub comes to mind).
Of course, supporting arbitrary scalers or not in scummvm is another issue, given especially the complexity of an arbitrary upsampling/downsampling filter. Complexity in terms of computational complexity but also in terms of image processing algorithms. Fortunately though, we could use resampling filter kernels from other open source projects (VirtualDub comes to mind).