1964Video - official DevTalk & Release thread

[microdev]

My issue is that some static backgrounds (not hires, just the backgrounds that load with the ROM) load and appear as a green static--they don't load correctly. I've been using the DirectX render engine, but it does the same when I use the OpenGL engine.

Screenshot of what I'm talking about: http://i38.tinypic.com/nz4p4x.jpg

System Specs:
HP Pavilion DV7
AMD Turion X2 Dual-Core Processor @ 2.20GHz
Running Windows 7 RC 64-bit
ATI Radeon HD 3200 Graphics Card
4Gb RAM, 300 Gb HDD

That seems to be a common problem with some Radeon cards under some configuration. First recommendation would be to upgrade your drivers but I guess, that you already did.

Try also to check "normal combiner" in the "Game default option" tab. If it is checked, try with unchecking it. To me this seems to be the hottest trace.

Which render engine are you using? If it's DirectX you could try to change the "swap effect" method under the DirectX tab and see if this changes anything. If you are using OpenGL, you could try to use DirectX instead.

If none of these help I would propose to enable the "Display Tooltips" check box in the "General" tab. Than a tool tip will explain you every setting over which you are hovering your curser. That helps you determining if some of these settings might have an effect to your problem and change them.

Sorry for not being able to give you a precise instruction how to solve your problem but not being able to reproduce it, this is hard to do.

Let me know if one of these advices worked.

[microdev]

Packing would be a result however it would convert the texture data into something more manageable. If you think about what the TP is it's a file system based database. It would make sense to use this concept to store the data instead of scanning the disk to find loadable files etc. Turning files into BLOB's in a data base makes things easier. The additional advantage is being able to make an application using the same DB core to manage building the texture package. Less manual work in other words. Although a full fledged DB system is overkill it might lead to some ability to manage things in ways not previously thought of.

Wouldn't be the usage of a database a little bit too much? The files are already cached in a searchable list in memory. Thus, I don't see a need to put effort in that so far. Furthermore, how would you like to manage to add and remove textures from this database? Might become hard for retexturers...

But I completely agree with you, that something like CoolSmoky apparently did would be a cool thing. Meaning packing all texures to a single, compressed file for releasing them. Also adding texture compression would be very nice as it would drastically speed up the loading and would use less disk and VRAM space.

Anything I do won't be a miraculous change that is a certainty it will be slow. My biggest problem was just figuring out where to add in the db management.

Don't worry, no pressure. Even if you don't succeed at all, nobody will blame you. I can tell you, where to hook it in. The commented code should also help you a great deal with that.

[Chieftain459]

@microdev--hate to say it, but none of those suggestions worked. Although, now that you mention it, the last driver update I did was about a month ago, and I couldn't find supported drivers for Win7 at that time. So I suppose the issue could stem from that, although it seems like such an odd way for driver incompatibility to manifest itself. Anyway, I'll do a check later for new drivers again and see what happens. I'll post the end result if it's a positive one.

[microdev]

@microdev--hate to say it, but none of those suggestions worked. Although, now that you mention it, the last driver update I did was about a month ago, and I couldn't find supported drivers for Win7 at that time. So I suppose the issue could stem from that, although it seems like such an odd way for driver incompatibility to manifest itself. Anyway, I'll do a check later for new drivers again and see what happens. I'll post the end result if it's a positive one.

Bad to read. Did you also try changing the combiner type under the DirectX tab?

The latest driver seems to be catalyst 9.9 Do you have that one installed? Download can be found here.

Btw. What happens, if you replace the background texture by an external one? Maybe even by itself? Does that cause any changes to that effect?

I just have Windows XP & therefore can't test anything under Windows7

[Cyberman]

Wouldn't be the usage of a database a little bit too much? The files are already cached in a searchable list in memory. Thus, I don't see a need to put effort in that so far. Furthermore, how would you like to manage to add and remove textures from this database? Might become hard for retexturers...

It seems like a lot, however if you consider what you are doing, it's a very specialized DB with indexing (or should I say the pivot data) being the CRC check. And it would be silly to do something like that with a 'full fledged' db engine, or would it? There are DB engines that only occupy 256K compiled in 64bit x86 code. Compared to the rest of the plugin that is a small increase. The aforementioned db is almost a complete SQL engine.
Mostly I want to test the feasibility (hence some bits of work) of handling the data this way.

But I completely agree with you, that something like CoolSmoky apparently did would be a cool thing. Meaning packing all texures to a single, compressed file for releasing them. Also adding texture compression would be very nice as it would drastically speed up the loading and would use less disk and VRAM space.

If the db engine handles the caching for you... think about it. After having a standardized set of data that people CAN distribute (the textures can be dumped as the data is matched).

Don't worry, no pressure. Even if you don't succeed at all, nobody will blame you. I can tell you, where to hook it in. The commented code should also help you a great deal with that.

Indeed I still need to check out the code via SVN. The first phase is merely to get it to work with the plugin. If the code where the old TMEM bug was found is commented, generating both sets of CRC's can lead to creating a cross reference. Actually dumping the image data is not necessary (psuedo dump I guess?) One just needs depth CRC (prior to ... where it was fixed) CRC (whatever version it is now) Height width and palette information (not the actual palette).
Fortunately this kind of data is easy to generate and doesn't occupy large tracks of disk space (certainly smaller than the original ROM image).

There are a lot of possibilities. As I said first get something that works. Then one can worry about managing data. It's getting the right data that is important.

Cyb

[microdev]

If the code where the old TMEM bug was found is commented, generating both sets of CRC's can lead to creating a cross reference. Actually dumping the image data is not necessary (psuedo dump I guess?) One just needs depth CRC (prior to ... where it was fixed) CRC (whatever version it is now) Height width and palette information (not the actual palette).
Fortunately this kind of data is easy to generate and doesn't occupy large tracks of disk space (certainly smaller than the original ROM image).

There are a lot of possibilities. As I said first get something that works. Then one can worry about managing data. It's getting the right data that is important.

No, if I remember right, I have not yet commented the part that is concerned by the TMEM-bug. But I'll do so as soon as I get some time again. So far I just started commenting TextureFilters.cpp - that's the "class" that manages hires loading, dumping, etc.

Concerning the TMEM-bug, I intended to fix it & simply generate 2 alternative palette CRCs for each 4bit texture. Then, if no hires replacement can be found with the correct palette CRC, the system will try to find one with the alternative (incorrect CRC). This way, old texture packs will still be supported & new dumps will be correct, regardless the TMEM-flag.

One could even assume that if one 4bit CRC of a pack is right or wrong, this will also be the case for the remaining ones & load any subsequent 4bit texture directly with the same CRC type. This would gain some speed but might fail, if the textures have been dumped by different persons.

EDIT: now as I reread your post, I guess that's more or less exactly, what you described?

[vinipsmaker]

... Furthermore the source code has to be documented for
allowing a better understanding. All applied changes have already been documented - more to come. ...

What documentation tool will you guys use?
I think doxygen is a good tool.

• C learned
• SDL learned
• Learning C++, soon I will contribute

[Enzo Dragon]

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.

[new_profile]

Wouldn't be the usage of a database a little bit too much? The files are already cached in a searchable list in memory. Thus, I don't see a need to put effort in that so far. Furthermore, how would you like to manage to add and remove textures from this database? Might become hard for retexturers...

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.

Cheers.

[ditto_n]

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.