What's new

Native Windows build of Mupen64Plus: Developer Preview

Richard42

Emulator Developer
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!
 

Narann

Graphic programming enthusiast
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... :unsure:

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

Thank a lot :)

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


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\Mupen64Plus\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\Mupen64Plus 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/mupen64plus-audio-sdl/src/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:
OP
R

Richard42

Emulator Developer
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.

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.

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.

Don't seems to be a mupen64plus-audio-sdl VS Project:
http://bitbucket.org/richard42/mupen64plus-audio-sdl/src/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?
 

Narann

Graphic programming enthusiast
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! ;)
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.:unsure:
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.
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.
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...:unsure:

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! :party:

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:
OP
R

Richard42

Emulator Developer
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.

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.

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! :party:
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. :)

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.

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!
 

Narann

Graphic programming enthusiast
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). :)
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! :D
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)
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?
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.
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...
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.
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:

LazerTag

Leap of Faith
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.
 

cebolla

New member
/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)
 

Top