What's new

1964Video - official DevTalk & Release thread

Status
Not open for further replies.

microdev

Member
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-Rice-Video-Community-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 a moderator:

Cyberman

Moderator
Moderator
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 :D
 
Last edited:
OP
M

microdev

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

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.

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.

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.

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.

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.

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.
 
OP
M

microdev

Member
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:
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:

Chieftain459

New member
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
 

Cyberman

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

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

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

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.
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
 
OP
M

microdev

Member
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
 
OP
M

microdev

Member
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.
 
OP
M

microdev

Member
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.
:eek: 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

New member
@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.
 
OP
M

microdev

Member
@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

Moderator
Moderator
:eek: 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
 
OP
M

microdev

Member
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:

vinipsmaker

C/C++ programmer, emacs user
... 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

STFU, NAVI
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

New member
:eek: 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

New member
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.
 
Status
Not open for further replies.

Top