Graphics don't seem right

Tramboi · Post by **Tramboi** » Sun Dec 16, 2007 3:37 pm

Hi Robin,

the new version doesn't work (some columns are fucked up) but it is indeed faster (10.5ms) so I'll try to fix it, or re-unroll it from scratch, it looks worth it!

But first I'm gonna investigate the debug console.

agentq · Post by **agentq** » Sun Dec 16, 2007 5:34 pm

Don't worry about the debug console, I've fixed it, as well as the screen corruption when you switch the scaler on and off in non scumm games.

Tramboi · Post by **Tramboi** » Sun Dec 16, 2007 6:22 pm

Great!

I have to admit I was actually scratching my head about the VRAM allocation stuff...

robinwatts · Post by **robinwatts** » Mon Dec 17, 2007 10:55 am

Tramboi wrote:the new version doesn't work (some columns are fucked up) but it is indeed faster (10.5ms) so I'll try to fix it, or re-unroll it from scratch, it looks worth it!

I'll try and look over the code again later to see where I've messed up.

Ta,

Robin

robinwatts · Post by **robinwatts** » Mon Dec 17, 2007 11:29 am

robinwatts wrote:I'll try and look over the code again later to see where I've messed up.

New version in the same place with at least 1 column fixed.

Robin

Tramboi · Post by **Tramboi** » Tue Dec 18, 2007 9:56 pm

One column is still garbage

By the way when you STMFD a new register at the beginning, think about offsetting r9 in
LDR r9, [r13,#9*4] @ r9 = palette

I don't have too much time to check it though so hopefully you'll find it by rereading the code

robinwatts · Post by **robinwatts** » Wed Dec 19, 2007 1:07 am

Tramboi wrote:One column is still garbage

By the way when you STMFD a new register at the beginning, think about offsetting r9 in
LDR r9, [r13,#9*4] @ r9 = palette

I don't have too much time to check it though so hopefully you'll find it by rereading the code

New version in the usual place. Should fix an error in 1 in every 4 columns, and incorporates your offset fix above - thanks for that.

Thanks for trying this stuff out - I don't have an NDS to test on. I certainly don't expect you to debug my code for me - but your efforts so far have been brilliant!

Hopefully this should be sorted now, but if it still goes wrong, it'd be nice to know how many columns are broken (1 out of 4 say), and even, if you can tell by looking at the screen, which ones are broken...

Thanks,

Robin

fingolfin · Post by **fingolfin** » Wed Dec 19, 2007 10:22 am

Hi folks, just noticed this thread, interesting to read.

Regarding dirty rectangles: I recommend to first concentrate on making the fullscreen blitter as fast as possible. Reason: Many games (e.g. COMI, Dig, FT, and various non-SCUMM games) unfortunately make little to no effort to do "small" blits, they just do full screen blits all the time. OK, those three SCUMM games might be out of the league anyway, but still for non-SCUMM games, you may have to use a fast fullscreen blitter.

Also, we've been offering a "framebuffer" API for the engines for some time now, and that requires full screen updates, too. The reason for that API, btw (as was explained on a scummvm-devel post at some point) is/was that in many cases, what takes most time is several stages of scaling/blitting etc. on various backends. Those backends get a better speedup if they just "manually" compare which pixels changed, and then only blit those. But I guess that is out of question for the NDS...

It's difficult to design a graphics API which can be optimized for several backends, I am afraid :-/. Suggestions are always welcome, though. Speed is no issue on the desktop, but we must accommodate the NDS, PSP, Symbian/Palm/WinCE devices and others.

BTW, anybody who knows a good MIPS code (PSP), send 'em over

.

Tramboi · Post by **Tramboi** » Wed Dec 19, 2007 10:45 am

fingolfin wrote:Hi folks, just noticed this thread, interesting to read.

Regarding dirty rectangles: I recommend to first concentrate on making the fullscreen blitter as fast as possible. Reason: Many games (e.g. COMI, Dig, FT, and various non-SCUMM games) unfortunately make little to no effort to do "small" blits, they just do full screen blits all the time. OK, those three SCUMM games might be out of the league anyway, but still for non-SCUMM games, you may have to use a fast fullscreen blitter.

Also, we've been offering a "framebuffer" API for the engines for some time now, and that requires full screen updates, too. The reason for that API, btw (as was explained on a scummvm-devel post at some point) is/was that in many cases, what takes most time is several stages of scaling/blitting etc. on various backends. Those backends get a better speedup if they just "manually" compare which pixels changed, and then only blit those. But I guess that is out of question for the NDS...

It's difficult to design a graphics API which can be optimized for several backends, I am afraid :-/. Suggestions are always welcome, though. Speed is no issue on the desktop, but we must accommodate the NDS, PSP, Symbian/Palm/WinCE devices and others.

That's my idea about the thingy Max : optimize the worst case first

And that's right, abstracting so many hardwares is just bound to need tradeoffs on some platforms. Let's just live with it!

fingolfin wrote:BTW, anybody who knows a good MIPS code (PSP), send 'em over .

A good code for what? A PSP scaler?
I don't know if the PSP is really similar to the PS2, but if so there is certainly something to be done using the VU0, double buffering, and the asynchronous DMAs!

agentq · Post by **agentq** » Wed Dec 19, 2007 9:49 pm

Also, we've been offering a "framebuffer" API for the engines for some time now, and that requires full screen updates, too. The reason for that API, btw (as was explained on a scummvm-devel post at some point) is/was that in many cases, what takes most time is several stages of scaling/blitting etc. on various backends. Those backends get a better speedup if they just "manually" compare which pixels changed, and then only blit those. But I guess that is out of question for the NDS...

I find it difficult to believe that manually comparing two frames is efficient on any platform. The scaler would have to be pretty slow to benefit from this.

On the DS, the old dirty rectangle API was far superior to the new API, and many of the games run slower than they did. Admittedly, there were a lot of games that did a whole full screen blit anyway, and those are no worse. But in my opinion, we should be moving those games towards dirty rectangles, and only using the new framebuffer api for those games that really need it (like for scrolling sections).

[/quote]

fingolfin · Post by **fingolfin** » Thu Dec 20, 2007 8:57 am

agentq wrote:I find it difficult to believe that manually comparing two frames is efficient on any platform. The scaler would have to be pretty slow to benefit from this.

But it is so -- think of the case where you just did a palette rotation (thus, dirtying the whole screen), and are using the (veeeery slow) hq2x scaler, plus aspect ratio correction, and you can get huge boosts if the palette rotation only affected small portions of the screen.

I was skeptical, too, but I know several emulators which implement this technique for a major speed boost. Of course on a low end platform with slow memory and a small cache, it will be bad. And if you only have one stage, because you combine scaling+ASR+rotation into a single function, *and* you have a quick scaler like AdvMame2x, then you don't want to do this.

agentq wrote: On the DS, the old dirty rectangle API was far superior to the new API, and many of the games run slower than they did. Admittedly, there were a lot of games that did a whole full screen blit anyway, and those are no worse. But in my opinion, we should be moving those games towards dirty rectangles, and only using the new framebuffer api for those games that really need it (like for scrolling sections).

In many cases, dirty rectangles are just not possible. At least not without major changes to the involved engines. And with palette rotation, you will still have to check the whole screen, unless you happen to run on a device which has 8bit color as its native mode anyway.