What's new

1964Video - official DevTalk & Release thread

Status
Not open for further replies.
OP
M

microdev

Member
Alright, guys. This is something you guys should check out.

Morrowind Graphics Extender. A couple of years back, Mudlord got shaders working in 1.6.3. The results were amazing but it doesn't support loading half as many textures. Mudlord used Timeslip's utility for Oblivion as a starting point to do this.

MGE hooks d3d9.dll to apply post-process shaders to Morrowind, just like Mudlord's DX9 1.6.3 hooks d4rk.dll (in fact, d4rk.dll is practically the same .dll in everything but name) to do this same thing.

I don't know a thing about coding, but I thought I would bring this amazing application to your attention. As far as I know, it's open source and I'm sure the MGE devs wouldn't mind answering questions. There are a lot of high quality shaders they've already developed for MW and I see no reason why any of them could not be applied to an N64 game.

If you guys could re-implement shaders, it would be a BIG. DEAL.
The reason it doesn't work seems to be that 1964Video is compiled under DirectX8. DirectX9 is needed for applying these shaders. Someone (I think DD) removed the DirectX9 support. I don't know why. It would have to be readded from provitating from the shader mod.

What documentation tool will you guys use?
I think doxygen is a good tool.
So far, no tool is used for creating documentation but soly comments have been added to the source code. I think having a documentation of the used functions in a JavaDoc style would be a great and very helpful addition.

You can use SQLite, it will take about 256 kB on your disk. I'm using it in an embedded project and its cool. Webkit use it too to enable HTML 5 features. Plus, it has a small footprint. However, moving all the files to a table could be boring task and could take a lot.
Thanks for the info. But, I'm still not yet convinced about the advantage using a DB as the files would have to be loaded from file system, nevertheless. I think finding an intelligent way for indexing the pack folder (e.g. xml list) and getting somehow automatically aware of any changes would be the most comfortable way for reducing loading time. But this is to me so far of low priority. If anybody wants to implement this feel free.

Hey guys, where are the settings stored? I want to reset to defaults as I'm having PJ64 1.6 lock up on me when loading external textures, want to make sure its a legitimate problem and not something in my settings.

They are stored in the registry. There is also a registry key remover for resetting the configurations. I'll check if the name of the main key has changed and update the key remover if this is the case. I'll post the updated version in the first post later on.
 
Last edited:

vinipsmaker

C/C++ programmer, emacs user
...
So far, no tool is used for creating documentation but soly comments have been added to the source code. I think having a documentation of the used functions in a JavaDoc style would be a great and very helpful addition.
...

doxygen is like javadoc. we comment the code and the doxygen generate the documentation in several formats (html, pdf, postscript, LaTeX, xml, etc). Here an example.

Doxygen can be used in several languages and is the most used documentation tool in open-source world.


I think in december I'll can help the project.
 

Kodiack

New member
Loading too many high resolution textures into a game causes my emulator to crash. It doesn't matter which emulator I use.

My system specs are in my sig, and for reference (in case it's related to that) I have 512 MB of video memory. I can get the error messages if necessary.
 
OP
M

microdev

Member
I think in december I'll can help the project.
we are really looking forward to it :)


Loading too many high resolution textures into a game causes my emulator to crash. It doesn't matter which emulator I use.

My system specs are in my sig, and for reference (in case it's related to that) I have 512 MB of video memory. I can get the error messages if necessary.

Asuming you're using 1964Video r35: Do you have texture caching enabled or disabled? If enabled, please disable texture caching and report if this also crashes the emulator.

Most probably, you have too less RAM for large texture pack caching. I would have assumed that windows would handle this situation through swapping but obviously it doesn't.

If you're using an older version, please update & try again.
 
Last edited:

Enzo Dragon

STFU, NAVI
The reason it doesn't work seems to be that 1964Video is compiled under DirectX8. DirectX9 is needed for applying these shaders. Someone (I think DD) removed the DirectX9 support. I don't know why. It would have to be readded from provitating from the shader mod..
I don't know if dx9 was ever officially supported. Mudlord added DX9 support to 1.6.3 and released it with his stable version of 1.6.4. I don't know if the source is still around for mudlord's dx9 version of 1.6.3. He had a repository which should still be linked to in the old threads, though I have no idea if it's still online.

You can do some pretty damn amazing things with post-process shaders, though. I hope this is looked into further.
D3D9 was removed because it was borked.
That doesn't tell anyone anything, Dan. What do you mean by "borked"? That language is very vague. =/

There were some geometry issues that I know about, (warping/bending of polys) but I have no idea if that was dx9 issues or some other problem with 1.6.3. Either way, it was iterated once and then dropped. I'm sure whatever the problem was, the new team could figure it out.

I wonder if dx9 is faster than dx8. Does anybody know?
 
Last edited:

Kodiack

New member
Most probably, you have too less RAM for large texture pack caching. I would have assumed that windows would handle this situation through swapping but obviously it doesn't.

I could have sworn I'd tried this. o_O Either way, this resolved the issue, and textures are loading much much faster now. Kind of odd, as turning off caching should cause the opposite. =P

Thanks!
 
OP
M

microdev

Member
I could have sworn I'd tried this. o_O Either way, this resolved the issue, and textures are loading much much faster now. Kind of odd, as turning off caching should cause the opposite. =P

Thanks!

No. Turning of caching results in indexing the textures when the rom is started. If caching is enabled, they will not only be indexed but also loaded to RAM. Thus, if caching is disabled, the rom starts faster as the plugin doesn't have to load the textures at rom start. But with caching disabled, the plugin will have to load the textures everytime they are needed during gameplay. This can lead (especially for large textures) to delays during gameplay. With caching enabled, the textures are only loaded once and therefore don't cause any delay during gameplay.

This is e.g. recognizable in the intro movie (where the credits occure) of Castlevania LOD and most probably also in the Zelda Community pack as both are using huge textures.
 
Last edited:

Enzo Dragon

STFU, NAVI
Alright. One more suggestion, because I'm a huge jerk:

Back in '07 when Mudlord was working on this plugin, we had a very nice discussion about how best to force a game's viewport aspect ratio. Cyberman came up with this idea for how to handle it intelligently, though I can't say for sure how much of what he said was feasible (it sounds good to me!).

I DO know that it's possible because our pal Jabo implemented it years ago in the public version of his video plugin (the one that comes with pj64 1.6). Basically, Jabo's plugin renders the game in widescreen resolutions instead of stretching the image when a widescreen resolution is specified, so that the viewable area of the game is actually wider.

Would be pretty great to be able to render games in true widescreen instead of pillar-boxing them or resorting to hideous stretching, is what I am getting at. If I need to provide a more thorough explanation of viewport/screen aspect ratio, I will. <3
 

Kodiack

New member
No. Turning of caching results in indexing the textures when the rom is started. If caching is enabled, they will not only be indexed but also loaded to RAM. Thus, if caching is disabled, the rom starts faster as the plugin doesn't have to load the textures at rom start. But with caching disabled, the plugin will have to load the textures everytime they are needed during gameplay. This can lead (especially for large textures) to delays during gameplay. With caching enabled, the textures are only loaded once and therefore don't cause any delay during gameplay.

This is e.g. recognizable in the intro movie (where the credits occure) of Castlevania LOD and most probably also in the Zelda Community pack as both are using huge textures.

Ah, I see. I did notice some pretty painful halts when loading new environments in Ocarina of Time. Is there any workaround to get this to work? I have a 24 GB page file and 12 GB of memory. I doubt the plug-in's the issue, but there must be some way to get it to store the textures into RAM. Smoother gameplay is well worth the initial delay.
 
OP
M

microdev

Member
Ah, I see. I did notice some pretty painful halts when loading new environments in Ocarina of Time. Is there any workaround to get this to work? I have a 24 GB page file and 12 GB of memory. I doubt the plug-in's the issue, but there must be some way to get it to store the textures into RAM. Smoother gameplay is well worth the initial delay.

Oops, seems like I misread something. If caching works or not should only depend on your amount of system memory and not on the memory of your graphic card. The textures will be cached to ram and not to your graphic cart (well at least not all).

Having said that, I'm really wondering why turning off caching solved your issue then.
Hmm, you're using 1964Video r35, right? What error message occures, when the plugin crashes? Could you please open your task manager and have a look at the process of your emulator in the process tab? Than start the rom with caching enabled and watch how memory occupation by the emulator process rises. How much memory is occupied, when the emu crashes?

Normally caching should work fine for you as you have more than enough memory (RAM).
 

Kodiack

New member
Oops, seems like I misread something. If caching works or not should only depend on your amount of system memory and not on the memory of your graphic card. The textures will be cached to ram and not to your graphic cart (well at least not all).

Yeah, I kind of hoped it worked that way, otherwise it'd be quite limiting. =P The only textures that should be in the GPU memory are those that are in immediate use or are withing a set cache pool (i.e. up to 128 MB of textures may be cached in video memory or something).

Having said that, I'm really wondering why turning off caching solved your issue then.
Hmm, you're using 1964Video r35, right? What error message occures, when the plugin crashes? Could you please open your task manager and have a look at the process of your emulator in the process tab? Than start the rom with caching enabled and watch how memory occupation by the emulator process rises. How much memory is occupied, when the emu crashes?

Yes, I am using 1964Video r35.

Here's an image of the crash:

http://i357.photobucket.com/albums/oo20/Kodiack_Film/Private Miscellaneous/RuntimeError.png

The crash also happens in the 1964 emulator, as previously stated. I tried uninstalling and reinstalling Microsoft Visual C++ and the service packs, but to no avail.

Memory usage does continually go up. It was around ~1.7 GB in use for the OS before all the textures were loaded, and before the crash it hits 2.7 GB, with the emulator using 1.1 GB.

Normally caching should work fine for you as you have more than enough memory (RAM).

Definitely. 12 GB is really more than enough for anything out there. =P

Good luck with working out the issue, or finding what would be causing it. =)
 
OP
M

microdev

Member
Yeah, I kind of hoped it worked that way, otherwise it'd be quite limiting. =P The only textures that should be in the GPU memory are those that are in immediate use or are withing a set cache pool (i.e. up to 128 MB of textures may be cached in video memory or something).
It uses as much GPU memory as available.
Hmm, does not really contain any information about the crash
Memory usage does continually go up. It was around ~1.7 GB in use for the OS before all the textures were loaded, and before the crash it hits 2.7 GB, with the emulator using 1.1 GB.
1.1GB? That's a lot. Which hires pack are you using? Could you please provide a link to this pack? Maybe I can reproduce your problem with that pack...
 

Kodiack

New member
1.1GB? That's a lot. Which hires pack are you using? Could you please provide a link to this pack? Maybe I can reproduce your problem with that pack...

I use the latest version of this:

http://www.emutalk.net/showthread.php?t=45875

And come to think of it, 1.1 GB is absolutely insane. o_O The emulator should use ~5-50 MB itself, the ROM 32 MB, and the texture pack is 692 MB. Even though that ~750 MB of usage is still pretty high for an emulator, it's still below the projected 1.1 GB.
 

Nintendo Maniac

New member
Alright. One more suggestion, because I'm a huge jerk:

Back in '07 when Mudlord was working on this plugin, we had a very nice discussion about how best to force a game's viewport aspect ratio. Cyberman came up with this idea for how to handle it intelligently, though I can't say for sure how much of what he said was feasible (it sounds good to me!).

I DO know that it's possible because our pal Jabo implemented it years ago in the public version of his video plugin (the one that comes with pj64 1.6). Basically, Jabo's plugin renders the game in widescreen resolutions instead of stretching the image when a widescreen resolution is specified, so that the viewable area of the game is actually wider.

Would be pretty great to be able to render games in true widescreen instead of pillar-boxing them or resorting to hideous stretching, is what I am getting at. If I need to provide a more thorough explanation of viewport/screen aspect ratio, I will. <3
PJ64 1.7 beta has an improved version of said "force widescreen hack" FYI. Also nullDC and Dolphin implement force widescreen hacks as well.


Also, I'm getting an error as well, but a different kind of error. In PJ64 1.6 I get "Failed to load plugin" when I go to Options -> Settings... This happens with both r30 and r35. I haven't a clue why, and I can run both Jabo's Direct3D6 1.5.2 and Jabo's Direct3D8 1.6 just fine.

Interestingly enough, I also get an error in 1964 1.1 with the included 1964video plugin, saying it too couldn't load the plugin (though right when opening the program).

GPU is a Radeon 7000 64MB PCI (NOT PCIe, but the original PCI). While an older GPU, it handles N64 graphics just fine (I do have to lower the resolution a bit for Perfect Dark though :p).
OS: Windows XP Pro SP3
DirectX: 9.0c (4.09.0000.0904)
CPU: Pentium 4 @ 2GHz
RAM: 256 MB (reported as 254 MB)
HDD: 41.9 GB (37.5 GB Free)
 
Last edited:

GEROSENE

New member
nice plugin. good job. the problem i'm having, well more of an annoyance really, is that when i go from fullscreen (1680x1050) to windowed (640x480),
it crashes pj64 1.6. i read through the lists and couldn't find the solution. any ideas?
 
OP
M

microdev

Member
In PJ64 1.6 I get "Failed to load plugin" when I go to Options -> Settings... This happens with both r30 and r35. I haven't a clue why, and I can run both Jabo's Direct3D6 1.5.2 and Jabo's Direct3D8 1.6 just fine.

Interestingly enough, I also get an error in 1964 1.1 with the included 1964video plugin, saying it too couldn't load the plugin (though right when opening the program).

Did you do that?:
 

Nintendo Maniac

New member
HOLY CRAP I GOT IT TO WORK!

What I did was go to the older version of the plugin, that is Aristotle's Mudlord & Rice Video. That didn't work - it said I was missing msvcrtd.dll, so I checked the post again. It said I needed Microsoft Visual C++ 2008 SP1 so I got that, but it still said the DLL was missing. So I got the DLL and even though I wasn't getting the error anymore, the plugin wasn't listed... HOWEVER, 1964video WAS listed!

So it looks like you need Microsoft Visual C++ 2008 SP1 and/or msvcrtd.dll to use this plugin. You might want to mention that in the OP. ;P
 
Status
Not open for further replies.

Top