1964Video - official DevTalk & Release thread

[microdev]

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.

[squall_leonhart]

D3D9 was removed because it was borked.

[microdev]

D3D9 was removed because it was borked.

What means "borked"? If it means malfunctioning, then fixing might have been the better alternative - especially as it was optional.

[vinipsmaker]

...
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]

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.

[microdev]

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.

[Enzo Dragon]

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?

[Kodiack]

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!

[microdev]

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.

[Enzo Dragon]

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