Aristotle's Mudlord & Rice Video

I can't get it to compile at all with DirectX 9, even when I choose Release DX9 as the build mode. Unresolved externals.

This is the first out of 7 errors (which are all located in 2 externals: TextureFilters.obj and Render.obj):

Unresolved external symbol _FreeBMGImage referenced in function "bool __cdecl LoadRGBBufferFromPNGFile (char *,unsigned char * *,int &,int &,int)" (? LoadRGBBufferFromPNGFile@@YA_NPADPAPAEAAH2H@Z)

The DirectX9 builds cause memory allocation problems with pj64, so i don't recommend using them.

I saw the thread in the hi res retexturing section linking to this.

I didn't even know this plugin was still being worked on. I haven't read the entire thread yet, but I'm just here to show my support! I wouldn't mind being a beta tester too if it's being offered.

Hi guys,

Ok, I understand the situation with mudlord. I hope his new projects work out well for him.

I did some testing for the loading of textures. It appears that this version of the plugin simply won't load textures larger than 4x the original texture size. I reduced the size of my "new" textures to check this and they loaded.

Example: A texture with an original size of 32x32 can only be up-sized to 128x128, and a 64x64 only up to 256x256.

I think this is most likely because the source version is older (ie: not 6.1.4) and does not (yet) have the ability to load hires textures larger than 4x the original texture size.

Maybe someone can help you add the ability to load larger texture sizes up to (32x or 64x?) like it is in 6.1.4?

I am still not perfectly clear on if the source for 6.1.4 has been lost, or if it may still be available?

Anyway, these were my findings and I hope they help you out.

Jay

PS: Hey Terranigma, Nice to see you and thanks for the support!!! To be a beta tester all you have to do is download the latest releases and try them out with your game of choice. Try to stick to the topic/issues at hand. ie: the issues we are currently working on such as hires texture loading, texture cache/loading speeds, DRAM CRC texture name bug related slowdown, ect... (not know GFX or emulation issues at this time so as not to overwhelm the dev team ).

I believe 6.1.4 source poofed with bounty source.
Also mud had a system crash or he accidentally deleted the files the brain forgets these things easily.

So it is what it is I suppose I don't believe I religiously retrieved source versions of the plugin like I should have. In fact I'll have to look if I have any source (sigh). Looks like I only have 6.1.1 beta (ick).

Erstwhile here are my suggestions. Religious backups <--
I recomend daily backups myself (I make automatic ones that are date and time branded for serious projects). Back up to a seperate machine on a network or a USB drive. Doesn't matter. WRite a script to do this (I did it's not hard) and put it in your scheduler in windows. This means you'll have a lot of backups of the same stuff, those you can delete ( I do) if you don't update for a week. However it's backed up and cheap insurance.

Daily backups are also good for making mistakes and finding them fast. Use beyond compare or similiar utility to do comparisons to see what you might have hosed.

Yes I do have experience, I work on things that have to work or someone dies, quite a bit of responsibility there. So my backups are religious every change has to be carefully thought through and documented. It's not fun in fact it's kind of tedious. (sigh)

Erstwhile if you don't wish to redo something or find out what you need to unfix then use the backup method I metnioned. You may also wish to start adding doxygen commenting to the source. If you need help with this ask me, I've done some extensive use of doxygen. It works very well but you have to use it and understand how it works.

Releases need to be very carefully documented as well. IE what is changed and when. This isn't just for you but for the next person in lines. If you can move the project to source forge and use the SVN clients with it regularly. Keep several branchs maintained and keep a local set of backups on your back up HD.

I can help with some commenting and some doxygen. Do not get the idea that source code can be self documenting, personal experience has shown that this doesn't work well. I've also found a lot of other people concluded the same (wow hehehe). If you need some doxygen additions let me help you. I've used it for 18 months, it works, if you know how to use it. Also it gives you an amazing view of your code how it flows etc. This is extremely important if you are trying to figure what is going on in your code. Of course some of the call diagrams can drive you nuts.

Again if you need help ask, I can help some, not in terms of coding but helping documenting the code yes. That at least I have a lot more experience with than that nuts and bolts of the plugin.

As for 6.1.4 call it gone, mostly because the amount of work to find out what was done is greater than the amount of work needed to redo it.

I also suggest getting some sort of over all documentation on how the plugin works (not like Zilmer's spec), in terms of what data is loaded, when it is loaded and what it is used for. It's boring stuff I know but it will reveal errors in the methods used likely. That is a good thing I always say.

That's the best I can do. There were some interesting plans brewing as well but what is more important is to have the code with commenting and documentation then more people can work on it. That's my 2 cents. In fact documentation is probably more important than fixing bugs. It will make bug fixing much easier in the long run. Not sure how long or how much work it is.

Most importantly have fun.

Perhaps sitting down and having a strategy meeting 'it's an expression' on how to proceed will help you resolve what to do first? Having direction helps.

I do have a source forge account as well.

The source was last viewed on 8-20-2007 (wow long time ago). I don't believe I have anything other than binaries otherwise. I can't remember if I had trouble getting the source or something equally silly.

Cyb

Also mud had a system crash

Click to expand...

Yes, had a system crash, lost all changes.

As for 6.1.4 call it gone, mostly because the amount of work to find out what was done is greater than the amount of work needed to redo it.

Click to expand...

Okay,

* Changes to TextureFilter.cpp to allow for greater scaling factors. Mupen64Plus code branch in thier SVN has support for abitrary scale factors for textures, like GlideHQ as, as long as textures are in a power of two.
* Added extra filters. Look at GlideHQ source code for my implementations of HQ2xS and LQxxS and backport then. Isn't hard. Any coder with half a brain can do it.

Ok, I understand the situation with mudlord.

Click to expand...

I don't understand how the hell you know what happened. Anyway, I am glad you know what happened, I think. Or something :huh:

And thanks. New projects are going fine. Halo - Combat Evolved engine reverse engineering is coming along very well as Squall knows, as well as other RE projects. Already wrote a custom patch and keygen engine, as well as other reverse engineering efforts.....:whistling



...And.


Nice to see some texture optimizations working at least. Kudos. :freak:

Dunno if I can stick around......

Awesome! Thank you.

Stick around.

Later,
Jay

PS: I hope everyone's having a happy new year! arty:

In the source code, can someone explain what: does if FreeBMGImage() is defined as: ? Wouldn't it be the equivalent of: struct BMGImageStruct *img = &img; ?

I think what the coding is trying to do is make a blank structure in img's place, but the coding does not make sense at all. It wants to make a new BMGImageStruct structure at the memory address pointed by the memory address of img? I'm confused.

I think fixing this could even fix the memory issues with DirectX 9. I removed all calls to FreeBMGImage and ReadPNG and ReadJPEG and all other hi-res texture reading calls from the source, and it compiled successfully, and when I ran it in PJ64, it showed DX9 Version on its name, and in game there's no additional lag from your DX8 version that came with the zip file, and no new graphics glitches or anything.

Checking "Load hi-res textures if available" of course did not actually load any hi-res textures (but it still shows the white text on the black background that it was loading them).

Edit: Actually yeah, FPS dropped from 280fps to 180fps when I loaded a save state in the Deku Tree between the DX9 build I compiledand the (Stable) DX8 build that came with the zip.

I still have high hopes though...? Maybe.

I think what the coding is trying to do is make a blank structure in img's place, but the coding does not make sense at all. It wants to make a new BMGImageStruct structure at the memory address pointed by the memory address of img? I'm confused.

Click to expand...

I'd advise you learn more about C before even attempting to help. Sorry for being rude, but I really don't think editing this plugin is up for newbies. In places, a working knowledge of C++ is needed to understand how the plugin works. Take for instance the DeviceBuilder class.

Well OK, but can you just answer if I was right or not about

void BMG_EXPORT FreeBMGImage( struct BMGImageStruct *img );
FreeBMGImage(&img);

being the same thing as

struct BMGImageStruct *img = &img;

? I don't wanna have that question stuck in my head for a long time.

Here is a nice thing on structs:
http://irc.essex.ac.uk/www.iota-six.co.uk/c/h4_structs_part_3.asp

Maybe then you can work out the answer yourself

I honestly hate having to do people's homework......I rather people have some initiative and try to learn something.


Also:
http://irc.essex.ac.uk/www.iota-six.co.uk/c/

I appreciate your guys' effort so much.

Aristotle,

I did try my original pack. I have kept backups of my work regularly. I have a collection of micro SD cards and USB drives full of them!

That's what led me to think that it was the sizing.

I loaded up my original pack and it worked. Then I chose an easy to identify 128x128 (64x64 original size) texture from that pack and just upsized it to 1024x1024. It disappeared in game. So I made it 512x512 and it was still missing. Then I made it 256x256 and it reappeared in game.

Then for cross checking I took the same texture from my "latest as is" pack (that was a size of 1024x1024) and pasted it into my original release pack. The texture again disappeared in game. So I did the same thing with this texture...made it 512x512. Still missing of coarse, so I made it 256x256 and it then appeared in game.

Mudlord just confirmed it. This version of the plugin only has the ability to load textures up to 4x the original texture size.

Try it by downsizing any large texture from my newest pack to 256x256 or 128x128 (it depends on what the original texture size is) and let me know if it appears in game.

Note: 1964 won't reload the textures with just a SS reload (F7) even though the "white text on black background showing checking of hires textures" shows up and cycles through.

You will need to go into the video settings GUI and uncheck "load hires textures", and click OK to return to game, then go back to the GUI and re-check "load hires textures", and click OK again to return to the game where the texture will now show. This is just for 1964 I have found.

The save method I use in Photoshop is: Merge Visible, CTRL-S. (oh, and I never use/allow a background layer, not sure if it matters though, I just don't like locked "background layers" )

Let me know if it works and thanks again,
Jay

mudlord88 said:

Here is a nice thing on structs:
http://irc.essex.ac.uk/www.iota-six.co.uk/c/h4_structs_part_3.asp

Maybe then you can work out the answer yourself

I honestly hate having to do people's homework......I rather people have some initiative and try to learn something.


Also:
http://irc.essex.ac.uk/www.iota-six.co.uk/c/

Click to expand...

Alright, thanks dude.

Also I'm mainly just trying to fix this release for myself. I get linker errors because of some of the functions in BMGImage.h so I want to actually fix this rather than completely remove them.

Although there is actually no point in even trying to compile and so this is a big waste of time. :whistling It's to cure my boredom.

Rice Video has had an off/on problem regarding loading textures 4x the original for as long as i've used it.

squall_leonhart said:

Rice Video has had an off/on problem regarding loading textures 4x the original for as long as i've used it.

Click to expand...

Hi squall,

Please explain?

Jay

Sometimes it would work, other times it wouldn't.

Its more to do with the capability of the video card however, and the texture sizes it is capable of loading.

Hints on the textures et al

First suggestion if the card can't handle big textures reduce and use more than one for the texture. This may require some extra code for splitting the texture and rendering the multiple textures onto the same surface.

Aristotle do you have a diff utility? I am going to attempt to start doxygen work on a few of the source files. My guess is this will take a while so I'll start with header files and work to cpp files eventually. I'm afraid it's not going to be fast work. I could add 2 files version.h and documentation.h
Version.h can contain ... version information (shocking isn't it?) I don't know what good creating version information for older versions will do so I guess I can start with the now. I can set up the version data in that file.
Documentation.h is just how it sounds this generates the main page of the documentation, includes credits pundits (joke) and links to the version information.

I suppose after I run the first doxygen documentation test on the code I'll find out how doxy friendly it is.

In any case how do you want the 'doxy' commented code? I guess I could generate patch files (mumble). I'll include the doxygen setup file. It's better if you run Doxygen on your machine the files can get kind of big (especially the call trees which look more like a web at times).

Cyb