ScummVM DS 0.11.0 beta1 released for testing! [obsolete]

[robinwatts]

AgentQ replied to this in another thread, saying...

No, it's not possible. The software scaler currently implemented scales from 320x200 to 256x200, and uses a large portion of the CPU. This is about as fast as it can be, and it doesn't have to cope with scaling in two directions.

640x480 is four times as much data, not something that's worth attempting, IMO. There's also the problem of fitting all the data into memory. We only have 4Mb of general purpose memory.

Don't forget, the WinCE devices have much more memory and 300Mhz+ CPUs instead of the DSes 66Mhz/33Mhz ones.

Well, I bow to your greater knowledge of the DS, but just before I abandon the idea as unworkable, can you set me straight about the following?

The DS contains, as you say, 4Mb of general purpose memory, but also (AIUI) 512K of VRAM.

512K of VRAM is enough to hold a 640x480x1 byte screen, and 2 256x192 screens (one for the scaled version, and one for palette looked up section of the 640x480 one).

Surely that means that the larger screen can be accomodated without having to dip into general memory?

My limited knowledge in this area gleaned from skimming the DS docs suggests that we can rearrange the 4 128k VRAM banks into 1 large 512k block of memory.

We arrange one 256x192x2 screen to start at offset 0 within this block, and follow it by the 640x480x1 screen. After this we put the last 256x192x2 screen.

This means that each of the 256x192x2 screens would be entirely contained within a single 128K bank of the VRAM, and the 640x480x1 one would be in a single continuous lump, (spanning all 4) making it easy for us to access it.

(It's entirely possible that there are limitations that I don't know about that I've overlooked here - in which case I apologise).

As for speed... the latest version of the CPU scaler takes 10.5ms - that's reading from 320x256 and writing to 255x192.
(Actually, why are we reading from 320x256? Surely for 320x200 games that's 56 lines too many? Maybe we should make the number of lines a parameter? Could save 2ms?)

The 640x480 one would need to read from just under 4 times as much data, and write to the same amount. A very rough estimage would therefore expect that to be around 4 times as slow? (Maybe less, as the storing overhead is the same).

That would suggest a time of 40ms or so. That's still enough to do 25fps isn't it? (ignoring all other factors, which is clearly wrong, but my experience on other ports suggests that the graphics blitting is the highest computational hit)

Even if we really do get a huge slowdown for things like intros (where the number of fps really matters), does this matter as much in actual gameplay?

As I say, I'm not trying to be a clever ass here and claim that I know better than you (cos clearly your experience and work on this port makes you a much better judge of what is possible and what isn't), but I'd like to understand the issues...

Robin

[Tramboi]

(Actually, why are we reading from 320x256? Surely for 320x200 games that's 56 lines too many? Maybe we should make the number of lines a parameter? Could save 2ms?)

In fact we don't

[Ripatius]

I'm having some crashing issues with Day of the Tentacle; I can't get past the cutscene after giving the salad oil to Red Edison as Hoagie with or without the new software scaler so at least it's not to blame. The older version 0.10.0a works without problems.

Hope this helps!

[k0sm1k]

Hi. I get a black screen when loading The Secret of Monkey Island, (worked great with v0.10.0a on a M3 lite SD). MI2 works great. I haven't had time to test other games.
The scaler looks awesome, I'm so glad you put that feature. Thanks

[Roman]

Thanks a lot for the wonderful CPU scaling!
I did'n use ScummVM DS until now because of its ugly scaling, so for me this is more than an update, for me this is the first serious Scummvm DS release. Just tried it with Indy and it's looking perfect!

[patters]

I agree with Roman - without the scaler, the parts where you select dialogue in games were almost illegible. It's a great addition. I have a couple of queries:-

Can you make an option for the secondary screen to display the game in native res? I personally find that the zoomed view isn't much help, but if it was able to show 1:1 and focussing automatically as it currently does, this would be better.

You mention in your earlier post in this thread that the scaler is only scaling horizontally. Would it be too much of a performance hit to add the option of both directions?

Is the reason that the menus in the DS port are still in the older green and black style down to the lack of scaler until now?

Anyway, thanks for all the work you've put into this - it's much appreciated.

[robinwatts]

You mention in your earlier post in this thread that the scaler is only scaling horizontally. Would it be too much of a performance hit to add the option of both directions?

The source screens for currently supported games on the DS are 320x200, which have to be scaled down to fit on a 256x192 screen.

What sort of scaling would you want to see? If we (1) scale to preserve aspect ratio, then we'd squash from being 200 lines high to being 160 lines high; leaving 32 black lines somewhere on the screen (either as black border at the top and/or bottom. The other 160 lines would be blurred versions of the original (as they would have to be weighted combinations of 2 original lines).

If we (2) scale to fill the screen exactly, that'd mean losing a mere 8 lines, but would again mean that all the other lines of the screen became blurred.

So I'm not convinced it would look good, either way. (Experience suggests that blurring latin fonts left/right results in readable text, but the moment you start blurring glyphs vertically they become MUCH harder to read).

As to CPU time... squashing widthways only means the scaler has to read 5 pixels from a scanline and combine them to output 4. A nice localised operation.

To squash vertically (as for (1) ) too would mean we'd have to read 10 source pixels, and combine them to output 4 (reusing 5 on the next line). Unrolling the loop to get us the required speed would mean we'd end up with code at least 4 times as large as currently, that probably runs at best at about half the speed, giving a worse image.

Speeds for (2) would be even worse as the code would need to unroll much further, or would need to read it's weights from a buffer.

It's not something that massively appeals as a use of my coding time... (but of course, I can't speak for the other devs that have done way more than me!)

Robin

[Roman]

Can you make an option for the secondary screen to display the game in native res? I personally find that the zoomed view isn't much help, but if it was able to show 1:1 and focussing automatically as it currently does, this would be better.

I dislike the zoomed top screen too. It doesn't look good, it distracts from the game, it wastes battery life and system performance and it's completely useless. I'd be perfectly happy with the title screen or a box shot of the currently running game, this would be stylish, it wouldn't distract from the game and it would waste less battery life and less performance. It would be useless too but it would have at least some positive effects (improved nostalgia, more style).

[patters]

Hi robinwatts thanks for the comments - always good to know the background. I'd forgotten about aspect ratio as a concern, and I hadn't really considered that it could make the entire image quite a lot more blurred as you say. The "drop certain scanlines" method would be a little messy on the artwork, even if you implemented a flicker method like say PocketNES on the GBA. So I suppose it's probably best left alone, especially if to try and get it done would be a major effort.

I would like that option of having the secondary screen rendered in 1:1 though.

[agentq]

Hi people,

patters:

I would like that option of having the secondary screen rendered in 1:1 though. Smile

You can already do this. Holding L + pressing A and B zooms the screen in and out. It snaps when it gets to an exact 1x and 2x scale.

patters:

The "drop certain scanlines" method would be a little messy on the artwork, even if you implemented a flicker method like say PocketNES on the GBA. So I suppose it's probably best left alone, especially if to try and get it done would be a major effort.

PocketNES style flicker scaling is already implemented on both screens when the software scaler isn't running. If you look carefully and have odd eyes like me you can see it flicker.

It makes text much more legible (compared to not having it), but not anywhere near as good as the software scaler.


Robin:

512K of VRAM is enough to hold a 640x480x1 byte screen, and 2 256x192 screens (one for the scaled version, and one for palette looked up section of the 640x480 one).

Surely that means that the larger screen can be accomodated without having to dip into general memory?

No. The currently ScummVM backends API means that the game engine must be able to retrieve a pointer to the current framebuffer. Since the VRAM doesn't support 8-bit writes (only 16/32 bit ones), a copy must exist in system RAM.

There are other limitations, especially in the way you can split the VRAM between screens.

The current implementation has the zoomed screen using a 512x256 video mode (the modes must be a power of two, so this is the smallest that can fit a 320x240 image). Having the whole buffer in VRAM rather than just a screen-sized chunk means I can scroll and zoom without using any CPU time on the sub screen. You wouldn't want to have to scale and transfer two screens of data, would you?

Two other 128k blocks are used to hold the 512x256x8 image in the main screen, when the scaler is disabled.

When the scaler is enabled, I switch to a 256x256x16 mode, which uses the same amount of RAM.

This leaves one 128k block, which is used for sprites, such as the cursor and other informational icons displayed on top of the game. Only around 32k of this is used, but there are no suitable VRAM blocks that provide 32k that I can use instead. It's possible that I could rejig the sprites to fit into a 16k block and so free up 128k of VRAM, but this wouldn't be enough for a 640x480 screen. Not by a mile.

So the other option would be to do all the scaling in software and then you only need enough VRAM for the final image.

You estimated it would take 40ms to scale a 640x480 screen to 256x192. I think that's a little optimistic, because we would need to scale in two directions, doubling the amount of calculation needed, and then handle four times as much data, so perhaps 60 - 80ms would be my guess. Your ARM wizardry might be able to get it down from that, of course, but that's probably where we'd start from.

Of course, even at 40ms for the scaler, you're forgetting to take account of the amount of time the actual game takes. Parts of Sam & Max, as well as Inherit the Earth, slow down a fair bit with no scaler at all (using my flicker scaling method which runs entirely in hardare and takes no CPU), so we don't really have any overhead without affecting those games.

Then you have to think about the fact that the 640x480 games have four times as much data to push around when blitting their sprites to their internal buffers. All this means that they are unlikely to run well even without the overhead of a scaler.

Then there's the RAM issue. 4Mb of RAM doesn't go far, especially when you take off 1.5Mb or so for the ScummVM binary.

You may have heard about the extra RAM packs which can allow 32Mb more in a plug in module. These are handy, but code must be hand tuned to remove all 8-bit writes, and even then the ram is a lot slower than the internal memory, as it sits on a 16-bit bus at 8Mhz.

So hopefully I've helped you understand the issues involved.

[robinwatts]

Since the VRAM doesn't support 8-bit writes (only 16/32 bit ones), a copy must exist in system RAM.

Ah! That's a biggy that I hadn't realised.

You estimated it would take 40ms to scale a 640x480 screen to 256x192. I think that's a little optimistic, because we would need to scale in two directions, doubling the amount of calculation needed, and then handle four times as much data, so perhaps 60 - 80ms would be my guess. Your ARM wizardry might be able to get it down from that, of course, but that's probably where we'd start from.

I started to play with an implementation of this last night, and I reckon that the 2d scale actually falls out not too badly. But I'll abandon it now, as the points you have made above make it clear that it's useless.

Parts of Sam & Max, as well as Inherit the Earth, slow down a fair bit with no scaler at all (using my flicker scaling method which runs entirely in hardare and takes no CPU), so we don't really have any overhead without affecting those games.

Do you have any tools to do profiling on the NDS? Is there anything left over that could usefully be accelerated?

So hopefully I've helped you understand the issues involved.

You certainly have. Many thanks!

Robin

[patters]

patters:

I would like that option of having the secondary screen rendered in 1:1 though. Smile

You can already do this. Holding L + pressing A and B zooms the screen in and out. It snaps when it gets to an exact 1x and 2x scale.

Thanks. I had seen that in the docs but I had the "force 200%" option set so I thought it wasn't working. All good now...

PocketNES style flicker scaling is already implemented on both screens when the software scaler isn't running. If you look carefully and have odd eyes like me you can see it flicker.

It makes text much more legible (compared to not having it), but not anywhere near as good as the software scaler.

So would it be possible to have an option to scale to 256x192 by using the new horizontal scaler but also using the flicker scaling method in the Y direction (as opposed to the current X)? Or does that still completely mess with the optimizations in the new scaler?

[agentq]

No, scaling 200 to 192 pixels with the flicker scaler would look horrible.

It's only 8 pixels! Just scroll down to see them.

[patters]

ok fair enough.
One suggestion though - can ScummVM be made to remember what zoom level you have set for the second screen between sessions? That would be handy.
Merry Christmas btw!

[Shtroodle]

I'd like to ask if anyone tried to run Amiga version of Waxworks on this build. I know agentq doesn't mention it's supported but I was just curious.

Thanks for reply.