[The green thunder11]

My friend is working on a paper Mario ROM hack but his emulator has reached a limit of textures that the emulator can handle.
He already already patched it so that it can handle 4GB of virtual memory instead of 2GB.
Is there some way to make the virtual memory even bigger? or is there another emulator that can handle more textures?

He is using the 1964 emulator with the glide64 graphic plugin.

[FAST6191]

Are you all doing some kind of higher definition retexturing work that would need such a high limit? If so we can probably discuss more there, if instead you are grabbing the end result of text rendering and replacing things there (we see that often in N64 and gamecube hacking work) then it is probably time to start learning ROM hacking as most understand it -- swapping out textures to change displayed text is not something that should be done unless the game itself uses textures/images for its text, and even then it should be done inside the ROM and not need an emulator to handle it.

The 4 gigabyte limit is likely more an issue with pointers, and operating system memory allocation. I do not imagine it would be that difficult to alter it to stream from a file or to parse a file list and load accordingly (then giving you basically infinite space), though it would likely break a few other things along the way.

[The green thunder11]

He is indeed trying to make a higher definition of the game, here is an example of what he is trying to do.

I doubt that he would want to alter the ROM as he would like it to have least problems as possible, though i'll have to talk to him about that.
Is there some sort of N64 sprite editor program out there? I myself have searched for it and found nothing.
Your help is appreciated by the way. 

[Zoinkity]

Most N64 titles don't use "sprites", even non-3D games.  They texture a rectangle (at low-level actually two triangles) with an image to display it.  It's much like stretching an image onto a canvas then setting that canvas in a room, except your image is painted on rubber.

There's exceptions; Bangaioh's a decent example, and anything that draws directly to the frame buffer (many of which aren't emulated).


Paper Mario isn't compressed, and although PAL is larger (64MB unless I'm mistaken) you're still talking about needing more than six times the storage?  Are you completely certain your video card is displaying the source images you're using at their full resolution?

Console won't work for this.
For simplicity's sake I'll just state at the resolution you're trying to achieve you won't be able to hit hardware at all.  On an actual N64 you can't exceed the display depth or tmem; the best quality possible is 1 pixel in:1 pixel out.  Using higher-quality source is a factor when doing the computations for elements, but this only goes so far. 
Tmem limitations can be exceeded by applying the texture across a greater number of surfaces (multiple texrects versus just one) at the cost of longer RSP/RCP processing times.  That's not a direct relationship either.  Depending on if the depth filter is in use or how collisions are being detected you could wind up with, worst case, quadratic growth.
Actual image sizes overrunning rdram is pretty easy to work around, but you'd have to implement a load-on-demand scheme.  It would be problematic if you're DMAing stupid amounts of data while trying to display them, but it's not impossible.


The problem with console does spread to emulation though!
The problem with depth on console is the problem with all graphics cards.  Hi-def image replacement in emulation potentially has the same problem.  You can not exceed the maximum depth currently displayed by the card, so that implicitly means there's a depth level at which an image no longer gains quality.  In fact, depending on how that case is treated it could dither the image in a way that looks worse than a less complex source. 
If you're talking about needing more than 4GB, your images would be, what?  Increased by a factor of 100?  You seriously need to check if that's truly what's being displayed or not.

[Jorpho]

He is indeed trying to make a higher definition of the game, here is an example of what he is trying to do.

You do realize that there's already at least one partially-complete HD texture pack for the game, don't you?  I believe the most recent version is at http://www.emulation64.com/files/info/1048/ .
https://www.youtube.com/watch?v=s00A-0DKZq4

If I'm not mistaken, HD textures are all handled by the emulator (and its plugins) and there's no need to start hacking in virtual memory support.