Red/blue channels swapped?

[slembcke]

I think you have an RGB -> BGR channel ordering issue going on with your GL code. I noticed some off colors in a couple games. When I run this Applesoft snippet, I get the following output. All the blues and reds are swapped.

10 for y = 0 to 3
20 for x = 0 to 3
30 color = 4*y + x
40 plot x, y
50 next x
60 next y

This is on Fedora (Wayland) with AMD graphics. I might have time to dig into the code and help debug it, but no promises. >_>

[slembcke]

Oh, I missed this originally, but probably relevant:

[X11] Failed to create OpenGL 3.0 context [X11] ... using old-style GLX context!

[buserror]

Are you using the tip of the tree? here I had several issues, normalized all to BGRA... and realized it was considerably slower than my previous version using RGBA! The Apple II video should now be GL_RGBA -- the MUI interface is GL_BGRA -- so the About box has the proper colors.

The Macro in mii_video.c is HI_RGB(r,g,b) { \ .rgb = (0xff000000 | ((b) << 16) | ((g) << 8) | (r)), \

To match. Here I use xorg, nvidia binary driver. I'm fairly sure this provide the right videos everywhere I tried, honest :-) Also work in double-low-res in the latest versions...

Thanks for trying tho, glad it's not totally borken :-)

[slembcke]

I can double check the commit SHA, but I pulled main right before posting that.

[slembcke]

Ok, so main as of right now is at 2e12a37bceebef3787abddc1ca10d82fdc427e9d unless you have unpushed changes. The code in mii_mui_gl.c is all still using BGRA. Swapping the byte order your HI_RGB() macro or the texture format in mii_mui_gl.c both work just fine as a fix.

As far as "fast" texture formats go in GL, that... ugh always a bit of a dice roll. IIRC, traditionally what happens is that the GPU just uses whatever ordering it wants internally. So the problem comes when the CPU needs to byteswap the textures during upload. Since you do that every frame it can get expensive if there is a format mismatch. I don't know if there is an obvious "right" answer that works with every (or even most) driver/GPU combos in 2024. If it was me I would just use RGBA for everything and be done with it. (shrug)

For what it's worth... There seems to be no measurable performance difference for me on AMD/Mesa for RGBA vs BGRA. I used gamemoderun to disable the CPU governor and the CPU monitor sat at very stable 9% in both cases. Forcing a conversion with mismatched glTexImage2D/glTexSubImage2D formats makes it jump to 10.3%. Not very scientific, I didn't instrument the code or really profile anything, but... (shrug)

[xandark]

I'm building on origin/main and am getting color issues of this otherwise excellent emulator...

I'll also attach the disk I used to generate that. MECC-A240 Computer Inspector v1.0.zip

Operating System: KDE neon 5.27 KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.114.0 Qt Version: 5.15.12 Kernel Version: 6.5.0-21-generic (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 6800H with Radeon Graphics Memory: 14.9 GiB of RAM Graphics Processor: AMD Radeon Graphics (also happens with NVidia discreet chipset)

[buserror]

Thanks for the detailed report! I'm fairly sure this one is nailed in the next version I'll push "soon"! Good program tho, it reports the RPM of the floppy as 292rpm, which isn't good, I wonder why. Perhaps one extra cycle to an instruction somewhere?

[xandark]

Here's another good diagnostic disk you should throw against MII. It is even more comprehensive and I noticed some visual issues.

A2eDiagnostics_v2.1.zip

[slembcke]

Seems to be fixed in 1.8.

[xandark]

Yes, looking good in the new version and I like the spinning disk visualizer, very cool.