(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.According to GBATEK GBA has LCD Video Controller and DS has two 2D engines which are almost the same as GBA's LCD controller +3D geometry and rendering engines. DS only has specialized chips so calling them GPUs might be a stretch.
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.
Programming Discussion Thread
|
04-13-2015, 03:02 PM
NO WAY! I would've never thought of that! We just do this code here, and compile some stuff there, yep! Totally possible! It's so simple, you're a genius ReZ!!
Arch
Intel Core i7 - 4510U iHD4400 8GB RAM Check here first: wiki.dolphin-emu.org 04-13-2015, 04:26 PM
Snark aside, what is it you're posting about ReZ? Asking about the feasibility of it? Looking for technical information? You aren't asking a question, and I don't see you replying to anyone specific, so I'm a little confused.
Anyway, my GBA emu is coming alone. Sound is mostly finished, but the DMA digital channels need more work down the line. It's not the best audio quality. I think I might need my own mixer. SDL's mixer sound good enough for simple things like square waves and noise though. At any rate, GBE+ is a fully functional emulator that can enjoyably play games from start to finish. There are still a number of games with glaring issues (Mario + Luigi won't start a new game ) but for the most part it's on the right path.
A question about floating point operations across CPUs, as I know Dolphin managed to actually emulate the GC/Wii perfectly in this regard... I'm working on an online game that requires perfect synchronization across differents computers, I heard for Starcraft II they used "fixed point math" to make sure of this, however I also heard all CPUs following IEEE 754 should stay in sync... how did Dolphin handle this? Fixed point math, or does the GC/Wii follow IEEE 754? Can you expect all modern CPUs to follow IEEE 754? Also, the game is in Unity.
Specs: intel i5 3570k @ 3.4GHz;
16Gb RAM; Raedon HD 7900; Win8 64-Bit 04-26-2015, 11:29 PM
(04-26-2015, 11:09 PM)KHRZ Wrote: Can you expect all modern CPUs to follow IEEE 754? Yes. (04-26-2015, 11:09 PM)KHRZ Wrote: how did Dolphin handle this? Fixed point math, or does the GC/Wii follow IEEE 754? If you're interested, Fiora has written about it here: https://www.alchemistowl.org/pocorgtfo/pocorgtfo06.pdf In short, it mostly follows IEEE 754 but has some exceptions, meaning that Dolphin has to add some extra code on top of the native CPU's floating point support in order to be sync-compatible. 04-27-2015, 09:09 AM
IEEE754 is not an exact standard, you can have two machines that both comply with it and give different results.
Shomuni is tile replacement in your GBA emulator already functional and what it can do, is it comparable to let's say hdnes?
05-11-2015, 11:57 PM
Tile replacement work hasn't even started for the GBA. I'm not going to focus on that until I reimplement GB tile replacement and finish what work I started for GBC tile replacement. Currently the plan is 1) to integrate code from the old project into the new one for GB/GBC emulation then 2) write a Qt GUI, 3) go back and work on tile replacement for GB/GBC games then 4) do a 0.1 release.
GBA tile replacement is going to be much more complicated than either the GB/GBC. Given that computing hashes even on a simple game like Kirby's Dreamland could slowdown emulation on my 3.8GHz i5-2500K, GBA work is going to be a monster. I'm thinking of using multi-threading to alleviate some of the hashing stress across multiple cores. It'd be optional but beneficial, and there's no reason not to add it in this day and age. 05-21-2015, 05:42 AM
This thread needs more love :p
Been very busy integrating and tweaking my old code from GBE into GBE+. I've abstracted the cores enough so that GB and GBA games can happily run in the same emulator. GB LCD emulation is getting a total rewrite, and so far it's going good. I actually have a number of games running just fine (without sprites or window emulation) but there's not much to show (it'd be the same stuff I posted here years ago). |
« Next Oldest | Next Newest »
|
Users browsing this thread: 3 Guest(s)