12/21/2023 0 Comments Boxshot ultimate forum![]() (but of course, I can't speak for the other devs that have done way more than me!) It's not something that massively appeals as a use of my coding time. 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. 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. 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). squashing widthways only means the scaler has to read 5 pixels from a scanline and combine them to output 4. (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).Īs to CPU time. So I'm not convinced it would look good, either way. 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. The other 160 lines would be blurred versions of the original (as they would have to be weighted combinations of 2 original lines). 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 source screens for currently supported games on the DS are 320x200, which have to be scaled down to fit on a 256x192 screen. Would it be too much of a performance hit to add the option of both directions? Patters wrote:You mention in your earlier post in this thread that the scaler is only scaling horizontally. 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)Įven 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?Īs 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. A very rough estimage would therefore expect that to be around 4 times as slow? (Maybe less, as the storing overhead is the same). The 640x480 one would need to read from just under 4 times as much data, and write to the same amount. ![]() (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 latest version of the CPU scaler takes 10.5ms - that's reading from 320x256 and writing to 255x192. (It's entirely possible that there are limitations that I don't know about that I've overlooked here - in which case I apologise).Īs for speed. 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. After this we put the last 256x192x2 screen. We arrange one 256x192x2 screen to start at offset 0 within this block, and follow it by the 640x480x1 screen. 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. ![]() Surely that means that the larger screen can be accomodated without having to dip into general memory? The DS contains, as you say, 4Mb of general purpose memory, but also (AIUI) 512K of VRAM.ĥ12K 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). 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? We only have 4Mb of general purpose memory.ĭon't forget, the WinCE devices have much more memory and 300Mhz+ CPUs instead of the DSes 66Mhz/33Mhz ones. There's also the problem of fitting all the data into memory. This is about as fast as it can be, and it doesn't have to cope with scaling in two directions.Ħ40x480 is four times as much data, not something that's worth attempting, IMO. The software scaler currently implemented scales from 320x200 to 256x200, and uses a large portion of the CPU.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |