I Got Gpsp (gba) Running With Sound!

[Amon_Re]

Maybe it would look better to use the 940 to perform a hq2x scaling and then scale that one down bilinear to fit the screen? hq2x has damn nice results.
http://www.hiend3d.com/hq2x.html
Or better hq3x, then you could just drop evry 2nd pixel to fit the screen.

Wow, nice!

 

[Epicenter]

Running Hq2x over the frame would be a big job even for the 920T to do, and then tack on bilinear scaling and it's far more work-- especially EVERY frame at 60 FPS (even 30 is pushing it.) Also, it's vector-based, and will probably rely heavily on floating point calculations. In short, I'd expect it to tie up a whole processor and be very slow (probably too slow to be useful).

 

[Vimacs]

hq*x isnt that cpu intense, i think the 940 could do it easyly without slowing down the 920 to much.
Let the 920 run everything and write the gba res image somewhere in upper memory, then let the 940 grab scale and blit it, memory overhead shouldn't be to big.
Also you wouldn't need bilinear scaling afterwards, v rs could be evenly devided by 2 and h res as well if you drop every 8th pixel which shouldn't be too noticeable.
You could even use the hw scaler for this job, which would probably do exactly that.

 

[Epicenter]

Scaling without any sort of filtering will completely defeat the purpose of using Hq2x and probably make the result image look pretty terrible. The hardware scaler also does not produce pretty results. I remain confident the 940T won't be up for the task, honestly. Look at Flash, which is entirely vector-based-- even on a modern x86 processor which has superior floating point processing capability and therefore extremely rapid processing of vector-based math, drawing even a simple, small scene uses a remarkable amount of CPU time. It's a very effective visual method but it is a major drain on processing resources in a realtime scenario. Also, a scaling operation of this sort should be extremely memory intensive, and the relevant data to be worked with won't even begin to fit in the 920T's 16kb cache, much less the 940T's 4kb one. The best bet would be for it to happen in the 16.67ms delay between frames on a 60 FPS-operating emulated system. However, since the emulator won't BE running at 60 FPS and the machine will be fighting to produce every frame it can, there won't be any spare CPU time to spend. There'll be slowdown because old frames are being repeated as new ones are drawn-- the source of 'bullet time' style lag, or frames will be skipped to keep a consistent rate of emulation. Either way there won't be the necessary time window for the 940T to have RAM to itself.

 

[Vimacs]

You don't need to filter when you can just drop evry 2nd pixel.
Also interlacing on your tv does the same.

 

[Epicenter]

Such methods work a lot better on analog video handling hardware than digital-- such shortcuts rarely look even close to as nice. You're probably going to be looking at some sort of nearest-neighbor scaling or running it letterboxed for acceptable performance. Getting it close to 60 FPS is going to be a tricky job due to the 2D subsystem anyway-- it's much the same issue as the SNES, there.

The name is going to change, right, Zodttd? I mean, Gpsp?

 

[PokeParadox]

The floats can also be converted to fixed point...

The name is going to change, right, Zodttd? I mean, Gpsp?

it's GP SP as in, GP(2X) (GBA)SP

 

[sam fisher]

The floats can also be converted to fixed point...

And you can also lose a lot of accuracy...

 

[Vimacs]

heres a example of different scaling ways.

original

simple pixel doubleing

hq3x+pixel dropping

 

[PokeParadox]

The floats can also be converted to fixed point...

And you can also lose a lot of accuracy...

I don't think the accuracy lost will be all that significant...

Vimacs: That certainly looks nice!

 

[Vimacs]

yup, hq*x+pixel drop is the only way i found to get decent scaling without ugly blur.

 

[Epicenter]

It looks choppy and strange. Line thicknesses on sprites are non-uniform and inconsistent. Honestly I'd rather have it letterboxed. But if I had to pick some form of scaling it'd be nearest-neighbor with no HQ*x filter, because the framerate loss will just be too dramatic.

 

[Vimacs]

What makes you believe so?
I doubt there would be any bigger fps loss as long as you don't heavily relay on memory bandwidth.
Let your normal program write to some other address instead of the fb address.
Set the hw scaler to scale the fb by 0.5.
Let the 940 grab the image from that address scale it with hq3x and let the blitter write it to the fb address while you process the next frame..
The only fps loss you would get is while you have to wait for a free slot on the mem bus, which shouldn't be a problem for most emulators.

 

[krosfyah]

The floats can also be converted to fixed point...

The name is going to change, right, Zodttd? I mean, Gpsp?

it's GP SP as in, GP(2X) (GBA)SP

Actually, it stands for gameplaySP.

 

[zodttd]

Jumped into this conversation a bit late, but the blitting technique that Vimacs proposed should be able to work. I remember doing something similar with gp2psx when I was using the 940 as a blitter. Back then I was having some trouble, but most the problems I had then can be worked out now. Either way it worked for gp2psx (the problems were due to what I wanted it to do besides blitting), and should work for gpSP if we go that route.

I've used HQ3X in the past, but never seen the "pixel dropping" code alongside it. I'll look into it.

Meanwhile, I cleaned up the code a lot for future use of other ports in the ARM arch. I also am putting in the modifications done by Ryo (thanks Ryo!). I have made things a bit faster, and it looks more "polished" than before.

I (like most other people) am waiting for the next release of gpSP by Exophase. If it's coming soon enough, it'll be merged with the next release of gpSP for the GP2X. That'd be very good news.

It's getting better.

 

[PokeParadox]

I know this idea would be yet more filter overhead but... would it be possible to smooth over those dithered gradients? If you look at the hills in the background of Vimacs screenshots they are dithered, may look nicer if the colours could be smoothed over to remove the staggered pixels.
Such filtering, if possible, would be beneficial to MegaDrive emulation since it uses this type of dithering a lot.

 

[critical]

I was playing with the scaling a few days ago (I too had been looking at this port a few weeks ago). zodttd: SetVideoMode can be called more than once if you're using paeryn's SDL lib.

I've compiled up my latest noodlings here (with source):

http://criticalhippo.googlepages.com/gpsp0...ical_hack_1.zip

There are unscaled, aspect-correct (hopefully) scaled and fullscreen scaled options. No filtering - just the scaling that the SDL port provides for free. I played around with various other bits and pieces to see if I could get any more performance out of it (asm routines from uclinux via mame, mmuhack, etc.) breaking screen centring, and maybe some other stuff into the bargain. Hope some of it might be of use - if nothing else to examine the state of play w.r.t. scaling.

 

[clone]

I know this idea would be yet more filter overhead but... would it be possible to smooth over those dithered gradients? If you look at the hills in the background of Vimacs screenshots they are dithered, may look nicer if the colours could be smoothed over to remove the staggered pixels.
Such filtering, if possible, would be beneficial to MegaDrive emulation since it uses this type of dithering a lot.

Gradient smothing? I know of a filter called gradfun2db http://forum.doom9.org/showthread.php?t=108681 that would achieve the effect you want.... But this is for video filtering. I suppose something like that could be made for the 2x, but such perfection is being a bit ambitious. The overheads would be noticable. What that filter does is identify gradients and smooth them. It's actually made to remove banding, by smoothing out the gradient (burring it and adding noise). It improves the percieved quality by quite a lot, but also kills compressability.

Anyway, I don't think there is any point for implimenting such a thing into this emulator. GBA games don't seem to suffer from limited colour-depth issues much/at all. Whilst any 8bit emulator could benefit from such a filter, in order to kill the overhead it'd have to be applied to the sprites themselves rather than a post-process on the to-be-rendered frame. However, it'd be working with small sprites, so a gradient/dither detection algorithm will have to be strict, otherwise it could easily kill detail.

All in all, I don't think it's viable.

 

[DaveC]

I know this idea would be yet more filter overhead but... would it be possible to smooth over those dithered gradients? If you look at the hills in the background of Vimacs screenshots they are dithered, may look nicer if the colours could be smoothed over to remove the staggered pixels.
Such filtering, if possible, would be beneficial to MegaDrive emulation since it uses this type of dithering a lot.

The problem with that is that it wouldn't know if it is dithering that it is blending or graphics details. So it would blend EVERYTHING not just dither which would result in loss of detail in many places.

heres a example of different scaling ways.

simple pixel doubleing

That image does not show doubling. It is being scaled fractionally. Notice how some pixels are single thickness while others doubled?

Below is actually doubled:

 

[Phil]

I know this idea would be yet more filter overhead but... would it be possible to smooth over those dithered gradients? If you look at the hills in the background of Vimacs screenshots they are dithered, may look nicer if the colours could be smoothed over to remove the staggered pixels.
Such filtering, if possible, would be beneficial to MegaDrive emulation since it uses this type of dithering a lot.

The problem with that is that it wouldn't know if it is dithering that it is blending or graphics details. So it would blend EVERYTHING not just dither which would result in loss of detail in many places.

heres a example of different scaling ways.

simple pixel doubleing
http://img175.imageshack.us/img175/1747/1simplescaletw5.png[/ img]
[/quote]


That image does not show doubling. It is being scaled fractionally. Notice how some pixels are single thickness while others doubled?

Below is actually doubled:
[img]http://www.geocities.com/dcancilier@sbcglobal.net/pixeldouble.png[/ img]
[/quote]
I think What he was trying to show was how it would look on the2x as the resolution of the screen doesn't go that high as the doubled image.