Which Function For Scaling/zooming?


john4p said:
Well, I used MS Paint to "scale" the images.

Just to show screen dimensions. With proper hardware-scaling the results will look much better.
Still some of us may prefer a small border than fuzzy ripply images.

There should probably be a per game config file anyway as other settings like clock speed, button setup other things could be set. If a scale option was there the user could set per app depending on it's native res.

If someone wanted to play with an app like lightwave or deluxe paint you wouldn't want to be stretching text and menus on a 640 x 400 screen you could want 1:1.
 
Last edited by a moderator:
This looks good for scaling SNES to a 4:3 ratio. Simple 2X integer scaled the image, then bilinear stretch it to 640 x 480. Don't need this for other consoles that have matching 4:3 ratio resolutions. Perhaps Amiga could benefit from this?

15qart5.jpg


Here's another:
33cydxk.jpg


Save these images to your SD card and try them out on your Pandora, see how it looks ;)
 
Exophase said:
Sigh, whatever. I asked you to do one simple thing, and that is to wait for it before you condemn it, and you can't even do that much. Oh well.

EDIT: Let me just say I'm tired of your attitude on this - not really because your presentation is on the immature side, which it is, but because you're being completely unfair. In your mind everything is either PSP or it isn't PSP. I've seen a lot of fractional scaling on PSP (gpSP is really nothing without it) and the scaling here is a) hitting a higher resolution target and B) using a much better filter and is much more subtle than you think.

By the way, I don't know how you can say that looking more like a CRT is "not necessarily a good thing" and still have a high opinion of phosphor-2x which is designed specifically to look like a CRT as much as possible.
Can you somehow take a screen grab and post it if that isn't too much work? Then I could see exactly what you have in mind. If it isn't terrible I will admit it (of course I can't see it scroll and that is where scaling can fall apart but if you say it doesn't ripple then I will believe it) .

I say looking like a CRT is not necessarily a good thing because it depends on what you are copying. If you just blur it out than that is an aspect that may not desirable. You either like the look or you don't. I hate the look of bi-linear but don't mind the look of phosphor 2X. That is just why I say options are good. Locking it to one way is limited and you will please some, but disappoint others. Most emus I have seen have multiple scale/filter no filter options.
 
Last edited by a moderator:
No, I can't take a screenshot because it isn't on the framebuffer, it's an overlay. I'm not taking a picture because I don't have a camera good enough to show the difference without making everything much blurrier than it is. Sorry..

I hope it's clear, it's being 2x2 scaled, the aspect ratio isn't changed. The options for that are currently the same as on the other platforms. Yeah, eventually I should have a hardware option for that, but that changes things a lot with Temper. For the first release this is probably what you're going to be getting - a virtual 320x240 taking up 640x480. Inside that virtual 320x240 it'll be just as if it's on Wiz or GP2X. The only thing is that it won't be a straight 2x2 duplication with very light filtering that follows a more proper frequency response. I'm not doing one w/o the filtering because I'd rather wait for the filter taps to be exposed, than have a soft scaler that impacts performance.
 
Exophase said:
No, I can't take a screenshot because it isn't on the framebuffer, it's an overlay. I'm not taking a picture because I don't have a camera good enough to show the difference without making everything much blurrier than it is. Sorry..

I hope it's clear, it's being 2x2 scaled, the aspect ratio isn't changed. The options for that are currently the same as on the other platforms. Yeah, eventually I should have a hardware option for that, but that changes things a lot with Temper. For the first release this is probably what you're going to be getting - a virtual 320x240 taking up 640x480. Inside that virtual 320x240 it'll be just as if it's on Wiz or GP2X. The only thing is that it won't be a straight 2x2 duplication with very light filtering that follows a more proper frequency response. I'm not doing one w/o the filtering because I'd rather wait for the filter taps to be exposed, than have a soft scaler that impacts performance.
Ok about the pictures I didn't know if it was easy but since it is not then I wait.

I thought PC-engine was 256 x 240 or something like that not 320 x 240? If it won't be a straight 2x2 duplication with very light filtering what will it be?
 
Last edited by a moderator:
DaveC said:
I thought PC-engine was 256 x 240 or something like that not 320 x 240? If it won't be a straight 2x2 duplication with very light filtering what will it be?

Really this explanation should make it as easy as possible for you - you're familiar with what Temper does on GP2X and Wiz. It's designed for a 320x240 display. On Pandora I'm giving it a 320x240 display that's scaled to 640x480 (using filtering) and centered. PC-Engine games are usually (not always) 256x240 - so normally they will take up a 256x240 part of that window, unless you set soft horizontal scaling like in the Wiz version. So an effective resolution space of 512x480 on the Pandora. Like I said, this will be almost exactly like on GP2X and Wiz at first; I'll considering adding options for hardware horizontal scaling (going from 256x240, 320x240, 341x240, 512x240 et al to 640x480) and to do the 256->640 scaling in software instead of 256->320 + 320->640 in hardware. I hope this clarifies everything.
 
Last edited by a moderator:
DaveC said:
Iorgy77 said:
I want to see the whole game, not bits cut off so it can look sharp.
That is why it should have options, not all parts of the world were on the PAL standard.

And for NTSC games it will look sharp AND display the whole game without the fractional stretch..

Of course it should be an option, I am not the one who throws a sissy fit everytime someone requests some form of a scaling option. As John4P has stated there are many PAL games that wouldnt be fully displayed on an amiga emulator without the option to scale and an NTSC version may not exist.
 
Last edited by a moderator:
Exophase said:
DaveC said:
I thought PC-engine was 256 x 240 or something like that not 320 x 240? If it won't be a straight 2x2 duplication with very light filtering what will it be?

Really this explanation should make it as easy as possible for you - you're familiar with what Temper does on GP2X and Wiz. It's designed for a 320x240 display. On Pandora I'm giving it a 320x240 display that's scaled to 640x480 (using filtering) and centered. PC-Engine games are usually (not always) 256x240 - so normally they will take up a 256x240 part of that window, unless you set soft horizontal scaling like in the Wiz version. So an effective resolution space of 512x480 on the Pandora. Like I said, this will be almost exactly like on GP2X and Wiz at first; I'll considering adding options for hardware horizontal scaling (going from 256x240, 320x240, 341x240, 512x240 et al to 640x480) and to do the 256->640 scaling in software instead of 256->320 + 320->640 in hardware. I hope this clarifies everything.
Ok thanks for the explanation.

Do you think that phosphor thing could be done on the Pandora or is that to CPU heavy? I know you would probably know what kind of a hit that code would give. Maybe possible for arcade games or something (MAME)?
 
Last edited by a moderator:
DaveC said:
Ok thanks for the explanation.

Do you think that phosphor thing could be done on the Pandora or is that to CPU heavy? I know you would probably know what kind of a hit that code would give. Maybe possible for arcade games or something (MAME)?

I don't know, I don't know what the algorithm is. If it's a big CPU hit it can probably be offloaded to the DSP instead but Pandora is not ready for DSP coding yet.
 
Last edited by a moderator:
That phosphor-2x really does interest me. But I couldn't find anything about that on google...
Anyone got a nice link for me?
 
jamppa said:
EvilDragon said:
That phosphor-2x really does interest me. But I couldn't find anything about that on google...
Anyone got a nice link for me?
http://board.byuu.org/viewtopic.php?p=3457#p3457
It's probably far too CPU-intensive, but someone on that thread talked about having written a DirectX shader version, so maybe something like it could be written to run on the SGX. I hope. :p
 
Last edited by a moderator:
Tom` said:
It's probably far too CPU-intensive, but someone on that thread talked about having written a DirectX shader version, so maybe something like it could be written to run on the SGX. I hope. :p

Okay, but just remember, even texture streaming on the SGX has been shown to come with a performance penalty, right now.
 
Last edited by a moderator:
greendots said:
Does the OMAP's image signal processor have any usefulness here?

No, short of using the DSP to do it in software (which should allow you to do a lot, but someone still has to code it)

IVA2.2 consists only of the DSP, memory, video hardware acceleration functions, and DMA controller.

If you're looking for hardware functions for performing a generic scaling blit I think you'll come up short. SGX can do it, but only within the context of scene rendering.
 
Last edited by a moderator:
Whoa! This actually looks so amazing!
Has anyone tried how much CPU power it uses? Would love to play old TV games (or Arcade machines :D) like this :eek:
 
Eventually we should have a unified scaler library using the DSP then I think... I will have to try to get dsp-bridge working and see how much assembly I remember :)
 
greendots said:
Eventually we should have a unified scaler library using the DSP then I think... I will have to try to get dsp-bridge working and see how much assembly I remember :)

Just use TI's compiler... or if you must use "linear assembly" and the optimizing assembler. Coding in straight C6x assembly is difficult (more difficult than usual assembly languages) because you have to track the status of the writebacks in order to know when it's okay to read from them in dependent operations, and you have to schedule up to 8 execution units.
 
Last edited by a moderator:
I had not looked into it much yet so thanks :) I've only done some basic x86 stuff so I would be better off in a Higher language anyway.

The mainline kernel should be all thats needed since wifi and the gpu aren't needed here so anyone with a pandora should be able to start right away (if interested that is). My pandora is a week or two away since I'm still waiting for a reply from Craig :/
 
greendots said:
I will have to try to get dsp-bridge working
Why not dsplink or dspgateway? Maybe you know which is best to use in our case and can tell us, as I have no clue.
 
Last edited by a moderator:
Back
Top