I may have spoken too soon.....
Spoiler:
Programming Discussion Thread
|
(01-13-2015, 12:39 PM)Shonumi Wrote: Yeah, I can scale the image "manually" through software. You can basically do anything in software :p The thing is, LCD emulation is currently the biggest bottleneck for GBE+, so manually scaling the screen just eats more CPU time. I have to trim down and optimize LCD emulation first. But software scaling is more of a back-up in case OpenGL is unavailable. There is one GBA emulator that claims to have a hardware rendering https://endrift.com/mgba//2014/12/09/announcing-mgba/, is that a real hardware rendering or just blitting ? Are things like MSAA, SSAA and Anisotropic Filtering possible with software rendering ? I'm asking if it is generally possible , I know MSAA and TF/AF aren't possible with 2D. 01-14-2015, 04:37 AM
(01-14-2015, 12:15 AM)Ramoth Wrote: There is one GBA emulator that claims to have a hardware rendering https://endrift.com/mgba//2014/12/09/announcing-mgba/, is that a real hardware rendering or just blitting ? Are things like MSAA, SSAA and Anisotropic Filtering possible with software rendering ? I'm asking if it is generally possible , I know MSAA and TF/AF aren't possible with 2D. I don't see why not. You could just simulate in software whatever a gpu does in hardware. 01-14-2015, 01:27 PM
Ramoth Wrote:There is one GBA emulator that claims to have a hardware rendering https://endrift.com/mgba//2014/12/09/announcing-mgba/, is that a real hardware rendering or just blitting ? From what I can see, endrift is just using OpenGL for the drawing portion. In 2D systems like the GBA, rendering is the process looking up tiles and then determining what pixel data should be generated from that. OpenGL natively has no way of knowing what to do with the tile data, so you can't pass the data off to OpenGL and expect it to generate an image. You can determine the pixel data yourself first into a buffer, then pass it on to OpenGL to push those pixels to your screen. There's a very important distinction between rendering and drawing. Think of rendering as the computer getting an "idea" of what the final image looks like, but drawing is the computer actually showing you what the image looks like. A lot of people use "rendering" to mean the "drawing" bit, however. Fwiw, it'd be possible to do hardware rendering with something like OpenCL. If you can treat your GPU just like another processor, you could tell it how it's supposed to interpret the GBA's tile data as actual pixel data (rendering) and from there push that image on-screen (drawing). Ramoth Wrote:Are things like MSAA, SSAA and Anisotropic Filtering possible with software rendering ? Of course. With software rendering, you're in control of everything. You're the one that gets to decide the value of each and every last pixel. You're basically unstoppable in this mode (01-14-2015, 01:27 PM)Shonumi Wrote:Ramoth Wrote:Are things like MSAA, SSAA and Anisotropic Filtering possible with software rendering ? Interesting, but if so then why none of an emulators that use only software rendering have such features ? Are you planning to use OpenCL ? 01-15-2015, 01:25 AM
Generally, software rendering is a lot slower than hardware rendering, so making there more to do would make it unplayably slow.
OS: Windows 10 64 bit Professional
CPU: AMD Ryzen 5900X RAM: 48GB GPU: Radeon 7800 XT 01-15-2015, 02:29 AM
Ramoth Wrote:Interesting, but if so then why none of an emulators that use only software rendering have such features ? Are you planning to use OpenCL ? Basically what AON3 said, plus it's just easier and less time consuming to program. I want to check out OpenCL as an option for GBE+'s custom tile replacement. GBE+ needs to create hashes of every tile it encounters so users can dump and replace them, but the hashing process is actually pretty CPU intensive. To put this in perspective, even when hashing tiles from a simple game such as Kirby's Dreamland for the original GB, GBE experienced slowdowns at points where lots of tiles were generated. GB tiles are simple and fast to hash in comparison to many GBA tiles, so the problem only grows. If the GPU could handle all of that hashing, I'd like to optionally offload it from the CPU. Another method is to make GBE+ multithreaded and use different CPU cores for the hashing. I'm leaning more towards a multicore solution however, since that will add the least amount of non-SDL related dependencies to the project. 01-15-2015, 11:32 PM
(01-15-2015, 02:29 AM)Shonumi Wrote:Ramoth Wrote:Interesting, but if so then why none of an emulators that use only software rendering have such features ? Are you planning to use OpenCL ? I am interested about a technical difficulties associated with adding these features to software rendering. The only thing I was able to find about it on Intenet is that for a texture filtering GPU texture fetches have to be emulated in software which is apparently very hard to do so I suspect AA is even harder. 01-16-2015, 12:14 AM
GPUs basically have standard ways of being asked to do common tasks like AF so you don't have to do much to set them up. In software rendering, you'd have to filter the textures to all the required sizes, and then, probably with more difficulty, you'd have to work out which scaled texture best fit the space you were texturing, and stuff.
OS: Windows 10 64 bit Professional
CPU: AMD Ryzen 5900X RAM: 48GB GPU: Radeon 7800 XT (01-16-2015, 12:14 AM)AnyOldName3 Wrote: GPUs basically have standard ways of being asked to do common tasks like AF so you don't have to do much to set them up. In software rendering, you'd have to filter the textures to all the required sizes, and then, probably with more difficulty, you'd have to work out which scaled texture best fit the space you were texturing, and stuff. I see, what about things like MSAA? |
« Next Oldest | Next Newest »
|