Page 1 of 17 12311 ... LastLast
Results 1 to 10 of 162
  1. #1
    EmuTalk Member
    Join Date
    Dec 2002
    Posts
    282
    Mentioned
    1 Post(s)

    1964Video - official DevTalk & Release thread

    Name: 1964Video
    Type: N64 Emulator video plugin (under community development)
    Licence: GPL 2.0
    Targeted: All 1964 emulator users
    Supported Emulators: All windows-based emulators with plugin support (1964, Project64, Mupen64plus)
    Requirements: MS C++ Redistributable Package


    Latest Download: http://www.emutalk.net/threads/54166...munity-version
    Release Date: 10/14/2009

    Source Code: Google-Code SVN

    BUGS: PLEASE CHECK THE ISSUE LIST BEFORE REPORTING A BUG!



    Changelog:
    r35
    • added support for a WIP folder for enabling the reloading of newly designed
      textures of retexture artists. WIP has to be a direct subfolder of the main
      folder of the hires pack. Nested folders are possible
    • fixed a bug with texture dumping
    • fixed the counter display for texture loading. Now it indicates the real
      amount of loaded textures and does not restart at 1 for each sub folder
    • adjusted displayed messages
    • added hint for caching option (forgot to port this from my private codebase
      last time)
    • started to comment the hires code in TextureFilters.cpp. It should now be
      veeery easy understandable even for beginners


    r30
    • CRC-fix avoids slowdown in Castlevania, Smash Brothers and probably other games, when hires is enabled
    • Support for static hires backgrounds as used in Zelda
    • Experimental texture caching (check options). This has still improvement potential (texture compression)
      but might nevertheless be quite usefull with large hires textures
    • No rechecking and reloading (in case of enabled caching) of hires-textures. if a savestate is loaded or if you
      switch between fulscreen & window mode. This avoids nasty wait time
    • Fix to avoid crashing under Vista and Windows7
    • Some smaller things
    • Fixes ported from the Linux version of Rice



    Background:
    1964Video is based on the latest version of the Rice-plugin, meaning the version 6.1.4, which included some changes of Mudlord.
    Afterwards the community involvement started as Gitech requested some improvements for supporting the development of his
    Castlevania-LOD hires pack. Subsequently the plugin changed once again it's name to "Aristotle's Mudlord & Rice Video".

    Well, as you might have already guessed, adding the name of each author to the plugin name might become a little unhandy by
    the time. Thus the plugin had been renamed once again by death--druid to 1964Video and the source code has been transfered
    to an svn.

    Current situation:
    The development of the plugin has now moved from a one-man-show towards a (hopefully) community-driven approach. That way,
    we hope getting more people involved into actual development and to foster the progress of this great plugin, which - even if not yet
    being the most advanced one - was the initial plugin pushing N64 emulation to the next level by introducing hires texture support (Rice).

    The initial version of the plugin (r30, 10/10/2009) also contains some fixes, that have been applied by the folks of Mupen64plus, a multi
    platform N64 emulator, to the linux version of the Rice plugin (thank you guys!). Furthermore, some ideas have been taken from Glide64,
    which is the reference video plugin for 64 emulation atm (great work folks!).

    Aim:
    At first, the plugin has to be brought to a state that makes it easier accessible by potential new developers. Death-druid did with
    the transfer towards a maintained svn already the first step in that direction. Furthermore the source code has to be documented for
    allowing a better understanding. All applied changes have already been documented - more to come.

    The general target is of course the improvement of the existing plugin. As usually everyone just has a limited amount of time, he/she is
    able to dedicate to such leisure activities, additional developers are needed. Thus any interested dev is warmly invited to join up at the svn.

    Finally, it's of course all about having fun!


    This thread is meant for publishing the latest versions of the plugin, sharing information about development progress, obstacles, ideas to
    the community and for providing feedback regarding the releases towards the developers.

    This thread is not meant for nagging about "when do you release" or "when do you support". I guess feature requests should be allowed but
    don't expect a guarantee for implementation. If you really badly want it, it's community-driven - you are free to do it yourself. Please always
    keep in mind, if the devs lose the fun and therefore interest, you'll lose the contribution.
    Last edited by death--droid; January 23rd, 2013 at 12:05. Reason: updated plugin to r35


    • Advertising

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

  2. #2
    Moderator Cyberman's Avatar
    Join Date
    Nov 2001
    Posts
    1,917
    Mentioned
    1 Post(s)
    I'll be sure to enforce no questions about release dates.

    A suggestion add a method to print/list the users configuration (including video card) with a single button click in the plugin (Linux variant inclusive). This should vastly improve debugging.

    Bug reports that qualify as bugs should be given numbers, (perhaps a nice list post of bugs and what they relate too how old etc and if it's been fixed like bugzilla provides). Many nuisance posts occur when the user has a misconfigured plugin instead of a bug. Any ideas how to reduce this? The only suggestion I have is look at the official bug list first before posting.

    What should be done with posts that are bugs already reported?

    An idea, with known bugs suggestions can be placed in hints when the user attempts to configure the plugin. The hints can be generated from tested bug reports and work around for that particular version of the plugin.

    How do you plan on handling good bug reporting? Something like bugzilla? It would be good to set ground rules for people to follow. Direction is always good when people aren't sure what to do. Can I assume one person is in charge of examining changes? (always seemed like a goo idea)

    Erstwhile, I'll have to look if the code is more modular, I couldn't really find what I wanted to help with on the plugin without pulling more hair out. Perhaps this time around I can do so (LOL). In particular I wanted to change the way the textures were packaged, so it was easier for people making texture packs to release there data (instead of a pile of files dumped in directories). This would affect texture loading, CRC / checksum information and organization of the image dumping for retexturing.

    I am not sure what to do about being able to 'reload' older TP's that have improper CRC's and the such on them to make them migratable to newer variants of the plugin.

    Cyb - let me know the will of the developers
    Last edited by Cyberman; October 13th, 2009 at 02:54.
    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

  3. #3
    EmuTalk Member
    Join Date
    Dec 2002
    Posts
    282
    Mentioned
    1 Post(s)
    Quote Originally Posted by Cyberman View Post
    A suggestion add a method to print/list the users configuration (including video card) with a single button click in the plugin (Linux variant inclusive). This should vastly improve debugging.
    Good idea. I'll create an issue for that. It's not on my high priority list atm but nevertheless very helpful.

    Quote Originally Posted by Cyberman View Post
    Bug reports that qualify as bugs should be given numbers, (perhaps a nice list post of bugs and what they relate too how old etc and if it's been fixed like bugzilla provides). Many nuisance posts occur when the user has a misconfigured plugin instead of a bug. Any ideas how to reduce this? The only suggestion I have is look at the official bug list first before posting.
    google-code provides an issue management. Thus I think this could be used for tracking bugs. I'll add the direct link to the first post.

    Quote Originally Posted by Cyberman View Post
    What should be done with posts that are bugs already reported?
    I fear this kind of posts is inevitable. Deleting might cause the next one posting the same, wich might result in a lot of work for the mods. The only way I see is stressing the users to have a look at the buglist first.

    Quote Originally Posted by Cyberman View Post
    An idea, with known bugs suggestions can be placed in hints when the user attempts to configure the plugin. The hints can be generated from tested bug reports and work around for that particular version of the plugin.
    The idea is good but I guess virtually no one will read the hints.

    Quote Originally Posted by Cyberman View Post
    How do you plan on handling good bug reporting? Something like bugzilla? It would be good to set ground rules for people to follow. Direction is always good when people aren't sure what to do. Can I assume one person is in charge of examining changes? (always seemed like a goo idea)
    please see above and yes, a kind of "change manager" would be great.

    Quote Originally Posted by Cyberman View Post
    Erstwhile, I'll have to look if the code is more modular, I couldn't really find what I wanted to help with on the plugin without pulling more hair out. Perhaps this time around I can do so (LOL). In particular I wanted to change the way the textures were packaged, so it was easier for people making texture packs to release there data (instead of a pile of files dumped in directories). This would affect texture loading, CRC / checksum information and organization of the image dumping for retexturing.
    Well, the code structure did not really change in the meantime. But most changes applied by me have been commented. As soon as I got time, I will comment the rest of them and especially the hires handling part. It should not be too hard to understand it, then.

    What are you planning to do? If the textures are simply packed, it would not affect the checksum information. I think adding texture compression, would be a very required issue. It would reduce the size of texture packs and in case of activated caching also the size of occupied memory and finally would reduce loading time.

    We are really looking forward to your contribution. In case of any open questions concerning the code, simply contact me & I'll do my best to help.

    For joining the project, simply send me or death-droid an email address via PM.

    Quote Originally Posted by Cyberman View Post
    I am not sure what to do about being able to 'reload' older TP's that have improper CRC's and the such on them to make them migratable to newer variants of the plugin.
    If you are refering to the TMEM bug, I have already a possible solution in mind. I even started implementing it. I just have to find my code back as it was some month ago, before I left for my thesis.

  4. #4
    EmuTalk Member jmf145's Avatar
    Join Date
    Mar 2006
    Posts
    57
    Mentioned
    0 Post(s)
    Dumb question:
    Will this work with PJ64? or is just for 1964?

  5. #5
    EmuTalk Member
    Join Date
    Dec 2002
    Posts
    282
    Mentioned
    1 Post(s)
    Quote Originally Posted by jmf145 View Post
    Dumb question:
    Will this work with PJ64? or is just for 1964?
    Dumb answer: None of both, you have to download it as an app to your i-Phone.

    Serious answer:
    Quote Originally Posted by microdev View Post
    Supported Emulators: All windows based emulators with plugin support
    (Post 1, line 5) That means yes. In some way you're right, the name might be misleading. I've now listed the emulators to further clarify this.
    Last edited by microdev; October 13th, 2009 at 14:42.

  6. #6
    EmuTalk Member
    Join Date
    Jul 2009
    Location
    North Carolina, US
    Posts
    323
    Mentioned
    0 Post(s)
    Quote Originally Posted by microdev View Post
    Hmm, bad to hear - especially that it is not working for the ones, that might be capable of creating the new backgrounds. "still appear as green and black static" - does that mean, the original backgrounds had problems as well?
    Also. do you use OpenGL or DirectX?

    could you please answer and also describe your system specs in this thread?

    Has anyone else problems with loading static backgrounds?
    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

  7. #7
    Moderator death--droid's Avatar
    Join Date
    Feb 2008
    Posts
    1,271
    Mentioned
    2 Post(s)
    An odd problem there Chieftain459, may be a problem with your graphics card or a bad rom dump.
    If you appreciate some of the work I do, all donations are greatly appreciated


    System Specs: CPU: AMD FX 8350 4.0ghz 8-core, RAM: 2 x 8gb Corsair Vengeance DDR3, GPU: AMD Radeon R9 280x OC, System Drive: 120gb Samsung Evo SSD

  8. #8
    Moderator Cyberman's Avatar
    Join Date
    Nov 2001
    Posts
    1,917
    Mentioned
    1 Post(s)
    Quote Originally Posted by microdev View Post
    Good idea. I'll create an issue for that. It's not on my high priority list atm but nevertheless very helpful.


    google-code provides an issue management. Thus I think this could be used for tracking bugs. I'll add the direct link to the first post.
    I went to check and lo and behold that medium priority 'issue' was there.

    Quote Originally Posted by microdev View Post
    I fear this kind of posts is inevitable. Deleting might cause the next one posting the same, wich might result in a lot of work for the mods. The only way I see is stressing the users to have a look at the buglist first.

    The idea is good but I guess virtually no one will read the hints.
    Indeed (sigh).

    Quote Originally Posted by microdev View Post
    Well, the code structure did not really change in the meantime. But most changes applied by me have been commented. As soon as I got time, I will comment the rest of them and especially the hires handling part. It should not be too hard to understand it, then.
    It appears I am going to have to download the whole thing (LOL). Oh the travesty of it all (etc. etc. etc.)
    Quote Originally Posted by microdev View Post
    What are you planning to do? If the textures are simply packed, it would not affect the checksum information. I think adding texture compression, would be a very required issue. It would reduce the size of texture packs and in case of activated caching also the size of occupied memory and finally would reduce loading time.
    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.

    Quote Originally Posted by microdev View Post
    We are really looking forward to your contribution. In case of any open questions concerning the code, simply contact me & I'll do my best to help.

    For joining the project, simply send me or death-droid an email address via PM.
    That sounds like a reasonable method to proceed by. 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.
    Quote Originally Posted by microdev View Post
    If you are refering to the TMEM bug, I have already a possible solution in mind. I even started implementing it. I just have to find my code back as it was some month ago, before I left for my thesis.
    The biggest issue is of course matching old with new etc. Once you have a set of known dumped references it may also be possible to take older TP's and import the vast volume of data. Making complete dumps without the actual data is another possibility. Each Texture is known but not stored. This might be a handy way to not violate copywrite information and still share data for making new TP's based on prior dump sets.

    Lots of possibilities but I need to spend some time looking at the CRC and texture dump/load code then hopefully come up with a way to modularize it to facilitate the above concepts.

    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

  9. #9
    EmuTalk Member
    Join Date
    Dec 2002
    Posts
    282
    Mentioned
    1 Post(s)
    I've just uploaded r35 of the plugin. Please find download link and details concerning changes in the first post (there it will always be released)

    Main reason for this update was the support of a WIP folder for hires packs.

    As the plugin now does not reload the textures anymore when a savestate is loaded (to reduce waiting time), retexture artists had trouble to test their new textures.

    WIP solves this problem:

    For testing of new textures, simply create a direct subfolder in the texture pack folder. Any texture that is placed in this folder is reloaded, when a savestate is loaded
    (or if you switch between window mode and fullscreen). You can also place nested folders in the WIP folder.
    All textures contained in other folders of the texture pack folder won't be reloaded. I think that is the best compromise betweeen comfort for users and retexturers.

    The hires code is also now mainly commented & should thus not state a problem anymore to get common with it. I will continue commenting when I get time.
    If you summit any changes, please comment every line - even if you feel stupid doing so

    This will drastically help beginners to become common with the code.

    I'll respond to the other posts tomorrow. I have to go to bed now.

    microdev

  10. #10
    EmuTalk Member
    Join Date
    Apr 2005
    Posts
    863
    Mentioned
    0 Post(s)
    Thanks this will help greatly.

Page 1 of 17 12311 ... 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
  •