Page 1 of 15 12311 ... LastLast
Results 1 to 10 of 162

Hybrid View

  1. #1
    EmuTalk Member
    Join Date
    Dec 2002
    Posts
    281
    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,914
    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
    281
    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
    Moderator Cyberman's Avatar
    Join Date
    Nov 2001
    Posts
    1,914
    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

  5. #5
    EmuTalk Member
    Join Date
    Dec 2002
    Posts
    281
    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

  6. #6
    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.

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

  8. #8
    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.

  9. #9
    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?

  10. #10
    EmuTalk Member
    Join Date
    Dec 2002
    Posts
    281
    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.

Page 1 of 15 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
  •