You are not logged in.
Hi,
Great job on the latest versions ! Speed-wise and compatibility-wise (only tested my hombrews though ^^) DeSmuME has grown really impressively lately...
I have 2 minor bugs to reports :
1. 16bit sprites don't display correctly. Seems that whereas it should be using the sprite width for the image width in VRAM, it's using 128 pixels (or 256 ?). I recall seeing a registry entry (probably bits 5 and 6 in DISPCNT, not sure though).
The result is the following :
See how the timer/clock looks ? It should be showing only 1 number (vertically, of about 24 pixels tall), not 4 ^^
2. Quick little bug with 16bit textures in ortho mode : looks like the black is removed from the image and set as transparent
On this image, all the smileys should be filled with black instead of transparency
Thanks again for the work you've done on DeSmuME, keep it up guys
Offline
I don't know the exact bug with the 16bit sprites, but I can explain the bug with the 3D. Currently, the 3D core reads from the rendered openGL frame buffer, and uses it's result to layer it with the other backgrounds. The main problem with that implementation, is that if you ONLY read from the openGL framebuffer, you've no direct way to know which pixels were written and which weren't.
As a BIG FAT HACK, instead of using the stencil buffer or the depth buffer as a mask, I just decided that black was worthless So basically, pure black pixels are discarded when using the BG0 as a normal layer. This gives problems with at least one game (Ouendan), and it's an ugly implementation. In the future, I'll use either the depth buffer or the stencil buffer (probably the second) to mask the framebuffer from openGL.
Thanks for the bug report
Offline
Wow, fast answer Thanks for explaining, that's what I thought (without the technical info ^^). I guess it's ok for the vast majority of games (as it's really not a problem here)
As for the 2D Sprites, guess I'll wait some more ^^
Offline
Is that homebrew released ? Because I can check it and fix it if I'm able to do it, and I'll check how much would reading the stencil buffer affect perfomance, so I can fix a bit the 3D core.
Having coded a bit for the DS (just a quake3 bsp renderer), I know how handy is to have a tool to test before hardware, so as much as I can help, I'll do
EDIT: Well, I've already done the implementation using the stencil as a mask, and works perfectly, atleast with the games that gave problems before. It'll (hopefully) committed tomorrow
Offline
Sorry, thought I had given the link :s
Offline