2012-04-03 23:50:40 +00:00
|
|
|
void PPU::render_backgrounds() {
|
2012-04-07 08:17:49 +00:00
|
|
|
switch(regs.control.bgmode) {
|
|
|
|
|
case 0:
|
Update to v087r22 release.
byuu says:
Changelog:
- fixed below pixel green channel on color blending
- added semi-transparent objects [Exophase's method]
- added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable)
- EEPROM uses nall::bitarray now to be friendlier to saving memory to disk
- removed incomplete mosaic support for now (too broken, untested)
- improved sprite priority. Hopefully it's right now.
Just about everything should look great now. It took 25 days, but we
finally have the BIOS rendering correctly.
In order to do OBJ windows, I had to drop my above/below buffers
entirely. I went with the nuclear option. There's separate layers for
all BGs and objects. I build the OBJ window table during object
rendering. So as a result, after rendering I go back and apply windows
(and the object window that now exists.) After that, I have to do
a painful Z-buffer select of the top two most important pixels. Since
I now know the layers, the blending enable tests are a lot nicer, at
least. But this obviously has quite a speed hit: 390fps to 325fps for
Mr. Driller 2 title screen.
TONC says that "bad" window coordinates do really insane things. GBAtek
says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240
? 240 : x2; I like the GBAtek version more, so I went with that. I sure
hope it's right ... but my guess is the hardware does this with
a counter that wraps around or something. Also, say you have two OBJ
mode 2 sprites that overlap each other, but with different priorities.
The lower (more important) priority sprite has a clear pixel, but the
higher priority sprite has a set pixel. Do we set the "inside OBJ
window" flag to true here? Eg does the value OR, or does it hold the
most important sprite's pixel value? Cydrak suspects it's OR-based,
I concur from what I can see.
Mosaic, I am at a loss. I really need a lot more information in order to
implement it. For backgrounds, does it apply to the Vcounter of the
entire screen? Or does it apply post-scroll? Or does it even apply after
every adjust in affine/bitmap modes? I'm betting the hcounter
background mosaic starts at the leftmost edge of the screen, and repeats
previous pixels to apply the effect. Like SNES, very simple. For
sprites, the SNES didn't have this. Does the mosaic grid start at (0,0)
of the screen, or at (0,0) of each sprite? The latter will look a lot
nicer, but be a lot more complex. Is mosaic on affine objects any
different than mosaic of linear(tiled) objects?
With that out of the way, we still have to fix the CPU memory access
timing, add the rest of the CPU penalty cycles, the memory rotation
/ alignment / extend behavior needs to be fixed, the shifter desperately
needs to be moved from loops to single shift operations, and I need to
add flash memory support.
2012-04-13 11:49:32 +00:00
|
|
|
render_background_linear(regs.bg[3]);
|
|
|
|
|
render_background_linear(regs.bg[2]);
|
|
|
|
|
render_background_linear(regs.bg[1]);
|
|
|
|
|
render_background_linear(regs.bg[0]);
|
2012-04-07 08:17:49 +00:00
|
|
|
break;
|
|
|
|
|
case 1:
|
Update to v087r22 release.
byuu says:
Changelog:
- fixed below pixel green channel on color blending
- added semi-transparent objects [Exophase's method]
- added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable)
- EEPROM uses nall::bitarray now to be friendlier to saving memory to disk
- removed incomplete mosaic support for now (too broken, untested)
- improved sprite priority. Hopefully it's right now.
Just about everything should look great now. It took 25 days, but we
finally have the BIOS rendering correctly.
In order to do OBJ windows, I had to drop my above/below buffers
entirely. I went with the nuclear option. There's separate layers for
all BGs and objects. I build the OBJ window table during object
rendering. So as a result, after rendering I go back and apply windows
(and the object window that now exists.) After that, I have to do
a painful Z-buffer select of the top two most important pixels. Since
I now know the layers, the blending enable tests are a lot nicer, at
least. But this obviously has quite a speed hit: 390fps to 325fps for
Mr. Driller 2 title screen.
TONC says that "bad" window coordinates do really insane things. GBAtek
says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240
? 240 : x2; I like the GBAtek version more, so I went with that. I sure
hope it's right ... but my guess is the hardware does this with
a counter that wraps around or something. Also, say you have two OBJ
mode 2 sprites that overlap each other, but with different priorities.
The lower (more important) priority sprite has a clear pixel, but the
higher priority sprite has a set pixel. Do we set the "inside OBJ
window" flag to true here? Eg does the value OR, or does it hold the
most important sprite's pixel value? Cydrak suspects it's OR-based,
I concur from what I can see.
Mosaic, I am at a loss. I really need a lot more information in order to
implement it. For backgrounds, does it apply to the Vcounter of the
entire screen? Or does it apply post-scroll? Or does it even apply after
every adjust in affine/bitmap modes? I'm betting the hcounter
background mosaic starts at the leftmost edge of the screen, and repeats
previous pixels to apply the effect. Like SNES, very simple. For
sprites, the SNES didn't have this. Does the mosaic grid start at (0,0)
of the screen, or at (0,0) of each sprite? The latter will look a lot
nicer, but be a lot more complex. Is mosaic on affine objects any
different than mosaic of linear(tiled) objects?
With that out of the way, we still have to fix the CPU memory access
timing, add the rest of the CPU penalty cycles, the memory rotation
/ alignment / extend behavior needs to be fixed, the shifter desperately
needs to be moved from loops to single shift operations, and I need to
add flash memory support.
2012-04-13 11:49:32 +00:00
|
|
|
render_background_affine(regs.bg[2]);
|
|
|
|
|
render_background_linear(regs.bg[1]);
|
|
|
|
|
render_background_linear(regs.bg[0]);
|
2012-04-07 08:17:49 +00:00
|
|
|
break;
|
|
|
|
|
case 2:
|
Update to v087r22 release.
byuu says:
Changelog:
- fixed below pixel green channel on color blending
- added semi-transparent objects [Exophase's method]
- added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable)
- EEPROM uses nall::bitarray now to be friendlier to saving memory to disk
- removed incomplete mosaic support for now (too broken, untested)
- improved sprite priority. Hopefully it's right now.
Just about everything should look great now. It took 25 days, but we
finally have the BIOS rendering correctly.
In order to do OBJ windows, I had to drop my above/below buffers
entirely. I went with the nuclear option. There's separate layers for
all BGs and objects. I build the OBJ window table during object
rendering. So as a result, after rendering I go back and apply windows
(and the object window that now exists.) After that, I have to do
a painful Z-buffer select of the top two most important pixels. Since
I now know the layers, the blending enable tests are a lot nicer, at
least. But this obviously has quite a speed hit: 390fps to 325fps for
Mr. Driller 2 title screen.
TONC says that "bad" window coordinates do really insane things. GBAtek
says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240
? 240 : x2; I like the GBAtek version more, so I went with that. I sure
hope it's right ... but my guess is the hardware does this with
a counter that wraps around or something. Also, say you have two OBJ
mode 2 sprites that overlap each other, but with different priorities.
The lower (more important) priority sprite has a clear pixel, but the
higher priority sprite has a set pixel. Do we set the "inside OBJ
window" flag to true here? Eg does the value OR, or does it hold the
most important sprite's pixel value? Cydrak suspects it's OR-based,
I concur from what I can see.
Mosaic, I am at a loss. I really need a lot more information in order to
implement it. For backgrounds, does it apply to the Vcounter of the
entire screen? Or does it apply post-scroll? Or does it even apply after
every adjust in affine/bitmap modes? I'm betting the hcounter
background mosaic starts at the leftmost edge of the screen, and repeats
previous pixels to apply the effect. Like SNES, very simple. For
sprites, the SNES didn't have this. Does the mosaic grid start at (0,0)
of the screen, or at (0,0) of each sprite? The latter will look a lot
nicer, but be a lot more complex. Is mosaic on affine objects any
different than mosaic of linear(tiled) objects?
With that out of the way, we still have to fix the CPU memory access
timing, add the rest of the CPU penalty cycles, the memory rotation
/ alignment / extend behavior needs to be fixed, the shifter desperately
needs to be moved from loops to single shift operations, and I need to
add flash memory support.
2012-04-13 11:49:32 +00:00
|
|
|
render_background_affine(regs.bg[3]);
|
|
|
|
|
render_background_affine(regs.bg[2]);
|
2012-04-07 08:17:49 +00:00
|
|
|
break;
|
|
|
|
|
case 3: case 4: case 5:
|
Update to v087r22 release.
byuu says:
Changelog:
- fixed below pixel green channel on color blending
- added semi-transparent objects [Exophase's method]
- added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable)
- EEPROM uses nall::bitarray now to be friendlier to saving memory to disk
- removed incomplete mosaic support for now (too broken, untested)
- improved sprite priority. Hopefully it's right now.
Just about everything should look great now. It took 25 days, but we
finally have the BIOS rendering correctly.
In order to do OBJ windows, I had to drop my above/below buffers
entirely. I went with the nuclear option. There's separate layers for
all BGs and objects. I build the OBJ window table during object
rendering. So as a result, after rendering I go back and apply windows
(and the object window that now exists.) After that, I have to do
a painful Z-buffer select of the top two most important pixels. Since
I now know the layers, the blending enable tests are a lot nicer, at
least. But this obviously has quite a speed hit: 390fps to 325fps for
Mr. Driller 2 title screen.
TONC says that "bad" window coordinates do really insane things. GBAtek
says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240
? 240 : x2; I like the GBAtek version more, so I went with that. I sure
hope it's right ... but my guess is the hardware does this with
a counter that wraps around or something. Also, say you have two OBJ
mode 2 sprites that overlap each other, but with different priorities.
The lower (more important) priority sprite has a clear pixel, but the
higher priority sprite has a set pixel. Do we set the "inside OBJ
window" flag to true here? Eg does the value OR, or does it hold the
most important sprite's pixel value? Cydrak suspects it's OR-based,
I concur from what I can see.
Mosaic, I am at a loss. I really need a lot more information in order to
implement it. For backgrounds, does it apply to the Vcounter of the
entire screen? Or does it apply post-scroll? Or does it even apply after
every adjust in affine/bitmap modes? I'm betting the hcounter
background mosaic starts at the leftmost edge of the screen, and repeats
previous pixels to apply the effect. Like SNES, very simple. For
sprites, the SNES didn't have this. Does the mosaic grid start at (0,0)
of the screen, or at (0,0) of each sprite? The latter will look a lot
nicer, but be a lot more complex. Is mosaic on affine objects any
different than mosaic of linear(tiled) objects?
With that out of the way, we still have to fix the CPU memory access
timing, add the rest of the CPU penalty cycles, the memory rotation
/ alignment / extend behavior needs to be fixed, the shifter desperately
needs to be moved from loops to single shift operations, and I need to
add flash memory support.
2012-04-13 11:49:32 +00:00
|
|
|
render_background_bitmap(regs.bg[2]);
|
2012-04-07 08:17:49 +00:00
|
|
|
break;
|
2012-04-03 23:50:40 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Update to v087r22 release.
byuu says:
Changelog:
- fixed below pixel green channel on color blending
- added semi-transparent objects [Exophase's method]
- added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable)
- EEPROM uses nall::bitarray now to be friendlier to saving memory to disk
- removed incomplete mosaic support for now (too broken, untested)
- improved sprite priority. Hopefully it's right now.
Just about everything should look great now. It took 25 days, but we
finally have the BIOS rendering correctly.
In order to do OBJ windows, I had to drop my above/below buffers
entirely. I went with the nuclear option. There's separate layers for
all BGs and objects. I build the OBJ window table during object
rendering. So as a result, after rendering I go back and apply windows
(and the object window that now exists.) After that, I have to do
a painful Z-buffer select of the top two most important pixels. Since
I now know the layers, the blending enable tests are a lot nicer, at
least. But this obviously has quite a speed hit: 390fps to 325fps for
Mr. Driller 2 title screen.
TONC says that "bad" window coordinates do really insane things. GBAtek
says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240
? 240 : x2; I like the GBAtek version more, so I went with that. I sure
hope it's right ... but my guess is the hardware does this with
a counter that wraps around or something. Also, say you have two OBJ
mode 2 sprites that overlap each other, but with different priorities.
The lower (more important) priority sprite has a clear pixel, but the
higher priority sprite has a set pixel. Do we set the "inside OBJ
window" flag to true here? Eg does the value OR, or does it hold the
most important sprite's pixel value? Cydrak suspects it's OR-based,
I concur from what I can see.
Mosaic, I am at a loss. I really need a lot more information in order to
implement it. For backgrounds, does it apply to the Vcounter of the
entire screen? Or does it apply post-scroll? Or does it even apply after
every adjust in affine/bitmap modes? I'm betting the hcounter
background mosaic starts at the leftmost edge of the screen, and repeats
previous pixels to apply the effect. Like SNES, very simple. For
sprites, the SNES didn't have this. Does the mosaic grid start at (0,0)
of the screen, or at (0,0) of each sprite? The latter will look a lot
nicer, but be a lot more complex. Is mosaic on affine objects any
different than mosaic of linear(tiled) objects?
With that out of the way, we still have to fix the CPU memory access
timing, add the rest of the CPU penalty cycles, the memory rotation
/ alignment / extend behavior needs to be fixed, the shifter desperately
needs to be moved from loops to single shift operations, and I need to
add flash memory support.
2012-04-13 11:49:32 +00:00
|
|
|
void PPU::render_background_linear(Registers::Background &bg) {
|
|
|
|
|
if(regs.control.enable[bg.id] == false) return;
|
|
|
|
|
auto &output = layer[bg.id];
|
2012-04-07 08:17:49 +00:00
|
|
|
|
2012-04-14 07:26:45 +00:00
|
|
|
if(bg.control.mosaic == false || (regs.vcounter % (1 + regs.mosaic.bgvsize)) == 0) {
|
|
|
|
|
bg.vmosaic = regs.vcounter;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uint9 voffset = bg.vmosaic + bg.voffset;
|
2012-04-03 23:50:40 +00:00
|
|
|
uint9 hoffset = bg.hoffset;
|
|
|
|
|
|
|
|
|
|
unsigned basemap = bg.control.screenbaseblock << 11;
|
|
|
|
|
unsigned basechr = bg.control.characterbaseblock << 14;
|
|
|
|
|
unsigned px = hoffset & 7, py = voffset & 7;
|
|
|
|
|
|
|
|
|
|
Tile tile;
|
|
|
|
|
uint8 data[8];
|
|
|
|
|
|
|
|
|
|
for(unsigned x = 0; x < 240; x++) {
|
|
|
|
|
if(x == 0 || px & 8) {
|
|
|
|
|
px &= 7;
|
|
|
|
|
|
|
|
|
|
unsigned tx = hoffset / 8, ty = voffset / 8;
|
|
|
|
|
unsigned offset = (ty & 31) * 32 + (tx & 31);
|
|
|
|
|
if(bg.control.screensize & 1) if(tx & 32) offset += 32 * 32;
|
|
|
|
|
if(bg.control.screensize & 2) if(ty & 32) offset += 32 * 32 * (1 + (bg.control.screensize & 1));
|
|
|
|
|
offset = basemap + offset * 2;
|
2012-04-09 06:41:27 +00:00
|
|
|
uint16 mapdata = vram_read(offset, Half);
|
2012-04-03 23:50:40 +00:00
|
|
|
|
|
|
|
|
tile.character = mapdata >> 0;
|
|
|
|
|
tile.hflip = mapdata >> 10;
|
|
|
|
|
tile.vflip = mapdata >> 11;
|
|
|
|
|
tile.palette = mapdata >> 12;
|
|
|
|
|
|
|
|
|
|
if(bg.control.colormode == 0) {
|
|
|
|
|
offset = basechr + tile.character * 32 + (py ^ (tile.vflip ? 7 : 0)) * 4;
|
2012-04-09 06:41:27 +00:00
|
|
|
uint32 word = vram_read(offset, Word);
|
2012-04-03 23:50:40 +00:00
|
|
|
for(unsigned n = 0; n < 8; n++) data[n] = (word >> (n * 4)) & 15;
|
|
|
|
|
} else {
|
|
|
|
|
offset = basechr + tile.character * 64 + (py ^ (tile.vflip ? 7 : 0)) * 8;
|
2012-04-09 06:41:27 +00:00
|
|
|
uint32 wordlo = vram_read(offset + 0, Word);
|
|
|
|
|
uint32 wordhi = vram_read(offset + 4, Word);
|
2012-04-03 23:50:40 +00:00
|
|
|
for(unsigned n = 0; n < 4; n++) data[0 + n] = (wordlo >> (n * 8)) & 255;
|
|
|
|
|
for(unsigned n = 0; n < 4; n++) data[4 + n] = (wordhi >> (n * 8)) & 255;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
hoffset++;
|
|
|
|
|
uint8 color = data[px++ ^ (tile.hflip ? 7 : 0)];
|
|
|
|
|
|
2012-04-07 08:17:49 +00:00
|
|
|
if(color) {
|
Update to v087r28 release.
byuu says:
Be sure to run make install, and move required images to their appropriate system profile folders.
I still have no warnings in place if those images aren't present.
Changelog:
- OBJ mosaic should hopefully be emulated correctly now (thanks to krom
and Cydrak for testing the hardware behavior)
- emulated dummy serial registers, fixes Sonic Advance (you may still
need to specify 512KB FlashROM with an appropriate ID, I used
Panaonic's)
- GBA core exits scheduler (PPU thread) and calls
interface->videoRefresh() from main thread (not required, just nice)
- SRAM, FRAM, EEPROM and FlashROM initialized to 0xFF if it does not
exist (probably not needed, but FlashROM likes to reset to 0xFF
anyway)
- GBA manifest.xml for file-mode will now use "gamename.xml" instead of
"gamename.gba.xml"
- started renaming "NES" to "Famicom" and "SNES" to "Super Famicom" in
the GUI (may or may not change source code in the long-term)
- removed target-libsnes/
- added profile/
Profiles are the major new feature. So far we have:
Famicom.sys/{nothing (yet?)}
Super Famicom.sys/{ipl.rom}
Game Boy.sys/{boot.rom}
Game Boy Color.sys/{boot.rom}
Game Boy Advance.sys/{bios.rom[not included]}
Super Game Boy.sfc/{boot.rom,program.rom[not included]}
BS-X Satellaview.sfc/{program.rom,bsx.ram,bsx.pram}
Sufami Turbo.sfc/{program.rom}
The SGB, BSX and ST cartridges ask you to load GB, BS or ST cartridges
directly now. No slot loader for them. So the obvious downsides: you
can't quickly pick between different SGB BIOSes, but why would you want
to? Just use SGB2/JP. It's still possible, so I'll sacrifice a little
complexity for a rare case to make it a lot easier for the more common
case. ST cartridges currently won't let you load the secondary slot.
BS-X Town cart is the only useful game to load with nothing in the slot,
but only barely, since games are all seeded on flash and not on PSRAM
images. We can revisit a way to boot the BIOS directly if and when we
get the satellite uplink emulated and data can be downloaded onto the
PSRAM :P BS-X slotted cartridges still require the secondary slot.
My plan for BS-X slotted cartridges is to require a manifest.xml to
specify that it has the BS-X slot present. Otherwise, we have to load
the ROM into the SNES cartridge class, and parse its header before we
can find out if it has one. Screw that. If it's in the XML, I can tell
before loading the ROM if I need to present you with an optional slot
loading dialog. I will probably do something similar for Sufami Turbo.
Not all games even work with a secondary slot, so why ask you to load
a second slot for them? Let the XML request a second slot. A complete
Sufami Turbo ROM set will be trivial anyway. Not sure how I want to do
the sub dialog yet. We want basic file loading, but we don't want it to
look like the dialog 'didn't do anything' if it pops back open
immediately again. Maybe change the background color of the dialog to
a darker gray? Tacky, but it'd give you the visual cue without the need
for some subtle text changes.
2012-04-18 13:58:04 +00:00
|
|
|
if(bg.control.colormode == 0) output[x].write(true, bg.control.priority, pram[tile.palette * 16 + color]);
|
|
|
|
|
if(bg.control.colormode == 1) output[x].write(true, bg.control.priority, pram[color]);
|
2012-04-07 08:17:49 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Update to v087r22 release.
byuu says:
Changelog:
- fixed below pixel green channel on color blending
- added semi-transparent objects [Exophase's method]
- added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable)
- EEPROM uses nall::bitarray now to be friendlier to saving memory to disk
- removed incomplete mosaic support for now (too broken, untested)
- improved sprite priority. Hopefully it's right now.
Just about everything should look great now. It took 25 days, but we
finally have the BIOS rendering correctly.
In order to do OBJ windows, I had to drop my above/below buffers
entirely. I went with the nuclear option. There's separate layers for
all BGs and objects. I build the OBJ window table during object
rendering. So as a result, after rendering I go back and apply windows
(and the object window that now exists.) After that, I have to do
a painful Z-buffer select of the top two most important pixels. Since
I now know the layers, the blending enable tests are a lot nicer, at
least. But this obviously has quite a speed hit: 390fps to 325fps for
Mr. Driller 2 title screen.
TONC says that "bad" window coordinates do really insane things. GBAtek
says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240
? 240 : x2; I like the GBAtek version more, so I went with that. I sure
hope it's right ... but my guess is the hardware does this with
a counter that wraps around or something. Also, say you have two OBJ
mode 2 sprites that overlap each other, but with different priorities.
The lower (more important) priority sprite has a clear pixel, but the
higher priority sprite has a set pixel. Do we set the "inside OBJ
window" flag to true here? Eg does the value OR, or does it hold the
most important sprite's pixel value? Cydrak suspects it's OR-based,
I concur from what I can see.
Mosaic, I am at a loss. I really need a lot more information in order to
implement it. For backgrounds, does it apply to the Vcounter of the
entire screen? Or does it apply post-scroll? Or does it even apply after
every adjust in affine/bitmap modes? I'm betting the hcounter
background mosaic starts at the leftmost edge of the screen, and repeats
previous pixels to apply the effect. Like SNES, very simple. For
sprites, the SNES didn't have this. Does the mosaic grid start at (0,0)
of the screen, or at (0,0) of each sprite? The latter will look a lot
nicer, but be a lot more complex. Is mosaic on affine objects any
different than mosaic of linear(tiled) objects?
With that out of the way, we still have to fix the CPU memory access
timing, add the rest of the CPU penalty cycles, the memory rotation
/ alignment / extend behavior needs to be fixed, the shifter desperately
needs to be moved from loops to single shift operations, and I need to
add flash memory support.
2012-04-13 11:49:32 +00:00
|
|
|
void PPU::render_background_affine(Registers::Background &bg) {
|
|
|
|
|
if(regs.control.enable[bg.id] == false) return;
|
|
|
|
|
auto &output = layer[bg.id];
|
2012-04-07 08:17:49 +00:00
|
|
|
|
|
|
|
|
unsigned basemap = bg.control.screenbaseblock << 11;
|
|
|
|
|
unsigned basechr = bg.control.characterbaseblock << 14;
|
|
|
|
|
unsigned screensize = 16 << bg.control.screensize;
|
|
|
|
|
unsigned screenwrap = (1 << (bg.control.affinewrap ? 7 + bg.control.screensize : 20)) - 1;
|
|
|
|
|
|
2012-04-14 07:26:45 +00:00
|
|
|
if(bg.control.mosaic == false || (regs.vcounter % (1 + regs.mosaic.bgvsize)) == 0) {
|
|
|
|
|
bg.hmosaic = bg.lx;
|
|
|
|
|
bg.vmosaic = bg.ly;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int28 fx = bg.hmosaic;
|
|
|
|
|
int28 fy = bg.vmosaic;
|
2012-04-07 08:17:49 +00:00
|
|
|
|
|
|
|
|
for(unsigned x = 0; x < 240; x++) {
|
|
|
|
|
unsigned cx = (fx >> 8) & screenwrap, tx = cx / 8, px = cx & 7;
|
|
|
|
|
unsigned cy = (fy >> 8) & screenwrap, ty = cy / 8, py = cy & 7;
|
|
|
|
|
|
|
|
|
|
if(tx < screensize && ty < screensize) {
|
|
|
|
|
uint8 character = vram[basemap + ty * screensize + tx];
|
|
|
|
|
uint8 color = vram[basechr + (character * 64) + py * 8 + px];
|
Update to v087r28 release.
byuu says:
Be sure to run make install, and move required images to their appropriate system profile folders.
I still have no warnings in place if those images aren't present.
Changelog:
- OBJ mosaic should hopefully be emulated correctly now (thanks to krom
and Cydrak for testing the hardware behavior)
- emulated dummy serial registers, fixes Sonic Advance (you may still
need to specify 512KB FlashROM with an appropriate ID, I used
Panaonic's)
- GBA core exits scheduler (PPU thread) and calls
interface->videoRefresh() from main thread (not required, just nice)
- SRAM, FRAM, EEPROM and FlashROM initialized to 0xFF if it does not
exist (probably not needed, but FlashROM likes to reset to 0xFF
anyway)
- GBA manifest.xml for file-mode will now use "gamename.xml" instead of
"gamename.gba.xml"
- started renaming "NES" to "Famicom" and "SNES" to "Super Famicom" in
the GUI (may or may not change source code in the long-term)
- removed target-libsnes/
- added profile/
Profiles are the major new feature. So far we have:
Famicom.sys/{nothing (yet?)}
Super Famicom.sys/{ipl.rom}
Game Boy.sys/{boot.rom}
Game Boy Color.sys/{boot.rom}
Game Boy Advance.sys/{bios.rom[not included]}
Super Game Boy.sfc/{boot.rom,program.rom[not included]}
BS-X Satellaview.sfc/{program.rom,bsx.ram,bsx.pram}
Sufami Turbo.sfc/{program.rom}
The SGB, BSX and ST cartridges ask you to load GB, BS or ST cartridges
directly now. No slot loader for them. So the obvious downsides: you
can't quickly pick between different SGB BIOSes, but why would you want
to? Just use SGB2/JP. It's still possible, so I'll sacrifice a little
complexity for a rare case to make it a lot easier for the more common
case. ST cartridges currently won't let you load the secondary slot.
BS-X Town cart is the only useful game to load with nothing in the slot,
but only barely, since games are all seeded on flash and not on PSRAM
images. We can revisit a way to boot the BIOS directly if and when we
get the satellite uplink emulated and data can be downloaded onto the
PSRAM :P BS-X slotted cartridges still require the secondary slot.
My plan for BS-X slotted cartridges is to require a manifest.xml to
specify that it has the BS-X slot present. Otherwise, we have to load
the ROM into the SNES cartridge class, and parse its header before we
can find out if it has one. Screw that. If it's in the XML, I can tell
before loading the ROM if I need to present you with an optional slot
loading dialog. I will probably do something similar for Sufami Turbo.
Not all games even work with a secondary slot, so why ask you to load
a second slot for them? Let the XML request a second slot. A complete
Sufami Turbo ROM set will be trivial anyway. Not sure how I want to do
the sub dialog yet. We want basic file loading, but we don't want it to
look like the dialog 'didn't do anything' if it pops back open
immediately again. Maybe change the background color of the dialog to
a darker gray? Tacky, but it'd give you the visual cue without the need
for some subtle text changes.
2012-04-18 13:58:04 +00:00
|
|
|
if(color) output[x].write(true, bg.control.priority, pram[color]);
|
2012-04-07 08:17:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fx += bg.pa;
|
|
|
|
|
fy += bg.pc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bg.lx += bg.pb;
|
|
|
|
|
bg.ly += bg.pd;
|
|
|
|
|
}
|
|
|
|
|
|
Update to v087r22 release.
byuu says:
Changelog:
- fixed below pixel green channel on color blending
- added semi-transparent objects [Exophase's method]
- added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable)
- EEPROM uses nall::bitarray now to be friendlier to saving memory to disk
- removed incomplete mosaic support for now (too broken, untested)
- improved sprite priority. Hopefully it's right now.
Just about everything should look great now. It took 25 days, but we
finally have the BIOS rendering correctly.
In order to do OBJ windows, I had to drop my above/below buffers
entirely. I went with the nuclear option. There's separate layers for
all BGs and objects. I build the OBJ window table during object
rendering. So as a result, after rendering I go back and apply windows
(and the object window that now exists.) After that, I have to do
a painful Z-buffer select of the top two most important pixels. Since
I now know the layers, the blending enable tests are a lot nicer, at
least. But this obviously has quite a speed hit: 390fps to 325fps for
Mr. Driller 2 title screen.
TONC says that "bad" window coordinates do really insane things. GBAtek
says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240
? 240 : x2; I like the GBAtek version more, so I went with that. I sure
hope it's right ... but my guess is the hardware does this with
a counter that wraps around or something. Also, say you have two OBJ
mode 2 sprites that overlap each other, but with different priorities.
The lower (more important) priority sprite has a clear pixel, but the
higher priority sprite has a set pixel. Do we set the "inside OBJ
window" flag to true here? Eg does the value OR, or does it hold the
most important sprite's pixel value? Cydrak suspects it's OR-based,
I concur from what I can see.
Mosaic, I am at a loss. I really need a lot more information in order to
implement it. For backgrounds, does it apply to the Vcounter of the
entire screen? Or does it apply post-scroll? Or does it even apply after
every adjust in affine/bitmap modes? I'm betting the hcounter
background mosaic starts at the leftmost edge of the screen, and repeats
previous pixels to apply the effect. Like SNES, very simple. For
sprites, the SNES didn't have this. Does the mosaic grid start at (0,0)
of the screen, or at (0,0) of each sprite? The latter will look a lot
nicer, but be a lot more complex. Is mosaic on affine objects any
different than mosaic of linear(tiled) objects?
With that out of the way, we still have to fix the CPU memory access
timing, add the rest of the CPU penalty cycles, the memory rotation
/ alignment / extend behavior needs to be fixed, the shifter desperately
needs to be moved from loops to single shift operations, and I need to
add flash memory support.
2012-04-13 11:49:32 +00:00
|
|
|
void PPU::render_background_bitmap(Registers::Background &bg) {
|
|
|
|
|
if(regs.control.enable[bg.id] == false) return;
|
|
|
|
|
auto &output = layer[bg.id];
|
2012-04-07 08:17:49 +00:00
|
|
|
|
|
|
|
|
uint1 depth = regs.control.bgmode != 4; //0 = 8-bit (Mode 4), 1 = 15-bit (Mode 3, Mode 5)
|
|
|
|
|
unsigned basemap = regs.control.bgmode == 3 ? 0 : 0xa000 * regs.control.frame;
|
|
|
|
|
|
|
|
|
|
unsigned width = regs.control.bgmode == 5 ? 160 : 240;
|
|
|
|
|
unsigned height = regs.control.bgmode == 5 ? 128 : 160;
|
|
|
|
|
unsigned size = depth ? Half : Byte;
|
|
|
|
|
|
2012-04-14 07:26:45 +00:00
|
|
|
if(bg.control.mosaic == false || (regs.vcounter % (1 + regs.mosaic.bgvsize)) == 0) {
|
|
|
|
|
bg.hmosaic = bg.lx;
|
|
|
|
|
bg.vmosaic = bg.ly;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
int28 fx = bg.hmosaic;
|
|
|
|
|
int28 fy = bg.vmosaic;
|
2012-04-07 08:17:49 +00:00
|
|
|
|
|
|
|
|
for(unsigned x = 0; x < 240; x++) {
|
|
|
|
|
unsigned px = fx >> 8;
|
|
|
|
|
unsigned py = fy >> 8;
|
|
|
|
|
|
|
|
|
|
if(px < width && py < height) {
|
|
|
|
|
unsigned offset = py * width + px;
|
2012-04-09 06:41:27 +00:00
|
|
|
unsigned color = vram_read(basemap + (offset << depth), size);
|
2012-04-07 08:17:49 +00:00
|
|
|
|
|
|
|
|
if(depth || color) { //8bpp color 0 is transparent; 15bpp color is always opaque
|
2012-04-09 06:41:27 +00:00
|
|
|
if(depth == 0) color = pram[color];
|
2012-04-07 08:17:49 +00:00
|
|
|
if(depth == 1) color = color & 0x7fff;
|
Update to v087r28 release.
byuu says:
Be sure to run make install, and move required images to their appropriate system profile folders.
I still have no warnings in place if those images aren't present.
Changelog:
- OBJ mosaic should hopefully be emulated correctly now (thanks to krom
and Cydrak for testing the hardware behavior)
- emulated dummy serial registers, fixes Sonic Advance (you may still
need to specify 512KB FlashROM with an appropriate ID, I used
Panaonic's)
- GBA core exits scheduler (PPU thread) and calls
interface->videoRefresh() from main thread (not required, just nice)
- SRAM, FRAM, EEPROM and FlashROM initialized to 0xFF if it does not
exist (probably not needed, but FlashROM likes to reset to 0xFF
anyway)
- GBA manifest.xml for file-mode will now use "gamename.xml" instead of
"gamename.gba.xml"
- started renaming "NES" to "Famicom" and "SNES" to "Super Famicom" in
the GUI (may or may not change source code in the long-term)
- removed target-libsnes/
- added profile/
Profiles are the major new feature. So far we have:
Famicom.sys/{nothing (yet?)}
Super Famicom.sys/{ipl.rom}
Game Boy.sys/{boot.rom}
Game Boy Color.sys/{boot.rom}
Game Boy Advance.sys/{bios.rom[not included]}
Super Game Boy.sfc/{boot.rom,program.rom[not included]}
BS-X Satellaview.sfc/{program.rom,bsx.ram,bsx.pram}
Sufami Turbo.sfc/{program.rom}
The SGB, BSX and ST cartridges ask you to load GB, BS or ST cartridges
directly now. No slot loader for them. So the obvious downsides: you
can't quickly pick between different SGB BIOSes, but why would you want
to? Just use SGB2/JP. It's still possible, so I'll sacrifice a little
complexity for a rare case to make it a lot easier for the more common
case. ST cartridges currently won't let you load the secondary slot.
BS-X Town cart is the only useful game to load with nothing in the slot,
but only barely, since games are all seeded on flash and not on PSRAM
images. We can revisit a way to boot the BIOS directly if and when we
get the satellite uplink emulated and data can be downloaded onto the
PSRAM :P BS-X slotted cartridges still require the secondary slot.
My plan for BS-X slotted cartridges is to require a manifest.xml to
specify that it has the BS-X slot present. Otherwise, we have to load
the ROM into the SNES cartridge class, and parse its header before we
can find out if it has one. Screw that. If it's in the XML, I can tell
before loading the ROM if I need to present you with an optional slot
loading dialog. I will probably do something similar for Sufami Turbo.
Not all games even work with a secondary slot, so why ask you to load
a second slot for them? Let the XML request a second slot. A complete
Sufami Turbo ROM set will be trivial anyway. Not sure how I want to do
the sub dialog yet. We want basic file loading, but we don't want it to
look like the dialog 'didn't do anything' if it pops back open
immediately again. Maybe change the background color of the dialog to
a darker gray? Tacky, but it'd give you the visual cue without the need
for some subtle text changes.
2012-04-18 13:58:04 +00:00
|
|
|
output[x].write(true, bg.control.priority, color);
|
2012-04-07 08:17:49 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fx += bg.pa;
|
|
|
|
|
fy += bg.pc;
|
2012-04-03 23:50:40 +00:00
|
|
|
}
|
2012-04-07 08:17:49 +00:00
|
|
|
|
|
|
|
|
bg.lx += bg.pb;
|
|
|
|
|
bg.ly += bg.pd;
|
2012-04-03 23:50:40 +00:00
|
|
|
}
|