I do agree that we should improve the emulator. I haven't yet tested my SVN server from outside my home network so I'm not 100% sure that the port forwarding is working, but once it's set up right this will give us a practical way of working together.
I'm using mupen64 as part of a larger video game museum that I'm building; as a part of this project I have my own GUI written in python with pygame. So I'm really only interested in the 'nogui' build of mupen64 and its integration into this system. You're welcome to commit GUI improvements to the repository, however. If you want to make big changes that may break people's builds or take time to stabilize, we can make a branch to work on until it's ready to go back into the trunk. Most of the work that I plan to do will be fixing little bugs/annoyances and hunting down the remaining porting bugs. Maybe I'll do the dynamic recompiler some day too, because that's cool technology.
The best pattern that I've found for dealing with data types in a cross-platform way is to have a system/typedef header file where you define custom types like 'Int'/'Short'/'Char', or 'u32'/'s32'/'u64'/'s64'/etc. And then replace _all_ of the standard C/C++ types with the custom types in the code. This might be a worthwhile thing to do for mupen64, but it will be tedious. You would have to define a special Int-which-is-the-same-size-as-a-pointer type, in order to handle the code which does XOR on pointers for byte swapping. The only issue I see with applying this type handling to mupen64 is the plugins. It wouldn't be very clean to just copy this header file into all of the plugin sub-projects. To do it right would require having some common header file(s) which are shared between mupen64 and the plugin projects.
Richard
I'm using mupen64 as part of a larger video game museum that I'm building; as a part of this project I have my own GUI written in python with pygame. So I'm really only interested in the 'nogui' build of mupen64 and its integration into this system. You're welcome to commit GUI improvements to the repository, however. If you want to make big changes that may break people's builds or take time to stabilize, we can make a branch to work on until it's ready to go back into the trunk. Most of the work that I plan to do will be fixing little bugs/annoyances and hunting down the remaining porting bugs. Maybe I'll do the dynamic recompiler some day too, because that's cool technology.
The best pattern that I've found for dealing with data types in a cross-platform way is to have a system/typedef header file where you define custom types like 'Int'/'Short'/'Char', or 'u32'/'s32'/'u64'/'s64'/etc. And then replace _all_ of the standard C/C++ types with the custom types in the code. This might be a worthwhile thing to do for mupen64, but it will be tedious. You would have to define a special Int-which-is-the-same-size-as-a-pointer type, in order to handle the code which does XOR on pointers for byte swapping. The only issue I see with applying this type handling to mupen64 is the plugins. It wouldn't be very clean to just copy this header file into all of the plugin sub-projects. To do it right would require having some common header file(s) which are shared between mupen64 and the plugin projects.
Richard
