Suggest adding it to title bar of XQEMU window

Currently we don't properly emulate the DVD authentication which means you need a modded kernel ( usually referred to as bios) which does allow you to run copied games.

Here is some more info: http://xboxdevwiki.net/Xbox_Game_Disc

I've also started some work on it but I'm currently not actively working on it.

#           define NV097_SET_TEXTURE_FORMAT_COLOR_LU_IMAGE_DEPTH_Y16_FLOAT 0x31

Affected:

• Backyard Wrestling: Don't Try This at Home: Menu
• Backyard Wrestling 2: There Goes the Neighborhood: When going ingame
• Fireblade: When going ingame

The usb-xbox-gamepad device doesn't really inform the user that it's using the keyboard to emulate a gamepad. For SDL2-based gamepads we use usb-xbox-gamepad-sdl. So, we should probable call the keyboard based one usb-xbox-gamepad-kbd or something. Probably rename xid.c to xid-kbd.c or something as well. Please remember to fix the documentation on xqemu.com after making this change.

Related: #59

We need an official title compatibility list, with known issues, links to videos/screenshots, last tested revision, etc. John GodGame's list is probably a good place to start. Google Sheets might be the easiest, or a JSON file in the repo or something.

This issue happens on the 2.x rebase (commit 5d4058d with two linux-specific patches to fix the GL includes, and comment out glFrameTerminatorGREMEDY.

Main menu as well as the introduction video are completely filled with a solid color: Main menu (probably), Intro video (probably).

The in-game introduction sequence still has the same color instead of black borders:

For reference, this is a video what it is supposed to look like (Reference still)

@JayFoxRox speculated that it might be fog color, although this has not been tested.

hw/xbox/xid.c and xid-sdl.c have a lot in common. Let's factor out the common bits to make things more maintainable.

The timer returns bad values. I remember fixing this in my own code a while ago; but my changes never went upstream.

You can use JayFoxRox/xbox-tools#50 to compare the behaviour to real hardware.

After some period of time (seemingly random, ~2 min, give or take), Halo: CE will lock up when in game. When disabling nvnet, the issue appears to be gone.

Typical frame of Halo:CE multiplayer calls g_malloc0 ~53,419 times! Experimental results suggest noticeable performance improvement.

XQEMU should support emulating multiple Xbox controllers. SDL2 is a convenient abstraction layer for this (so users can use many different kinds of devices).

For macOS I've just tried installing this driver (v0.16.5), connecting an Xbox 360 wireless gaming receiver, and pairing an Xbox 360 controller. The driver detects the controller and SDL2 is able to pick it up using this demo code without any additional configuration. Unfortunately this driver does not correctly handle my Xbox Controller S when connecting it so I was unable to test it.

Running 5d4058d ; the right half of the display is broken in this screenshot:

(Screenshot provided by @DarkGabbz)

This is due to broken window clipping (which was merged in a premature state).
Even if it's not actually a regression, it will be observed as one in most applications (as window clipping usually contributes little, but can break a lot).

I believe this issue is due to anti-aliasing in combination with the clipping; which was never tested.

As the actual clipping uses OpenGL pixel coordinates, it has to respect anti-aliasing (which it currently doesn't). So these uniforms need pgraph_apply_anti_aliasing_factor.

The independence of the clipping optimization (which only scans for redundant regions) and implementation / uniform upload (which does clipping) should also be made more clear in the source code, by adding a comment near the optimization loop.
There should be a short review here though, because I have written this code a long time ago, and it might actually do more than optimizing I could have forgotten about.

That said, I believe the clipping optimization should not respect anti-aliasing. It works with coordiantes (surface_shape.clip_width and surface_shape.clip_height) which are not affected by anti-aliasing (unless our surface_shape is bad).
If optimization / implementation are really independent, then regardless of this issue, this comment should be removed or moved to the actual implementation (but that has been solved by my above observation probably).

The command-line interface is great for command-line junkies like myself. But I think a basic GUI front-end would go a long way for usability, perhaps similar in a way to what cxbx/virtualbox/vmware has.

Some basics:

• File > Load ISO
• Edit > Settings
  • ROM Images (allowing selection between multiple would be nice)
  • Controller Mapping
  • EEPROM config (mac address, region, etc)
  • Video (resolution/widescreen)
  • Graphics Tuning
  • Network config
  • Debug (SuperIO serial port, GDB server, Qemu monitor? Something)
  • Would like settings to be saved to a flat config file or something. Qemu seems to support this already but I think a flat ini file could do the job.
• LED ring status indicator, FPS metrics
• ...

We currently hardcode a EEPROM image in the source code which is loaded into the virtual EEPROM at startup.
Ideally we'd store the EEPROM contents in a file which is read and written at runtime.

The EEPROM is located here:

and here:

Testing on 2.x-rebase commit 5d4058d.
Bios: Complex 4627 Debug
HDD: 5960 Dashboard
ISO: Halo 1 and Midtown Madness 3 PAL repackaged with XISO and xdvdmulleter from ReDump ISO

Trying to load the ISO's in XQEMU 1 results in the game loading but in the 2.x-rebase trying to load it with the same setup it just goes to the dashboard.

The CI systems are building XQEMU for all platforms, and these binaries can be packaged (.zip, .dmg, .deb, etc) and made available to users for download through the artifact system.

Testing with commit 7f7dc95 and using xid-sdl.

After selecting a car the game goes to loadscreen to load the race.
Afterwards it displays the error message "Please reconnect the controller":

See this video of the problem for more context.

With DPRINTF enabled in xid-sdl.c I get the following output when that error message appears on screen:

...
xid handle_data 0x69 2 0x20
xid handle_data 0x69 2 0x20
xid handle_data 0x69 2 0x20
xid handle_control 0x2109 0x200
xid SET_REPORT 0x200
Set rumble power to 0x0, 0x0
xid handle_data 0x69 2 0x20
xid handle_data 0x69 2 0x20
xid handle_data 0x69 2 0x20
...

Note that it continously prints xid handle_data 0x69 2 0x20 regardless of this error and game.
However, the other 3 messages only appear when the error message first appears ingame.

Navigating to System Link appears to hang the system. Enabling packet dump shows one initial UDP broadcast packet being sent out. Enabling debug info from nvnet shows lots of activity, suggesting perhaps that it's waiting on some status bit to be set or a timeout to occur.

Something like the Dolphin FifoCi would be spectacular to have to catch regressions in the nv2a emulation.

We should probably dump each ShaderState to a file.

When the emulator starts, we could generate the shaders from this cache at startup.
This would avoid shader compilation during runtime where it might cause microstutter.

In case the emulator fails to compile a shader (also see #30), we could look at the ShaderState to see the raw input. This will become more important as our shaders move from readability to performance oriented code.

It would also make it easier to reproduce errors in the shader generator, as we could test new iterations on all known shaders, without re-running the games. Such a tool could also be used in automated testing.

Work in progress on the xbox-2.x-rebase branch. Filed here for tracking. See branch README.md for current status.

Tested on 50c0e6a

Specs:
CPU - Intel Core i7 8700K @ 5.0 Ghz
RAM - G.SKILL 32GB DDR4 3600MHz CL16
GPU - Nvidia GeForce GTX 1080 G1 Gaming 8GB
OS - Windows 10 64bit

Problem: When I click to empty slot, it massively drops to 0 fps and hangs or doing something that kills a performance.

Test against xqemu 1x: It's a regression propably so I've added a quickly video test where you can see that xqemu 1x goes further without drops.

VIDEO

Screenshot of issue (too slow to progress):

don't have the exact info (left the box up and it crashed my pc)
It said pgraph texfilter and had unsigned.. didn't get the error on the original codebase

Generated code is like this: r1.rgb = vec3(dot(r0.rgb, r0.a));

I'm not sure what exactly this does. I believe the dotproduct is only valid for rgb channels.
We should do hardware testing because this also violates the OpenGL spec (NV_register_combiners):

If the parameter is ALPHA, specifying a non-FALSE value for either of the parameters <abDotProduct> or <cdDotProduct>, generates an INVALID_VALUE error.

This part of the spec does not apply. It refers to writing to r1.a. The code display above is valid.

A workaround can be found in JayFoxRox/xqemu-espes#7 , but it's probably not correct.

Affected games:

• Mace Griffin Bounty Hunter
• Tony Hawk's American Wasteland
• Halo 2

I have not seen this happen on AppVeyor CI yet, which suggests this is environment specific.

It's quite bad because this happens at the end of compilation, so it looks like XQEMU compilation has failed, despite having worked fine.

Environment

I'm running 0523dea with #56 and #61, but had the same issue happen without those 2 PRs added.
My system is Windows 10 Pro N 64-bit (10.0, Build 17133).
MSYS2 has been upgraded to latest version using pacman -Syu

Package versions

$ pacman -Qs mingw-w64-x86_64-toolchain && pacman -Qs python2 && pacman -Qs python3
local/mingw-w64-x86_64-binutils 2.30-4 (mingw-w64-x86_64-toolchain)
    A set of programs to assemble and manipulate binary and object files (mingw-w64)
local/mingw-w64-x86_64-crt-git 6.0.0.5144.45e00853-1 (mingw-w64-x86_64-toolchain)
    MinGW-w64 CRT for Windows
local/mingw-w64-x86_64-gcc 7.3.0-2 (mingw-w64-x86_64-toolchain)
    GNU Compiler Collection (C,C++,OpenMP) for MinGW-w64
local/mingw-w64-x86_64-gcc-libgfortran 7.3.0-2 (mingw-w64-x86_64-toolchain)
    GNU Compiler Collection (libgfortran) for MinGW-w64
local/mingw-w64-x86_64-gcc-libs 7.3.0-2 (mingw-w64-x86_64-toolchain)
    GNU Compiler Collection (libraries) for MinGW-w64
local/mingw-w64-x86_64-gdb 8.1-2 (mingw-w64-x86_64-toolchain)
    GNU Debugger (mingw-w64)
local/mingw-w64-x86_64-headers-git 6.0.0.5144.45e00853-1 (mingw-w64-x86_64-toolchain)
    MinGW-w64 headers for Windows
local/mingw-w64-x86_64-libmangle-git 6.0.0.5079.3b7a42fd-1 (mingw-w64-x86_64-toolchain)
    MinGW-w64 libmangle
local/mingw-w64-x86_64-libwinpthread-git 6.0.0.5134.2416de71-1 (mingw-w64-x86_64-toolchain)
    MinGW-w64 winpthreads library
local/mingw-w64-x86_64-make 4.2.1-2 (mingw-w64-x86_64-toolchain)
    GNU make utility to maintain groups of programs (mingw-w64)
local/mingw-w64-x86_64-pkg-config 0.29.2-1 (mingw-w64-x86_64-toolchain)
    A system for managing library compile/link flags (mingw-w64)
local/mingw-w64-x86_64-tools-git 6.0.0.5111.3bc5ab74-1 (mingw-w64-x86_64-toolchain)
    MinGW-w64 tools
local/mingw-w64-x86_64-winpthreads-git 6.0.0.5134.2416de71-1 (mingw-w64-x86_64-toolchain)
    MinGW-w64 winpthreads library
local/mingw-w64-x86_64-pyqt5-common 5.10.1-1
    Common PyQt files shared between python3-pyqt5 and python2-pyqt5
local/mingw-w64-x86_64-python2 2.7.15-1
    A high-level scripting language (mingw-w64)
local/mingw-w64-x86_64-python2-pyqt5 5.10.1-1
    A set of Python 2.x bindings for the Qt5 toolkit
local/mingw-w64-x86_64-python2-sip 4.19.9-1
    Python 2.x SIP bindings for C and C++ libraries (mingw-w64)
local/python2 2.7.15-2
    A high-level scripting language
local/mingw-w64-x86_64-pyqt5-common 5.10.1-1
    Common PyQt files shared between python3-pyqt5 and python2-pyqt5
local/mingw-w64-x86_64-python3 3.6.5-1
    A high-level scripting language (mingw-w64)
local/mingw-w64-x86_64-python3-pyqt5 5.10.1-1
    A set of Python 3.x bindings for the Qt5 toolkit
local/mingw-w64-x86_64-python3-sip 4.19.9-1
    Python 3.x SIP bindings for C and C++ libraries (mingw-w64)
local/python 3.6.6-1
    Next generation of the python high-level scripting language
local/python3-appdirs 1.4.3-2
    A small Python module for determining appropriate platform-specific dirs, e.g. a "user data dir".
local/python3-packaging 16.8-3
    Core utilities for Python packages
local/python3-pip 10.0.1-1
    The PyPA recommended tool for installing Python packages
local/python3-pyparsing 2.2.0-2
    General parsing module for Python
local/python3-setuptools 39.2.0-1
    Easily download, build, install, upgrade, and uninstall Python packages
local/python3-six 1.10.0-5
    Python 2 and 3 compatibility utilities

Detailed log

Running ./build_windows.sh results in errors in dependency collection phase:

+ python2 ./get_deps.py dist/xqemu.exe dist
Skipping system DLL /c/WINDOWS/SYSTEM32/ntdll.dll
Skipping system DLL /c/WINDOWS/System32/KERNEL32.DLL
Skipping system DLL /c/WINDOWS/System32/KERNELBASE.dll
Skipping system DLL /c/WINDOWS/System32/ADVAPI32.dll
Skipping system DLL /c/WINDOWS/System32/msvcrt.dll
Skipping system DLL /c/WINDOWS/System32/sechost.dll
Skipping system DLL /c/WINDOWS/System32/RPCRT4.dll
Skipping system DLL /c/WINDOWS/System32/GDI32.dll
Skipping system DLL /c/WINDOWS/System32/gdi32full.dll
Skipping system DLL /c/WINDOWS/System32/msvcp_win.dll
Skipping system DLL /c/WINDOWS/System32/ucrtbase.dll
Skipping system DLL /c/WINDOWS/System32/USER32.dll
Skipping system DLL /c/WINDOWS/System32/win32u.dll
Skipping system DLL /c/WINDOWS/System32/ole32.dll
Skipping system DLL /c/WINDOWS/System32/combase.dll
Skipping system DLL /c/WINDOWS/SYSTEM32/IPHLPAPI.DLL
Skipping system DLL /c/WINDOWS/System32/bcryptPrimitives.dll
Skipping system DLL /c/WINDOWS/System32/SHELL32.dll
Skipping system DLL /c/WINDOWS/System32/cfgmgr32.dll
Skipping system DLL /c/WINDOWS/SYSTEM32/OPENGL32.dll
Skipping system DLL /c/WINDOWS/System32/shcore.dll
Skipping system DLL /c/WINDOWS/SYSTEM32/GLU32.dll
Skipping system DLL /c/WINDOWS/System32/windows.storage.dll
Skipping system DLL /c/WINDOWS/System32/shlwapi.dll
Skipping system DLL /c/WINDOWS/System32/kernel.appcore.dll
Skipping system DLL /c/WINDOWS/System32/profapi.dll
Skipping system DLL /c/WINDOWS/System32/powrprof.dll
Skipping system DLL /c/WINDOWS/System32/FLTLIB.DLL
Skipping system DLL /c/WINDOWS/System32/WS2_32.dll
Skipping system DLL /c/WINDOWS/SYSTEM32/WINMM.dll
Copying /mingw64/bin/libssp-0.dll...
Traceback (most recent call last):
  File "./get_deps.py", line 40, in <module>
    main()
  File "./get_deps.py", line 37, in main
    shutil.copyfile(dll_path, os.path.join(args.dest, dll_name))
  File "C:/msys64/mingw64/lib/python2.7/shutil.py", line 96, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: '/mingw64/bin/libssp-0.dll'

Re-running (./build_windows.sh) gives:

...
Skipping system DLL /c/WINDOWS/System32/powrprof.dll
Skipping system DLL /c/WINDOWS/System32/FLTLIB.DLL
Skipping system DLL /c/WINDOWS/System32/WS2_32.dll
Skipping system DLL /c/WINDOWS/SYSTEM32/WINMM.dll
Copying /mingw64/bin/libgcc_s_seh-1.dll...
Traceback (most recent call last):
  File "./get_deps.py", line 40, in <module>
    main()
  File "./get_deps.py", line 37, in main
    shutil.copyfile(dll_path, os.path.join(args.dest, dll_name))
  File "C:/msys64/mingw64/lib/python2.7/shutil.py", line 96, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: '/mingw64/bin/libgcc_s_seh-1.dll'

Notes

Running more often seems to get '/mingw64/bin/libgcc_s_seh-1.dll' again, although I'm not sure - I only ran this about 5 times as each build takes a considerable amount of time on this machine. Could be that it still randomly returns the other dll too (maybe others too).

Idea is to leverage some relatively recent developments in anti-aliasing research, namely SMAA (shader). This technique can be applied to an image, so even CPU blt'd images can benefit from this.

This issue happens on the 2.x rebase (commit 5d4058d with two linux-specific patches to fix the GL includes, and comment out glFrameTerminatorGREMEDY.

Text symbols are displayed where there should be no text:

(This screenshot is also affected by #42 , which is probaly unrelated to this issue.)

Note how there is text symbols in the 3D portion of the game, and the text on the bottom left seems to be tilted.
It's possible that these are objects which are using the wrong texture.

@JayFoxRox had the theory that it might be an issue with texture hashing.
However, further research is necessary.

Unfortunately I was unable to reproduce the issue after taking this screenshot.

Testing on 0523dea

Setup:
Bios: Connexant-256k-Debug-Gueux-Beta-2.bin
MCPX: v1.1
Dashboard: 5849

Specs:
OS: Win 10 1803
CPU: Intel Core i7-4770 @ 4.7ghz
GPU: Nvidia Geforce GTX 1070
RAM: 16GB DDR3-2000

When going ingame the camera moves on the car but all the previous frames are visible during that and the camera will freeze over the car and not move behind the car aka the visible gameplay (not including HUD) is frozen the game plays tho.

Note: the game renders fine in the demo.

Testing with commit 0523dea

One frame of the menu renders, then it turns black and after the demo played it comes back.

OS: Win10 1803
GPU: Nvidia GTX 1070
GPU Driver: 398.11

This prevents Xbox-Linux from booting.

However, having Xbox-Linux would probably be good for simple tests.
The research about PIO might also help with debugging retail games.

Need to update the main window titlebar with XQEMU and the XQEMU icon (tbd)

If you build xqemu 2.x rebase successfully and get that error at runtime:

No provider of glFrameTerminatorGREMEDY found.  Requires one of: GL extension "GL_GREMEDY_frame_terminator

Then you should try to comment out the glFrameTerminatorGREMEDY(); line there and rebuild:

Commenting out this line is not a proper fix btw, xqemu should not crash if this extension is missing, but it's enough to get xqemu working.

There is no Xbox specific GUI in XQEMU, which means that we force users to use a complicated CLI which was not meant for video game console emulation either.

The short-term solution people found for this, is to write frontends:

• XQEMU-Manager, Python 2/3 GUI using Qt
• xqemu-dash, C++ GUI using Qt
• XQEMU-Frontend, C# GUI
• xqemurun, Python 3 CLI

I have got exception after pressing Start:
MinGW Runtime Assertion
Assertion failed!
Program: D:\xb\xqemu2.0\xqemu.exe
File: C:/projects/xqemu-c5j6o/hw/xbox/dsp/dsp_cpu.c, Line 1018
Expression: address < DSP_XRAM_SIZE

Tested on latest 5d4058d, tested with bat-file, not xqemu manager (with xqemu-manager it stucks after copyright screen).
Here is bat-file content, maybe it can help to fix xqemu-manager:
xqemu.exe -cpu pentium3 -machine xbox,short_animation,bootrom=mcpx.bin -bios bios.bin -m 64 -drive index=0,media=disk,file=hdd.qcow2,locked -drive index=1,media=cdrom,file=gtasa.iso -usb -device usb-xbox-gamepad

If XQEMU fails to compile / link a shader it currently only reports the compilation / link log (which is implementation dependent; Usually the line which caused the issue and a short message, but nothing else).
I think we should also include the complete set of shaders so it can be investigated more easily. This is also important because some drivers are very bad at generating a meaningful compilation / link log.
This will especially be helpful once we have users who will report bugs.
(A similar change was also done in Citra a while ago and it turned out to be useful)

The necessary changes should be done in hw/xbox/nv2a_shaders.c

Tested on 0523dea

Specs:
CPU - Intel Core i7 8700K @ 5.0 Ghz
RAM - G.SKILL 32GB DDR4 3600MHz CL16
GPU - Nvidia GeForce GTX 1080 G1 Gaming 8GB
OS - Windows 10 64bit

Problem: Intro videos (.xmv) plays just fine and fast, but after I press a start button on main menu it drops to maybe 0.2 fps.

Workaround: Deleting the audio files (.wma) helped to get usable performance in menu (Screenshot) to get ingame (Screenshot). Deleting video files does not have noticable performance impact.

Screenshot of issue (too slow to progress):

What happens?

Starting xqemu, I get the message "'usb-host' is not a valid device model name".

What was supposed to happen?

My Duke controller was supposed to be forwarded with hub and all, as described here.

Command line

qemu-system-i386 -cpu pentium3 -machine xbox,bootrom=mcpx_1.0.bin,short_animation -m 64 \
-bios Complex_4627.bin \
-drive file=xbox_hdd.qcow2,index=0,media=disk,locked \
-drive file=Superdisc.iso,index=1,media=cdrom \
-device usb-host,hostbus=001,hostaddr=006

Sysinfo

OS: Debian testing
XQEMU revision: 0523dea
Flash ROM: Complex_4627.bin
libusb version: 1.0.22

Solid documentation is badly needed. This would be a great way to attract new developers and get them up to speed quickly. Possible something like Read the Docs can be used for this.

Things this should cover:

• Basic system init flow (very basics how Qemu devices are created, bus init, device init)
• What the main source files are
• High to medium level on how nv2a works, how nvnet works, how XYZ works...
• Debugging techniques (how to use KD, how to debug on real hardware (nxdk-rdt possibly))

Update: the new xqemu.com site is live! This project level documentation should be added there.

Low-level details about the nv2a architecture should probably end up going back to the envytools project. Other low-level details might be better suited for the XboxDevWiki.

Current revision is 1d968aa
Caused by / See espes/xqemu#46 (comment)

Objects which used to look fine are black now.

I've looked a bit into the Smashing Drive issue:

• Fixed function shading is turned on.
• Lighting is turned on.
• Only one light is enabled (Light 0, Infinite light type).
• No normals supplied (glVertexAttrib4fv(index = 2, v = [0, 0, 0, 0])).

The result is that a lamberts term with a zero-vector (= Normal here) is: 0.0 * x + 0.0 * y + 0.0 * z = 0.0.
So there is no light contribution in the scene. No light means that everything is not lit / black.

I did not verify if NHL Hitz 2002 runs into the exact same issue / situation. However, it still worked prior to #46 and doesn't work anymore now.

Affected games:

• Smashing Drive (Logos and sky + a lot of objects in intro are black)
• NHL Hitz 2002 (Ice / Stadium are black)

(Thanks to @JohnGodgames for testing + reporting the issue with NHL Hitz 2002; the Smashing Drive report is mine)

At the time of writing, this was an assumption and we weren't aware of any games using it.
Now we know of:

• Baldur's Gate: Dark Alliance II
• BMX XXX
• Conker Live and Reloaded
• Halo
• Halo 2
• Kameo Elements of Power
• Steel Battalion: Line of Contact

A unit test for all of these functions should be written, probably using NXDK-RDT and readback from the GPU to verify how the data was parsed into the vertex. Re-testing those games to confirm behaviour is also acceptable.

Something like Travis CI would be great to have to test the build on PR.

It would be also nice if we could allow downloads of these builds. It seems like many users run Windows, perhaps we can do a cross-compile build and Zip it up for download. This would allow people to more easily help with compatibility testing.

This is a video showing the issue.

There is a similar issue on other maps. The best example is probably "The Silent Cartographer" where the entire map is covered in fog.
It is unknown if this is a related issue, so I've dedicated this issue to Battle Creek.

Background for debugging this issue:

Fog is a dedicated feature of the fixed function pipeline (ffp), and in shaders it can be implemented in various ways, but the final combiner stage is ideal for it.

Considering that fog is typically the last stage, this issue looks like it's fog related (but could also be shadows or something else).
The later stages (such as fog) have the power to overwrite anything else - whereas textures typically happen very early on and are less uniform; lighting is also usually not that uniform either and it can't really overwrite the color in that way.

How you'd debug this depends on wether those draw calls are ffp or programmable pipeline:

• if this is programmable, I'd first make sure that if I just use "output = textures" that I get something useful (which should be an early step in the shader). then I'd remove commands at the end (where you'd expect fog) and see which one overwrites it again, until you've pinned the instruction which is at fault.
• if it's fixed function, then I'd first look into fog configuration and turn it off and just see what happens.

(The following was noticed after writing the above fog description)

I also noticed that the base contains a foggy section. I wonder if this might be an effect which accidentally spreads over the entire map in XQEMU.
Note that the XQEMU wall does not appear to show any difference between the lower (fog) and upper (no fog) portion.

Here's a screenshot from the linked video:

One major performance hinderance is time spent copying between RAM and graphics memory (glReadPixels) and associated waits for pipeline completion. Ideally, we should avoid this if at all possible. For example, if a surface is rendered, then used again for a second rendering pass, it should remain resident in graphics memory for the second rendering pass.

Many people are scared away by the huge QEMU source tree.

However, almost all of our code is exclusively in hw/xbox.

We should tell people where to look for our code, by sending them straight to that folder.
That should happen prominently in README.md

Our web-ecosystem should also do this; and if this is not done when closing this issue, a seperate issue should be created for xqemu/xqemu.com

XQEMU doesn't support sound yet.

@JayFoxRox has done some research and has some work here:

• JayFoxRox/xqemu-espes#24
• JayFoxRox/xqemu-espes#25

#           define NV097_SET_TEXTURE_FORMAT_COLOR_LC_IMAGE_YB8CR8YA8CB8 0x25

Affected:

• MotoGP: opening screen

Running MESA on Arch Linux I get the error which was described in #13 .
epoxy has not been integrated yet.

As master is currently broken, this issue should be fixed immediately.
I'll mark it as a regression, because XQEMU compilation used to work, now it doesn't.
Furthermore regression shows the importance of this issue.

Fetched from origin and checkout out current master (7f7dc95)
Then ran build_linux.sh:

[fox@x230 xqemu2]$ ./build_linux.sh 
+ set -o pipefail
+ ./configure --enable-debug '--extra-cflags=-march=native -g -O0 -Wno-error=redundant-decls -Wno-error=unused-but-set-variable -DXBOX=1' --disable-werror --target-list=i386-softmmu --enable-sdl --enable-kvm --disable-xen --with-sdlabi=2.0 --disable-curl --disable-vnc --disable-docs --disable-tools --disable-guest-agent --disable-tpm --disable-live-block-migration --disable-replication --disable-capstone --disable-fdt --disable-libiscsi --disable-spice --disable-user

...

make: *** [Makefile:478: subdir-i386-softmmu] Error 2

Re-run to get clean error log:

[fox@x230 xqemu2]$ make
  CC      i386-softmmu/gdbstub-xml.o
  CC      i386-softmmu/hw/xbox/nv2a/nv2a.o
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/gl/gloffscreen.h:44,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_shaders.h:25,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:38,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/GL/glew.h:85:2: error: #error gl.h included before glew.h
 #error gl.h included before glew.h
  ^~~~~
/usr/include/GL/glew.h:97:2: error: #error glext.h included before glew.h
 #error glext.h included before glew.h
  ^~~~~
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/gl/gloffscreen.h:44,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_shaders.h:25,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:38,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/GL/glew.h:18730:28: error: conflicting types for ‘PFNGLFRAGMENTLIGHTMODELFVSGIXPROC’
 typedef void (GLAPIENTRY * PFNGLFRAGMENTLIGHTMODELFVSGIXPROC) (GLenum pname, GLfloat* params);
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/epoxy/gl.h:89,
                 from /home/fox/Data/Projects/xqemu2/include/ui/console.h:11,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:27,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/epoxy/gl_generated.h:7427:27: note: previous declaration of ‘PFNGLFRAGMENTLIGHTMODELFVSGIXPROC’ was here
 typedef void (GLAPIENTRY *PFNGLFRAGMENTLIGHTMODELFVSGIXPROC)(GLenum pname, const GLfloat * params);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/gl/gloffscreen.h:44,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_shaders.h:25,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:38,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/GL/glew.h:18732:28: error: conflicting types for ‘PFNGLFRAGMENTLIGHTMODELIVSGIXPROC’
 typedef void (GLAPIENTRY * PFNGLFRAGMENTLIGHTMODELIVSGIXPROC) (GLenum pname, GLint* params);
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/epoxy/gl.h:89,
                 from /home/fox/Data/Projects/xqemu2/include/ui/console.h:11,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:27,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/epoxy/gl_generated.h:7429:27: note: previous declaration of ‘PFNGLFRAGMENTLIGHTMODELIVSGIXPROC’ was here
 typedef void (GLAPIENTRY *PFNGLFRAGMENTLIGHTMODELIVSGIXPROC)(GLenum pname, const GLint * params);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/gl/gloffscreen.h:44,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_shaders.h:25,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:38,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/GL/glew.h:18734:28: error: conflicting types for ‘PFNGLFRAGMENTLIGHTFVSGIXPROC’
 typedef void (GLAPIENTRY * PFNGLFRAGMENTLIGHTFVSGIXPROC) (GLenum light, GLenum pname, GLfloat* params);
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/epoxy/gl.h:89,
                 from /home/fox/Data/Projects/xqemu2/include/ui/console.h:11,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:27,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/epoxy/gl_generated.h:7431:27: note: previous declaration of ‘PFNGLFRAGMENTLIGHTFVSGIXPROC’ was here
 typedef void (GLAPIENTRY *PFNGLFRAGMENTLIGHTFVSGIXPROC)(GLenum light, GLenum pname, const GLfloat * params);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/gl/gloffscreen.h:44,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_shaders.h:25,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:38,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/GL/glew.h:18736:28: error: conflicting types for ‘PFNGLFRAGMENTLIGHTIVSGIXPROC’
 typedef void (GLAPIENTRY * PFNGLFRAGMENTLIGHTIVSGIXPROC) (GLenum light, GLenum pname, GLint* params);
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/epoxy/gl.h:89,
                 from /home/fox/Data/Projects/xqemu2/include/ui/console.h:11,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:27,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/epoxy/gl_generated.h:7433:27: note: previous declaration of ‘PFNGLFRAGMENTLIGHTIVSGIXPROC’ was here
 typedef void (GLAPIENTRY *PFNGLFRAGMENTLIGHTIVSGIXPROC)(GLenum light, GLenum pname, const GLint * params);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/gl/gloffscreen.h:44,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_shaders.h:25,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:38,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/GL/glew.h:18743:28: error: conflicting types for ‘PFNGLGETFRAGMENTMATERIALFVSGIXPROC’
 typedef void (GLAPIENTRY * PFNGLGETFRAGMENTMATERIALFVSGIXPROC) (GLenum face, GLenum pname, const GLfloat* data);
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/epoxy/gl.h:89,
                 from /home/fox/Data/Projects/xqemu2/include/ui/console.h:11,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:27,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/epoxy/gl_generated.h:7622:27: note: previous declaration of ‘PFNGLGETFRAGMENTMATERIALFVSGIXPROC’ was here
 typedef void (GLAPIENTRY *PFNGLGETFRAGMENTMATERIALFVSGIXPROC)(GLenum face, GLenum pname, GLfloat * params);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/gl/gloffscreen.h:44,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_shaders.h:25,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:38,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/GL/glew.h:18744:28: error: conflicting types for ‘PFNGLGETFRAGMENTMATERIALIVSGIXPROC’
 typedef void (GLAPIENTRY * PFNGLGETFRAGMENTMATERIALIVSGIXPROC) (GLenum face, GLenum pname, const GLint* data);
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/epoxy/gl.h:89,
                 from /home/fox/Data/Projects/xqemu2/include/ui/console.h:11,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:27,
                 from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/usr/include/epoxy/gl_generated.h:7623:27: note: previous declaration of ‘PFNGLGETFRAGMENTMATERIALIVSGIXPROC’ was here
 typedef void (GLAPIENTRY *PFNGLGETFRAGMENTMATERIALIVSGIXPROC)(GLenum face, GLenum pname, GLint * params);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:175:
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_pgraph.c:264:10: warning: redundant redeclaration of ‘pgraph_read’ [-Wredundant-decls]
 uint64_t pgraph_read(void *opaque, hwaddr addr, unsigned int size);
          ^~~~~~~~~~~
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:161:14: note: previous declaration of ‘pgraph_read’ was here
 DEFINE_PROTO(pgraph)
              ^~~~~~
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:145:14: note: in definition of macro ‘DEFINE_PROTO’
     uint64_t prefix ## _read(void *opaque, hwaddr addr, unsigned int size); \
              ^~~~~~
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:175:
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_pgraph.c:265:6: warning: redundant redeclaration of ‘pgraph_write’ [-Wredundant-decls]
 void pgraph_write(void *opaque, hwaddr addr, uint64_t val, unsigned int size);
      ^~~~~~~~~~~~
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:161:14: note: previous declaration of ‘pgraph_write’ was here
 DEFINE_PROTO(pgraph)
              ^~~~~~
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:146:10: note: in definition of macro ‘DEFINE_PROTO’
     void prefix ## _write(void *opaque, hwaddr addr, uint64_t val, unsigned int size);
          ^~~~~~
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:175:
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_pgraph.c: In function ‘load_graphics_object’:
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_pgraph.c:3976:32: warning: variable ‘switch3’ set but not used [-Wunused-but-set-variable]
     uint32_t switch1, switch2, switch3;
                                ^~~~~~~
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_pgraph.c:3976:23: warning: variable ‘switch2’ set but not used [-Wunused-but-set-variable]
     uint32_t switch1, switch2, switch3;
                       ^~~~~~~
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:176:
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_pfifo.c: At top level:
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a_pfifo.c:31:7: warning: redundant redeclaration of ‘pfifo_puller_thread’ [-Wredundant-decls]
 void *pfifo_puller_thread(void *opaque);
       ^~~~~~~~~~~~~~~~~~~
In file included from /home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.c:27:
/home/fox/Data/Projects/xqemu2/hw/xbox/nv2a/nv2a.h:442:7: note: previous declaration of ‘pfifo_puller_thread’ was here
 void *pfifo_puller_thread(void *opaque);
       ^~~~~~~~~~~~~~~~~~~
make[1]: *** [/home/fox/Data/Projects/xqemu2/rules.mak:66: hw/xbox/nv2a/nv2a.o] Error 1
make: *** [Makefile:478: subdir-i386-softmmu] Error 2
[fox@x230 xqemu2]$ 

Version information:

• extra/mesa 18.1.1-1
• extra/glew 2.1.0-1

MinGW Runtime Assertion
Assertion failed!
Program: D:\xb\xqemu2.0\xqemu.exe
File: C:/projects/xqemu-c5j6o/hw/xbox/nv2a/nv2a_pfifo.c, Line 366
Expression: false

Tested on latest 5d4058d.