(04-08-2015, 02:02 PM)Shonumi Wrote: Nintendo never called it a PPU though. That term applies strictly to the NES. I think SNES calls it the S-PPU (3 guesses as to what the "S" stands for...) As for the GBA, most of the hardware logic for processing graphics is actually very close to the CPU (according to Nintendo's own block diagrams), as were other pieces of hardware controlling timers, DMAs, and sound (basically everything that needed to run off of the system clock rate). Final output is transferred to the LCD driver and onto your screen.

The GBA's "enhanced" graphical capabilities were somewhat copy+paste from the SNES, iirc. The special effects on the GBA are comparable to the SNES' color math. The GBA can brighten the entire screen (up to full white), darken the entire screen (down to full black) and it could do alpha blending. It could also rotate and scale certain backgrounds, and any sprite (permitting limitations like only having a max of 32 different scalings/rotations combinations at a time). The scaling and rotation are applied per-scanline, which allowed for developers to emulate the infamous "Mode 7", but it was possible to render 3D things in software using one of the GBA's bitmap modes (the GBA is by no means a slouch). Off the top of my head, V-Rally 3 does this for most of its graphics.

In terms of general graphical capabilities, the GBA and SNES are very similar, though the GBA wins in many places (amount of onscreen sprites per-scanline, much saner tile formats, much larger available BG maps, larger sprites to name a few). It's correct to say that the SNES, GBA, and DS have similar 2D capabilities (the DS 2D engine is a near carbon-copy of the GBA, and the GBA is in many ways modeled after the SNES). Now, as far as I know, the DS does not contain a dedicated GPU. I really don't know what its hardware diagram looks like; I haven't gotten that far in studying the system.

Now, as for the naming conventions in GBE+, the LCD handles emulation of everything related to graphical output. It translates native GBA tiles into pixels on your computer screen. It deals with everything that needs to be drawn. In the original GBE project, I just called it the GPU (the code processed graphics, so why not call the C++ class GPU?) but LCD seems a better fit, and I'm keeping that convention moving forward. APU just stands for audio processing unit. I'm not sure if the sound controllers found in the GB/GBC (or GBA for that matter) constitute an APU, but I'm keeping that convention as well. DMA stands for Direct Memory Access, basically a fast way for processors to copy memory. Like I said, it's a controller on the GBA closely linked to the CPU. I made a separate file because it was easier to manage the code that way.

About the Solar Sensor, yes, I do plan on supporting it. It's not a priority though. It's documented by GBATEK, so it's just a matter of time. I just got sound working (for the most part, to the point where games are enjoyable start-to-finish), so now the focus will gradually turn to integrating GB/GBC support, working on a GUI, and polishing things up for a release. I expect GBA support to have some rough edges, despite all the time I've worked on it (nearly a full year, started April 9th) but that can't be helped. This is a project a throw an odd hour or two a day at, not something I sit down and do marathon 6 hour coding sprees Slowly but surely, one commit at a time.

(04-26-2015, 11:09 PM)KHRZ Wrote: Can you expect all modern CPUs to follow IEEE 754?

(04-26-2015, 11:09 PM)KHRZ Wrote: how did Dolphin handle this? Fixed point math, or does the GC/Wii follow IEEE 754?