+- Dolphin, the GameCube and Wii emulator - Forums (https://forums.dolphin-emu.org)
+-- Forum: Offtopic (https://forums.dolphin-emu.org/Forum-offtopic)
+--- Forum: Delfino Plaza (https://forums.dolphin-emu.org/Forum-delfino-plaza)
+--- Thread: Programming Discussion Thread (/Thread-programming-discussion-thread)
RE: Programming Discussion Thread - mendus - 03-11-2015
Hi all,
@neobrain Did you manage to solve the problem with linear interpolation? I was reading through the thread and couldn't resist posting.
(03-09-2014, 06:48 AM)neobrain Wrote: Does anyone of you happen to be into linear interpolation algorithms?
The GC/Wii GPU provides a feature called color combiners, which essentially linearly interpolates between 3 input values and additionally scales them with some value. I've came across a fancy problem, if anyone of you is bored enough to make sense out of it, look here: http://pastie.org/private/qaohdkaqljvfsnog7xyzgg
Point is, I'm trying to understand how this lerp is implemented specifically so that I can fix Dolphin to use the same algorithm. I don't really get anything about it so far though, unfortunately...
I'm in fact currently running tests against real hardware which check all possible 16777216 inputs, because I don't quite know what else to do with this :/
It seems to me that the stepdowns at places 20h, 60h, A0h and E0h are due to a rounding down. As you notices those values times 4 equal to 80h mod 100h. This is, if after multiplying c by 4 you divide by 100h you will get 0.8h at 0x20 (or analogues) and 0.7C at 0x21 (or analogues). If rounded to the closest integer, one would go up and the other one down hence creating a gap of 3 instead of 4. This suggest the denominator in the formula being 256 (100h).
In order to adapt to it, c should range from 0 to 256. And it seems there is a gap in 0x80. Hence the values of c could be interpreted as follows:
Values 00h - 7Fh correspond to 0-127
Values 80h - FFh correspond to 129-256
Since c indicates how close this number will be to a and b, it does not matter too much "jumping" one color.
Code doing this could go like this:
Code:
int odd_lerp(int a, int b, int c)
{
if (c&0x80) c++; // Take the step for the highest values
int temp = a*(256-c) + b*c;
return ((temp >> 6) + ((temp&0x20)?1:0)&0xFF); // Divide by 256 multiply by 4 and round up or down depending on the most significant byte that was lost.
}Works for the values in the pastebin, if I checked it alright. It will work for the rest of the cases if it is that rounding error that is making the flipper give those results. I am actually doing the same that what was proposed before, except I am handleing the error more generically.
RE: Programming Discussion Thread - tueidj - 03-11-2015
Pretty sure the GC documentation mentions that mapping from 0-255 to 0-256 is accomplished by "out = in + (in>>7)".
RE: Programming Discussion Thread - Shonumi - 03-11-2015
@mendus - Neobrain solved that a while ago here, iirc. Also, welcome to the Dolphin Forums, and the Programming Discussion thread specifically
RE: Programming Discussion Thread - KHRZ - 03-11-2015
OK so now I am trying to use SDL + OpenCL. I am currently rendering a char array of pixels to screen using SDL textures, however I need to move this array over to the GPU with OpenCL. Does anyone have any idea how to make SDL access the array on the GPU to make the texture/render it? Otherwise I'll have to copy it back and forth from the CPU/GPU all the time...
RE: Programming Discussion Thread - mendus - 03-11-2015
(03-11-2015, 02:45 PM)Shonumi Wrote: @mendus - Neobrain solved that a while ago here, iirc. Also, welcome to the Dolphin Forums, and the Programming Discussion thread specifically
Oh, I missed that post
. Well, the issue was old so I expected it to be solved.Cheers.
RE: Programming Discussion Thread - neobrain - 03-11-2015
(03-11-2015, 06:39 AM)mendus Wrote: Hi all,Heh, I didn't expect anyone to ever find that post again :p
@neobrain Did you manage to solve the problem with linear interpolation? I was reading through the thread and couldn't resist posting.
Anyway, in addition to what I said in the post that Shonumi linked to, this is also implemented in Dolphin now, in the WriteTevRegular function at https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoCommon/PixelShaderGen.cpp#L951 . That one is a bit more generic than what I was writing before.
(03-11-2015, 07:10 AM)tueidj Wrote: Pretty sure the GC documentation mentions that mapping from 0-255 to 0-256 is accomplished by "out = in + (in>>7)".That was only (the already known) part of the issue, though.
RE: Programming Discussion Thread - KHRZ - 03-25-2015
More OpenCL questions...
It seems one of my kernels is just crashing everything (including the screen driver). I am assuming the issue is that each thread tries to access the same memory at once (only reading). The problem 2 arrays are xGrid/grid_E is a short array (length 1024) that gets accessed at a random location a few 1000 times by each of 1000 threads. Looks like this:
for (int i=loopStart; i<loopEnd; ++i) {
grid_index = convert_int(x[i]/dx);
grid_index = ID;
Eparticle[i] = grid_E[grid_index]*( (xGrid[grid_index+1]-x[i])/dx ) + grid_E[grid_index+1]*( (x[i]-xGrid[grid_index])/dx ),
}
I am thinking if it could solve the issue to just make 1000 copies of the arrays (will just be 16MB) so each thread has it's own. But I am wondering should this really be neccesary? Since the arrays are marked as "const", shouldn't the GPU cache it in local memory by itself and not access so much globally? (Their memory buffers are however marked READ/WRITE rather than READ ONLY, as some other kernel needs to write to them).
RE: Programming Discussion Thread - Ramoth - 04-08-2015
I've a question. Has GBA got any kind of GPU? GBE+ has things like the CPU, DMA and the APU but not a GPU. By the way do you plan to emulate the solar sensor? I think VBA-M got it recently and so did mgba.
RE: Programming Discussion Thread - pauldacheez - 04-08-2015
I don't think that was VBA-M, it was mgba that got the solar sensor: https://endrift.com/mgba/
The GBA, AFAIK, has a PPU, which is basically a GPU that does only 2D acceleration (sprites n' shit). The SNES and DS have a similar PPU.
RE: Programming Discussion Thread - Shonumi - 04-08-2015
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.