Results 1 to 9 of 9
  1. #1
    Emulator Developer
    Join Date
    Oct 2007
    Posts
    510
    Mentioned
    0 Post(s)

    Native Windows build of Mupen64Plus: Developer Preview

    It's here. The second beta release of our series leading up to 2.0: Mupen64Plus v1.99.2 has been tagged. I'm not creating official source and binary packages of this tag, because it is primarily meant to be a Developer Preview for the new native Win32 build of Mupen64Plus.

    This is the first ever release of Mupen64Plus which can be compiled either by GCC in unix-based operating systems or Visual C++ in Windows. No other N64 emulator has ever been able to claim this level of platform independence. So, for you Win32 developers who would like to build and run this preview release, here is the software that you will need:

    1. Mercurial (TortoiseHG)
    2. Visual Studio .NET 2005

    That's it; no other tools or libraries are needed. I chose to base the project files on VS 2005 (MSVC8) because that is the latest version which is officially supported by SDL. It may be possible to import/upgrade the sln/project files to VC9 but I haven't attempted this. To get started,

    1. Use your Mercurial client to clone tag "1.99.2" of the following repositories (put them in the same parent directory):

    http://bitbucket.org/richard42/mupen64plus-audio-sdl/
    http://bitbucket.org/richard42/mupen64plus-core/
    http://bitbucket.org/richard42/mupen64plus-input-sdl/
    http://bitbucket.org/richard42/mupen64plus-rsp-hle/
    http://bitbucket.org/richard42/mupen64plus-ui-console/
    http://bitbucket.org/richard42/mupen64plus-video-rice/
    http://bitbucket.org/richard42/mupen64plus-win32-deps/

    2. Open up the solution file: mupen64plus-ui-console\projects\msvc8\mupen64plus-ui-console.sln

    3. Build it in Debug or Release mode

    4. Run it. You can use 'winrar' or similar to unzip the mupen64plus.v64.gz test ROM file in mupen64plus-core\roms\ and drop it into the build directory, then click the "Run" button in visual studio. Or, you can open a DOS shell and 'cd' to the build dir and run your own roms with "mupen64plus-ui-console.exe \path\to\my\rom.z64".

    Caveats Read this before complaining:
    1. There is no GUI application for selecting the ROMs. The GUI code was removed during the re-architecture for the sake of platform independence. There is only a command-line front-end application. If you would like to have a GUI front-end, I encourage you to write one. The core library API is fully documented and published on our emuwiki site.
    2. The console-based front-end only accepts uncompressed ROM images. If your ROMs are zipped, you will have to unzip them.
    3. The included Rice Video plugin seem to be sensitive to a parameter called ScreenUpdateSetting. The value which worked best in Linux causes a lot of flickering in Windows. If you have this problem, you can change the setting either on a per-ROM basis by editing the RiceVideoLinux.ini file or on a global (default) basis in the mupen64plus.cfg file, which is in a subdir of your home directory called "Application Data\Mupen64Plus".


    So the important question: How does it run? I have a core 2 duo laptop with an Intel 965 chipset (X3100 integrated graphics) and Mario Kart runs beautifully. The dynamic recompiler works (you have to enable it with --emumode 2), the audio playback is great, and the new joystick auto-configuration works. I haven't tested it extensively, so there are bound to be a few latent bugs. Give it a shot and let me know how it runs!


  2. #2
    Graphic programming enthusiast Narann's Avatar
    Join Date
    Jan 2010
    Posts
    78
    Mentioned
    0 Post(s)
    Hi Richard,

    I'd recieved your message but didn't had time to compile the project...

    I'd read the code but don't understand a lot... I'm not a good dev...

    I will try to compile it and say here if I'd prob.

    Thank a lot

    Quote Originally Posted by Richard42 View Post
    The core library API is fully documented and published on our emuwiki site
    Good idea!

    I'd try to compile core with VS9 (Visual C++ 2008 Express).

    Only the core (not console).

    I give you the only 1 warn:
    Code:
    1>\mupen64plus-core\src\r4300\x86\rjump.c(84) : warning C4731: 'dyna_start' : frame pointer register 'ebp' modified by inline assembly code
    Only seems to be a little code error. I don't really understant but I'd find that:
    http://msdn.microsoft.com/en-us/library/ywz8xf2a.aspx

    If I compile the sln project, I had no prob (Wow! Quick!).

    First try:

    Code:
    C:\Users\Narann>D:\Prog\mupen64plus\mupen64plus-ui-console\projects\msvc8\Debug\
    mupen64plus-ui-console.exe "D:\Prog\mupen64plus\mupen64plus-ui-console\projects\
    msvc8\GoldenEye 007 (E) [!].z64"
     __  __                         __   _  _   ____  _
    |  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___
    | |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __|
    | |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \
    |_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/
                 |_|         http://code.google.com/p/mupen64plus/
    Mupen64Plus Console User-Interface Version 1.99.2
    
    UI-console: attached to core library 'Mupen64Plus Core' version 1.99.2
                Includes support for Dynamic Recompiler.
    Core Warning: Couldn't open configuration file 'C:\Users\Narann\AppData\Roaming\
    Mupen64Plus\mupen64plus.cfg'.  Using defaults.
    Core Error: Unable to open rom database file '(null)'.
    Core: Goodname: GOLDENEYE (unknown rom)
    Core: Name: GOLDENEYE
    Core: MD5: CFF69B70A8AD674A0EFE5558765855C9
    Core: CRC: 414ca61 2e57b8aa
    Core: Imagetype: .z64 (native)
    Core: Rom size: 12582912 bytes (or 12 Mb or 96 Megabits)
    Core: Version: 1447
    Core: Manufacturer: Nintendo
    Core: Country: Europe (0x50)
    UI-Console: Cheat codes disabled.
    UI-console: using Video plugin: <dummy>
    UI-console: using Audio plugin: <dummy>
    UI-console: using Input plugin: <dummy>
    UI-console: using RSP plugin: <dummy>
    Core Warning: No video plugin attached.  There will be no video output.
    Core Warning: No audio plugin attached.  There will be no sound output.
    Core Warning: No input plugin attached.  You won't be able to control the game.
    Core Error: Could not construct face from (null)
    Core: Starting R4300 emulator: Cached Interpreter
    Core: couldn't open eeprom file 'C:\Users\Narann\AppData\Roaming\Mupen64Plus\sav
    e\GOLDENEYE (unknown rom).eep' for reading

    Quote Originally Posted by Richard42 View Post
    If you have this problem, you can change the setting either on a per-ROM basis by editing the RiceVideoLinux.ini file or on a global (default) basis in the mupen64plus.cfg file, which is in a subdir of your home directory called "Application Data\Mupen64Plus".
    mupen64plus.cfg don't seems to be created by default. Even If I create the file (on Win7: C:\Users\Narann\AppData\Roaming\Mupen64P lus\mupen64plus.cfg). I don't know how generate it for the first time.

    Mmmh... I read your code and the cfg file creation:
    Code:
    /* first, save the file if necessary */
        if (l_SaveConfigOnExit)
            ConfigSaveFile();
    From the ConfigShutdown() proc seems to be execute (by CoreShutdown) only (and only) if there is a problem with the rom:
    Code:
    /* load ROM image */
    In the main.c

    The only way I'd find to generate the mupen64plus.cfg was to enter a invalid rom path and magic! the mupen64plus.cfg was created!

    So, if it's the first time you launch mupen64plus with a valid rom path, you will be unable to play. The emulator start but you can't quit "cleanly" (the only way is to do ctrl+C but it kill the proc and don't execute the end of the code).

    Maybe you have to try to delete your C:\Users\Narann\AppData\Roaming\Mupen64P lus folder and launch a valid line: mupen64plus "C:\Roms\myRom.z64"

    To see what I'm talking about.

    Shame on me. The mupen64plus had to be launch from his directory... Noob error. (It's late in France ^^ )

    Goldeneye start.

    I have this message several times:
    Code:
    Core: couldn't open memory pack file 'C:\Users\Narann\AppData\Roaming\Mupen64Plu
    s\save\GoldenEye 007 (E) [!].mpk' for reading
    I hade to put:
    Code:
    ScreenUpdateSetting = 7
    To avoid flick
    And
    Code:
    R4300Emulator = 2
    To have no lag
    After few seconds, I had a "HEAP CORRUPTION DETECTED". I can't tell more but I will search more deeply later (maybe just a VS9 prob... Or the warning I told up?).

    Important thing:

    Don't seems to be a mupen64plus-audio-sdl VS Project:
    http://bitbucket.org/richard42/mupen.../tip/projects/
    So when I open the main VS project, VS told me that it can't find mupen64plus-audio-sdl.vcproj

    I finish with that.

    Good job!

    Have a good day!
    Last edited by Narann; January 8th, 2010 at 01:59.

  3. #3
    Emulator Developer
    Join Date
    Oct 2007
    Posts
    510
    Mentioned
    0 Post(s)
    Quote Originally Posted by Narann View Post
    Hi Richard,

    I will try to compile it and say here if I'd prob.

    I'd try to compile core with VS9 (Visual C++ 2008 Express).
    Thanks very much for your testing. I'm glad that you had such good results.

    Quote Originally Posted by Narann View Post
    I give you the only 1 warn:
    Code:
    1>\mupen64plus-core\src\r4300\x86\rjump.c(84) : warning C4731: 'dyna_start' : frame pointer register 'ebp' modified by inline assembly code
    Only seems to be a little code error.
    That warning is unavoidable due to the way that the dynamic recompiler works. It's not a problem; the code is correct. I suppose I should put in a #pragma to deactivate that warning.

    Quote Originally Posted by Narann View Post
    After few seconds, I had a "HEAP CORRUPTION DETECTED". I can't tell more but I will search more deeply later (maybe just a VS9 prob... Or the warning I told up?).
    That probabbly shouldn't happen. If you can debug this further it would be helpful.

    Quote Originally Posted by Narann View Post
    Don't seems to be a mupen64plus-audio-sdl VS Project:
    http://bitbucket.org/richard42/mupen.../tip/projects/
    So when I open the main VS project, VS told me that it can't find mupen64plus-audio-sdl.vcproj
    That was an oversight on my part as well. I have pushed the audio plugin project file and moved the tag, so if you update with Mercurial you should get the project file.

    Thanks again for your testing, I'm glad you were able to make it run. What kind of hardware do you have?

  4. #4
    Graphic programming enthusiast Narann's Avatar
    Join Date
    Jan 2010
    Posts
    78
    Mentioned
    0 Post(s)
    Quote Originally Posted by Richard42 View Post
    Thanks again for your testing, I'm glad you were able to make it run.
    You can be! I just had to copy the project, open the .sln and compile!
    Quote Originally Posted by Richard42 View Post
    That warning is unavoidable due to the way that the dynamic recompiler works. It's not a problem; the code is correct. I suppose I should put in a #pragma to deactivate that warning.
    It's you wich see. As I'd said I didn't understand what the asm code does.
    Quote Originally Posted by Richard42 View Post
    That probabbly shouldn't happen. If you can debug this further it would be helpful.
    I'm trying but as you know, I don't have a developer formation, I'm autodidact. I'm searching how launch debug with command line (to launch the rom...). If you know how do that on VS, could you just told me where find that? I'm sur it's a little option lost somewhere... Thanks I suppose with a "map" of the exe, I will can do that easely... I know it exist, I know the principe but don't know how do that...
    The prob apear with Goldeneye E. Mario Kart seem to work perfectly.
    Quote Originally Posted by Richard42 View Post
    That was an oversight on my part as well. I have pushed the audio plugin project file and moved the tag, so if you update with Mercurial you should get the project file.
    It's ok now, I'd update the project. Sound work well.
    Quote Originally Posted by Richard42 View Post
    What kind of hardware do you have?
    - Win7 x64
    - Radeon 4870
    - Core2Quad Q9300
    - 4Go

    EDIT: I'd Find it!
    Code:
    COGLTexture::~COGLTexture()
    {
        // Fix me, if usage is AS_RENDER_TARGET, we need to destroy the pbuffer
    
        glDeleteTextures(1, &m_dwTextureName );
        OPENGL_CHECK_ERRORS;
        free(m_pTexture); //Crash here!
        m_pTexture = NULL;
        m_dwWidth = 0;
        m_dwHeight = 0;
    }
    Now I will try to understand why it do that but there is not a lot of comments for understand the code

    EDIT2:

    When I use OpenGL Debug mode, I have this line repeating:
    OpenGL Error code 1282 in 'd:\prog\mupen64plus\mupen64plus-video-rice\src\oglrender.cpp' line 540

    Error code 1282 is GL_INVALID_OPERATION

    Your code is:
    Code:
        glBegin(GL_TRIANGLE_FAN);
    
        float depth = -(g_texRectTVtx[3].z*2-1);
    
        glColor4f(g_texRectTVtx[3].r, g_texRectTVtx[3].g, g_texRectTVtx[3].b, g_texRectTVtx[3].a);
        TexCoord(g_texRectTVtx[3]);
        glVertex3f(g_texRectTVtx[3].x, g_texRectTVtx[3].y, depth);
        
        glColor4f(g_texRectTVtx[2].r, g_texRectTVtx[2].g, g_texRectTVtx[2].b, g_texRectTVtx[2].a);
        TexCoord(g_texRectTVtx[2]);
        glVertex3f(g_texRectTVtx[2].x, g_texRectTVtx[2].y, depth);
    
        glColor4f(g_texRectTVtx[1].r, g_texRectTVtx[1].g, g_texRectTVtx[1].b, g_texRectTVtx[1].a);
        TexCoord(g_texRectTVtx[1]);
        glVertex3f(g_texRectTVtx[1].x, g_texRectTVtx[1].y, depth);
    
        glColor4f(g_texRectTVtx[0].r, g_texRectTVtx[0].g, g_texRectTVtx[0].b, g_texRectTVtx[0].a);
        TexCoord(g_texRectTVtx[0]);
        glVertex3f(g_texRectTVtx[0].x, g_texRectTVtx[0].y, depth);
    
        glEnd(); //Error at this line!
    So there is something wrong between glBegin() and glEnd()...
    After a little search (here: http://www.opengl.org/sdk/docs/man/xhtml/glBegin.xml), I can read that:
    GL_INVALID_OPERATION is generated if a command other than
    glVertex,
    glColor,
    glSecondaryColor,
    glIndex,
    glNormal,
    glFogCoord,
    glTexCoord,
    glMultiTexCoord,
    glVertexAttrib,
    glEvalCoord,
    glEvalPoint,
    glArrayElement,
    glMaterial,
    glEdgeFlag,
    glCallList, or
    glCallLists is executed between
    the execution of glBegin and the corresponding
    execution glEnd.
    The problem seems to be the TexCoord() proc.
    I removed the TexCoord() call and put directly the glTexCoord2f() function with args. I wrote that and I don't have OpenGL Error anymore:
    Code:
        glBegin(GL_TRIANGLE_FAN);
    
        float depth = -(g_texRectTVtx[3].z*2-1);
    
        glColor4f(g_texRectTVtx[3].r, g_texRectTVtx[3].g, g_texRectTVtx[3].b, g_texRectTVtx[3].a);
        glTexCoord2f(g_texRectTVtx[3].tcord[0].u, g_texRectTVtx[3].tcord[0].v);
        glVertex3f(g_texRectTVtx[3].x, g_texRectTVtx[3].y, depth);
        
        glColor4f(g_texRectTVtx[2].r, g_texRectTVtx[2].g, g_texRectTVtx[2].b, g_texRectTVtx[2].a);
        glTexCoord2f(g_texRectTVtx[2].tcord[0].u, g_texRectTVtx[2].tcord[0].v);
        glVertex3f(g_texRectTVtx[2].x, g_texRectTVtx[2].y, depth);
    
        glColor4f(g_texRectTVtx[1].r, g_texRectTVtx[1].g, g_texRectTVtx[1].b, g_texRectTVtx[1].a);
        glTexCoord2f(g_texRectTVtx[1].tcord[0].u, g_texRectTVtx[1].tcord[0].v);
        glVertex3f(g_texRectTVtx[1].x, g_texRectTVtx[1].y, depth);
    
        glColor4f(g_texRectTVtx[0].r, g_texRectTVtx[0].g, g_texRectTVtx[0].b, g_texRectTVtx[0].a);
        glTexCoord2f(g_texRectTVtx[0].tcord[0].u, g_texRectTVtx[0].tcord[0].v);
        glVertex3f(g_texRectTVtx[0].x, g_texRectTVtx[0].y, depth);
    
        glEnd();
    I suppose because it's in OpenGL specs you should do something to make it clean but maybe there is a reason...

    EDIT3:
    I think I'd find the Heap Corrumption problem!
    As I'd said, the prob is here:
    Code:
    COGLTexture::~COGLTexture()
    {
        // Fix me, if usage is AS_RENDER_TARGET, we need to destroy the pbuffer
    
        glDeleteTextures(1, &m_dwTextureName );
        OPENGL_CHECK_ERRORS;
        free(m_pTexture); //Crash here!
        m_pTexture = NULL;
        m_dwWidth = 0;
        m_dwHeight = 0;
    }
    Actually, m_pTexture is not a pointer of the COGLTexture class. It's a protected pointer of CTexture class!
    So i remove the "free(m_pTexture)":
    Code:
    COGLTexture::~COGLTexture()
    {
        // Fix me, if usage is AS_RENDER_TARGET, we need to destroy the pbuffer
    
        glDeleteTextures(1, &m_dwTextureName );
        OPENGL_CHECK_ERRORS;
        m_pTexture = NULL;
        m_dwWidth = 0;
        m_dwHeight = 0;
    }
    And put it in the ~CTexture() method:
    Code:
    CTexture::~CTexture(void)
    {
    	free(m_pTexture);
    }
    And now, I don't have Heap Corrumption!

    Told me if I made a error somewhere but it seem to work!

    EDIT4:
    Other thing. Seem to be a new modification (8h ago):
    In main.c (console)
    Code:
    ParsedString = malloc(strlen(ParamSpec) + 1);
    Make me an error (Conversion from 'void*' to pointer to non-'void' requires an explicit cast), I've done this instead:
    Code:
    ParsedString = (char *)malloc(strlen(ParamSpec) + 1);
    EDIT5:
    in RSP_Parser.cpp (991):
    Code:
    CRender::g_pRender->SetFogEnable( gRDP.geometryMode & G_FOG ? true : false );
    There is a prob there (maybe in gRDP). In goldeneye yet, in interior, there is fog (this is good) but there is not on some "moveable objects", like doors. If (for fun), I put:
    Code:
    CRender::g_pRender->SetFogEnable( gRDP.geometryMode & G_FOG ? true : true );
    Everything is ok, the fog is also on doors.
    Last edited by Narann; January 11th, 2010 at 04:03.

  5. #5
    Emulator Developer
    Join Date
    Oct 2007
    Posts
    510
    Mentioned
    0 Post(s)
    Quote Originally Posted by Narann View Post
    I'm searching how launch debug with command line (to launch the rom...). If you know how do that on VS, could you just told me where find that? I'm sur it's a little option lost somewhere... Thanks
    You can just hit the small green forward arrow on the toolbar to begin debugging, or hit F5. It will pop up a terminal window for the app but once the application terminates it will kill the window. There's probably a way to force it to leave the window around but I'm not sure how.

    Quote Originally Posted by Narann View Post
    When I use OpenGL Debug mode, I have this line repeating:
    OpenGL Error code 1282 in 'd:\prog\mupen64plus\mupen64plus-video-rice\src\oglrender.cpp' line 540
    I fixed this and pushed to bitbucket. The problem was that I had put OPENGL_DEBUG macros in places where I shouldn't have. It is an error to call glGetError in between glBegin and glEnd.

    Quote Originally Posted by Narann View Post
    I think I'd find the Heap Corrumption problem!
    As I'd said, the prob is here:
    Code:
    COGLTexture::~COGLTexture()
    {
        // Fix me, if usage is AS_RENDER_TARGET, we need to destroy the pbuffer
    
        glDeleteTextures(1, &m_dwTextureName );
        OPENGL_CHECK_ERRORS;
        free(m_pTexture); //Crash here!
        m_pTexture = NULL;
        m_dwWidth = 0;
        m_dwHeight = 0;
    }
    Actually, m_pTexture is not a pointer of the COGLTexture class. It's a protected pointer of CTexture class!
    So i remove the "free(m_pTexture)":
    ...
    And now, I don't have Heap Corrumption!
    Told me if I made a error somewhere but it seem to work!
    That fixes the heap corruption but introduces a memory leak. The ~OGLTexture() method does not call the base class ~Texture(), so by moving the free() call into the base class, it never gets called. The problem is that somebody is writing to the texture data space after it is freed. There is a GetTexture() method which returns the pointer to m_pTexture. Some object is getting (and possibly storing) this pointer and then still using it after the original texture is destroyed. If you can find the source of this logical error and fix it, then the heap corruption will be fixed and there will be no memory leak.

    Quote Originally Posted by Narann View Post
    EDIT4:
    Make me an error (Conversion from 'void*' to pointer to non-'void' requires an explicit cast), I've done this instead:
    Code:
    ParsedString = (char *)malloc(strlen(ParamSpec) + 1);
    I've also pushed this change. We have to compile the ui-console C source files as C++ in MSVC because it doesn't support some nice C99 features which I've used in this code. Thus the type checking is more strict.

    Quote Originally Posted by Narann View Post
    EDIT5:
    in RSP_Parser.cpp (991):
    Code:
    CRender::g_pRender->SetFogEnable( gRDP.geometryMode & G_FOG ? true : false );
    There is a prob there (maybe in gRDP). In goldeneye yet, in interior, there is fog (this is good) but there is not on some "moveable objects", like doors. If (for fun), I put:
    Code:
    CRender::g_pRender->SetFogEnable( gRDP.geometryMode & G_FOG ? true : true );
    Everything is ok, the fog is also on doors.
    That's interesting, but it probably causes problems in other situations.. Thanks for your testing and fixing; keep it up!

  6. #6
    Graphic programming enthusiast Narann's Avatar
    Join Date
    Jan 2010
    Posts
    78
    Mentioned
    0 Post(s)
    Quote Originally Posted by Richard42 View Post
    You can just hit the small green forward arrow on the toolbar to begin debugging, or hit F5. It will pop up a terminal window for the app but once the application terminates it will kill the window. There's probably a way to force it to leave the window around but I'm not sure how.
    I'd find. Actually, I'd just had to add command line to debug options (I didn't know where it was but's it's ok now).
    Quote Originally Posted by Richard42 View Post
    I fixed this and pushed to bitbucket. The problem was that I had put OPENGL_DEBUG macros in places where I shouldn't have. It is an error to call glGetError in between glBegin and glEnd.
    Glad to be useful for something!
    Quote Originally Posted by Richard42 View Post
    That fixes the heap corruption but introduces a memory leak. The ~OGLTexture() method does not call the base class ~Texture(), so by moving the free() call into the base class, it never gets called.
    Ok, two things: My solution, of course, was not good because if I move the free(m_pTexture), I have to move the m_pTexture = NULL with him. (shame on me...)

    But what I don't understand is that m_pTexture is a pointer of CTexture class and is not freed by him.
    Code:
    class COGLTexture : public CTexture
    It's strange that COGLTexture class is a "child" of CTexture. So when COGLTexture is destroyed (by a delete), CTexture should also call hi destructor no?

    I don't know if it's me or if the code is "strange" (malloc in cpp? new would be more appropriate no?). Look like C code wich was "tranform" to C++ code.

    I'd post the prob there(fr)
    Quote Originally Posted by Richard42 View Post
    The problem is that somebody is writing to the texture data space after it is freed.
    When I debug it, seems to be exactly the free(m_pTexture) inscrution wich make the heap corumption. If it was as you said, the app should crash elsewhere in the code no?
    Quote Originally Posted by Richard42 View Post
    There is a GetTexture() method which returns the pointer to m_pTexture. Some object is getting (and possibly storing) this pointer and then still using it after the original texture is destroyed.
    After read and read again this sentence, I have understand! I will see this deeplyest.
    On the fr thread, someone talk me about this kind of prob.
    Quote Originally Posted by Richard42 View Post
    I've also pushed this change. We have to compile the ui-console C source files as C++ in MSVC because it doesn't support some nice C99 features which I've used in this code. Thus the type checking is more strict.
    Ok... Be more strict with type is not as bad...
    Quote Originally Posted by Richard42 View Post
    That's interesting, but it probably causes problems in other situations...
    Of course! As I said, it was just for test. For a moment (In OGL), doors and moveable objects are drawed as "no fogeable" object. This hack was to test to make all object fogeable. Maybe doors are not created at the same time of the "no moveable ground". Maybe the gRDP.geometryMode don't return the good thing for moveable object. I don't know what would say:
    Code:
    gRDP.geometryMode & G_SOMETHING
    But I will see the fog prob more deeply later, once I'll solved the Heap Corumption with textures. (I also have to test with linux seeing if this prob already appear.
    Quote Originally Posted by Richard42 View Post
    Thanks for your testing and fixing; keep it up!
    If it really help you, I will continue.

    Best

    EDIT:
    I'd tryed something (don't launght ^^):
    OGLTexture.cpp
    #include <stdio.h>
    Code:
    COGLTexture::~COGLTexture()
    {
        // Fix me, if usage is AS_RENDER_TARGET, we need to destroy the pbuffer
        printf("COGLTexture destroyed Start\n");
        glDeleteTextures(1, &m_dwTextureName );
        OPENGL_CHECK_ERRORS;
        printf("free crash\n");
        free(m_pTexture);
        printf("free dont crash\n");
        m_pTexture = NULL;
        m_dwWidth = 0;
        m_dwHeight = 0;
        printf("COGLTexture destroyed Done\n");
    }
    Texture.cpp
    Code:
    #include <stdio.h>
    CTexture::~CTexture(void)
    {
    	printf("CTexture destroyed << Yes! It destruct him!\n");
    }
    And I got this:
    Code:
    COGLTexture destroyed Start
    free crash
    free dont crash
    COGLTexture destroyed Done
    CTexture destroyed << Yes! It destruct him!
    
    ETC...
    
    COGLTexture destroyed Start
    free crash
    BIG CRASH HERE
    So, the destructor of CTexture is called! And it's call after the destructor of COGLTexture.

    Anyway, this:
    Code:
    #include <stdio.h>
    COGLTexture::~COGLTexture()
    {
        // Fix me, if usage is AS_RENDER_TARGET, we need to destroy the pbuffer
        glDeleteTextures(1, &m_dwTextureName );
        OPENGL_CHECK_ERRORS;
        m_dwWidth = 0;
        m_dwHeight = 0;
    }
    And:
    Code:
    #include <stdio.h>
    CTexture::~CTexture(void)
    {
        free(m_pTexture);
        m_pTexture = NULL;
    }
    don't solve the problem but I think it's cleanest to destroy the pointer in his class than elsewhere.

    If I understand well, somebody try to wrote on a freed memory space (where was the texture before) thinking he's wrotting on the texture.
    But I do that:
    OGLTexture.cpp
    Code:
    m_pTexture = malloc(m_dwCreatedTextureWidth * m_dwCreatedTextureHeight * GetPixelSize()+1000);
    The problem should be the same.

    If somebody try to write on the texture it should change nothing and crash no?
    If texture memory space is N. If I malloc N+1000, the "hidden pointer" should wrote in the N memory space. It don't care about the 1000 next.

    But If I do that I don't have crash! :/

    Maybe it's just luck and enlarging memory space make luck to don't fall on "something used" that would be why it don't crash...

    EDIT2:
    I've find this line:
    OGLTexture.cpp
    Code:
    di->lpSurface = m_pTexture;
    Now, I have to follow lpSurface...

    EDIT3:
    I've never gived the message of the heap corrumption:
    Code:
    HEAP CORRUPTION DETECTED: after Normal block (#11639) at 0x0790FF10.
    CRT detected that the application wrote to memory after end of heap buffer.
    It's clear... But How this can happen in a free instruction? (because debug told me it's free(m_pTexture) instruction) How a free can "wrote to memory after end of heap buffer"? I don't understand...

    EDIT4: This only happen with 1x1 textures. For the moment, from all my roms, only Goldeneye have 1x1 textures... Mario Kart no, Pilotwing no, etc...

    The only thing I found was to create a special condition:
    If texture is 1x1, texture is 2x2... It work very well!
    But I think there is a operation somewhere in the code wich "transform" the texture and "destroy or modify" is allocation so I will continue to "follow" the texture path to his free. Don't know, Goldeneye seem to be the only one to give 1x1 texture. So I can't reproduce the bug on other rom.

    EDIT5:
    Seems to be a prob of convertion. I've comment all convertion operations in ConvertImage.cpp and no have prob. I will uncomment them one by one to find the guilty.
    EDIT6:
    I find him, seems to be ConvertCI4_RGBA16 from "ConvertImage.cpp" wich make the free 1x1 texture crash. Maybe just a coincidence and maybe 1x1 map crash on all convertion. I will try to know why.
    EDIT7:
    I approach:
    Code:
    for (uint32 x = 0; x < tinfo.WidthToLoad; x+=2)
                {
                    uint8 b = pSrc[dwByteOffset ^ nFiddle];
    
                    uint8 bhi = (b&0xf0)>>4;
                    uint8 blo = (b&0x0f);
    
                    //pDst[0] = Convert555ToRGBA(pPal[bhi^1]); //when I comment this
                    //pDst[1] = Convert555ToRGBA(pPal[blo^1]); //and this, it not crash
    
                    if( bIgnoreAlpha )
                    {
                        pDst[0] |= 0xFF000000;
                        pDst[1] |= 0xFF000000;
                    }
    
                    pDst+=2;
    
                    dwByteOffset++;
                }
    I have the impression that this loop "can't consider" that tinfo.WidthToLoad could be egal to 1 (and in a 1x1 map case, it is).

    So, is it possible for N64 to have 1x1 texture? (I don't know why Goldeneye's devs prefer a 1x1 more than a simple color...)

    I think I had find the prob. Now it's a little more complex for me to take a decision... Is this prob exist on linux? I will try later (could you? You can only play 10-20 sec before crash ).

    Is the best way to "force" a 2x2 texture or to made a "if tinfo.WidthToLoad > 1"). I also suppose that if we have to do the modification there, whe need to do the modification for all convertion.

    Any idea about that?

    Any way, I'm very glad to find this kind of bug myself! As I said, I'm not a dev and only do that on my free time.

    Bye!
    Last edited by Narann; January 14th, 2010 at 01:56.

  7. #7
    EmuTalk Member
    Join Date
    Aug 2006
    Posts
    9
    Mentioned
    0 Post(s)
    Last source code compiled with VS2008 run well

  8. #8
    Leap of Faith
    Join Date
    Dec 2001
    Location
    St. Louis
    Posts
    959
    Mentioned
    0 Post(s)
    same as cebolla.

    downloaded the source just 30 minutes ago, installed VS2008 express, compiled no problem.

    cfg was generated on startup the first time.

    only have tried Mario Golf 64 so far, minus the weird video issue (where you can't see the course until you strike the ball, I know that was fixed somewhere but I forget what needs done or plugin to use, anyway), it ran just fine.
    LazerTag

  9. #9
    EmuTalk Member
    Join Date
    Aug 2006
    Posts
    9
    Mentioned
    0 Post(s)
    /Wp64 (in VS2008)

    cl : Línea de comandos warning D9035 : La opción 'Wp64' está obsoleta y se quitará en próximas versiones

    The option "Wp64" is obsolete (only produce a Warning)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •