Page 2 of 17 FirstFirst 123412 ... LastLast
Results 11 to 20 of 162
  1. #11
    EmuTalk Member
    Join Date
    Dec 2002
    Posts
    281
    Mentioned
    1 Post(s)
    Quote Originally Posted by Chieftain459 View Post
    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.

  2. #12
    EmuTalk Member
    Join Date
    Dec 2002
    Posts
    281
    Mentioned
    1 Post(s)
    Quote Originally Posted by Cyberman View Post
    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.

    Quote Originally Posted by Cyberman View Post
    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.

  3. #13
    EmuTalk Member
    Join Date
    Jul 2009
    Location
    North Carolina, US
    Posts
    323
    Mentioned
    0 Post(s)
    @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.



    • Advertising

      advertising
      EmuTalk.net
      has no influence
      on the ads that
      are displayed
        
       

  4. #14
    EmuTalk Member
    Join Date
    Dec 2002
    Posts
    281
    Mentioned
    1 Post(s)
    Quote Originally Posted by Chieftain459 View Post
    @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

  5. #15
    Moderator Cyberman's Avatar
    Join Date
    Nov 2001
    Posts
    1,914
    Mentioned
    1 Post(s)
    Quote Originally Posted by microdev View Post
    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.
    Quote Originally Posted by microdev View Post
    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).

    Quote Originally Posted by microdev View Post
    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
    Progress (n.):
    The process through which the Internet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.
    -------------------------------------------------------------------
    Recursive (adj):
    see Recursive

  6. #16
    EmuTalk Member
    Join Date
    Dec 2002
    Posts
    281
    Mentioned
    1 Post(s)
    Quote Originally Posted by Cyberman View Post
    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?
    Last edited by microdev; October 16th, 2009 at 00:00.

  7. #17
    C/C++ programmer, emacs user
    Join Date
    Mar 2009
    Posts
    33
    Mentioned
    0 Post(s)
    Quote Originally Posted by microdev View Post
    ... 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
    Sorry by my bad english.

  8. #18
    STFU, NAVI Enzo Dragon's Avatar
    Join Date
    Jan 2006
    Location
    Charon, Pluto's Moon
    Posts
    223
    Mentioned
    0 Post(s)
    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.

  9. #19
    EmuTalk Member
    Join Date
    Oct 2002
    Posts
    39
    Mentioned
    0 Post(s)
    Quote Originally Posted by microdev View Post
    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.

  10. #20
    EmuTalk Member
    Join Date
    Feb 2006
    Posts
    2
    Mentioned
    0 Post(s)
    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.

Page 2 of 17 FirstFirst 123412 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •