What's new

Aristotle's Mudlord & Rice Video

Status
Not open for further replies.

microdev

Member
I'm sorry, DD. Then ALL (or some parts of) work did by Aristotle, Microdev and you in this new plugin will be remade in the lastest Mudlord Rice Video. Right, or wrong?

Yes, right - at least for the work that has yet been released. But that's as well no surprise as the goal has been to bring 6.1.2 to the state of 6.1.4 due to the invailability of the latest source code. Thanks to death--druid we don't have to bother about that anymore.:)

Nevertheless I strongly recommend to use 6.1.4 as basis of any further developments as it also contains some small fixes (e.g. concerning pic saving) that are not yet included in 6.1.2, 6.1.9 or any other (windows) derivative.

Compared to 6.1.4, the only real enhancements that have so far been added are:
fog (threshold changed) by Aristotle and the scanning of the hires directories to avoid dumping textures for which hires replacements are already existant by Death--Druid. (btw. does that one work now?)

There have been other addtions made to the plugin, that have not yet been released either because of missing time to port changes from development branch to release branch or as in case of the "bad texture dumps" (invalid palette CRC for 4bit textures dumped under Full TMEM emulation = on) due to the inavailability of material to test the changes.
 
Last edited:

death--droid

Active member
Moderator
Yes, right - at least for the work that has yet been released. But that's as well no surprise as the goal has been to bring 6.1.2 to the state of 6.1.4 due to the invailability of the latest source code. Thanks to death--druid we don't have to bother about that anymore.:)

Nevertheless I strongly recommend to use 6.1.4 as basis of any further developments as it also contains some small fixes (e.g. concerning pic saving) that are not yet included in 6.1.2, 6.1.9 or any other (windows) derivative.

Compared to 6.1.4, the only real enhancements that have so far been added are:
fog (threshold changed) by Aristotle and the scanning of the hires directories to avoid dumping textures for which hires replacements are already existant by Death--Druid. (btw. does that one work now?)

There have been other addtions made to the plugin, that have not yet been released either because of missing time to port changes from development branch to release branch or as in case of the "bad texture dumps" (invalid palette CRC for 4bit textures dumped under Full TMEM emulation = on) due to the inavailability of material to test the changes.

Well the hires texture replacement stuff might work now(Made some edits)
But i haven't had the chance to test it out due to crashing problems.

EDIT:

I have a feeling it has something to do with that directX 8.1 sdk we have being using :p

EDIT2:
I hope someone can find a solution to this so i can help out a bit more.
 
Last edited:

microdev

Member
Well the hires texture replacement stuff might work now(Made some edits)
But i haven't had the chance to test it out due to crashing problems.

EDIT:

I have a feeling it has something to do with that directX 8.1 sdk we have being using :p

EDIT2:
I hope someone can find a solution to this so i can help out a bit more.

Well, as I stated before, you don't have to reread the hires-folders as everything you need is already
in memory, namely in gHiresTxtrInfos. I added code to exclude hires textures from dumping.

If you badly need a fix, that should do the trick:

Code:
void DumpCachedTexture( TxtrCacheEntry &entry )
{
:
	CTexture *pSrcTexture = entry.pTexture;
	if( pSrcTexture )
	{
		// Check the vector table
		int ciidx;
		if( CheckTextureInfos(gTxtrDumpInfos,entry,ciidx,true) >= 0 )
			return;		// This texture has been dumpped
		else if( CheckTextureInfos(gHiresTxtrInfos,entry,ciidx,true) >= 0 )
			return;		// This texture already exists as a hires version, thus don't redump it.
:

(Function is located in TextureFilters.cpp)

microdev
 

vinipsmaker

C/C++ programmer, emacs user
I will learn programming now, then I will be a bit away from the project for while, but when I back, I will do more than documentation. And I added this file (TMEM CRC ...) in the google code aristotle video page.
 

death--droid

Active member
Moderator
Well, as I stated before, you don't have to reread the hires-folders as everything you need is already
in memory, namely in gHiresTxtrInfos. I added code to exclude hires textures from dumping.

If you badly need a fix, that should do the trick:

Code:
void DumpCachedTexture( TxtrCacheEntry &entry )
{
:
	CTexture *pSrcTexture = entry.pTexture;
	if( pSrcTexture )
	{
		// Check the vector table
		int ciidx;
		if( CheckTextureInfos(gTxtrDumpInfos,entry,ciidx,true) >= 0 )
			return;		// This texture has been dumpped
		else if( CheckTextureInfos(gHiresTxtrInfos,entry,ciidx,true) >= 0 )
			return;		// This texture already exists as a hires version, thus don't redump it.
:

(Function is located in TextureFilters.cpp)

microdev


:p

I don't have a problem with that.
I have a problem with the whole texture enhancement side of the plugin as it causes the emulator to crash for me (With every emulator):(.
The most i know about the crashing is that it is a Access Violation.
(I'm using Windows Vista 32 bit)
 

microdev

Member
:p

I don't have a problem with that.
I have a problem with the whole texture enhancement side of the plugin as it causes the emulator to crash for me (With every emulator):(.
The most i know about the crashing is that it is a Access Violation.
(I'm using Windows Vista 32 bit)

I see. Sorry, I can't help you with that as I don't use Vista and by sure never will. Under XP I don't have any access violation.

But what you can do is to track down the access violation. Shouldn't be too hard as the hires part just concerns two classes: TextureManager.cpp/h and TextureFilters.cpp/h

As the debug version is not working with hires, I can send you my logger class for tracking down the source of the error, if you want.
 

death--droid

Active member
Moderator
I see. Sorry, I can't help you with that as I don't use Vista and by sure never will. Under XP I don't have any access violation.

But what you can do is to track down the access violation. Shouldn't be too hard as the hires part just concerns two classes: TextureManager.cpp/h and TextureFilters.cpp/h

As the debug version is not working with hires, I can send you my logger class for tracking down the source of the error, if you want.

Hmm i might try running it on the xp computer in this house then :p.
If you tell me how to use the logger class ....Sure :)

EDIT:
microdev did you want to join the svn???
If you do just send me you hotmail or gmail and I'll add you as a admin :)
 
Last edited:

Rice

Emulator Developer
As the debug version is not working with hires

I am wondering why no one simply opens the DEBUG project in visual C++, hit the F5 key to run with debug it. Then Visual C++ shall stop right at the line of the source code where it crashes.
 

death--droid

Active member
Moderator
I am wondering why no one simply opens the DEBUG project in visual C++, hit the F5 key to run with debug it. Then Visual C++ shall stop right at the line of the source code where it crashes.

Mine didn't for some odd reason :(
It said something about symbol files

But it did come up with this

> ntdll.dll!77645844()
[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
kernel32.dll!75e1c56f()
msvcr90.dll!717738bb()
d3d8.dll!6480805b()
Aristotle Video.dll!02e43404()
Aristotle Video.dll!02e6da07()
Aristotle Video.dll!02e6118f()
Aristotle Video.dll!02e6f439()
Aristotle Video.dll!02dcbdad()
Aristotle Video.dll!02dcbf48()
RSP.dll!01fe22d8()
Project64.exe!004201f0()
Project64.exe!00433717()
kernel32.dll!75e14911()
ntdll.dll!7761e4b6()
ntdll.dll!7761e489()

EDIT:

Woops just realized i wasn't using the debug version XD
But now i cant seem to get the debug version to work :(
 
Last edited:

microdev

Member
I am wondering why no one simply opens the DEBUG project in visual C++, hit the F5 key to run with debug it. Then Visual C++ shall stop right at the line of the source code where it crashes.

I didn't because I am not common to the VC++ IDE. I thought I can't start it there as it's a library not an exe & there does not seem to be a JIT-Debugger shipped with the express edition.

But as I read your post I gave it another try & realized that you can attach the debugger to a running process & this works like you described.

It really indicates the line of code at which the app was crashing.

Wow, thanks a lot for this hint Rice, this drastically eases debugging!

Now C++ begins to feel like Java...;)
 

microdev

Member
Latest Mudlord source code (6.1.4) with fixed debug mode. Now it should work w/o crashing.
Maybe this fixes the crashing problems under Vista as well?

Download

Note: This is only of worth to the developers. It contains none of my additions (besides the debug fix).
Before I will release my additions I will send them to gitech for testing (when finally ported...) as a
untested, buggy release would cause more trouble than joy.
 

vinipsmaker

C/C++ programmer, emacs user
Latest Mudlord source code (6.1.4) with fixed debug mode. Now it should work w/o crashing.
Maybe this fixes the crashing problems under Vista as well?

Download

Note: This is only of worth to the developers. It contains none of my additions (besides the debug fix).
Before I will release my additions I will send them to gitech for testing (when finally ported...) as a
untested, buggy release would cause more trouble than joy.

Your file is on:
http://code.google.com/p/aristole-video/downloads/list

The google code aristotle site will has all related downloads while I be in the team.
 

gitech

N64 Artist
Awesome!

This will be a major milestone for the project.

I can't wait to see what's next for the plugin from the great team we have on this project!

:) ,
Jay
 

microdev

Member
Your file is on:
http://code.google.com/p/aristole-video/downloads/list

The google code aristotle site will has all related downloads while I be in the team.

ok. But I think this should not just be hosted there as a download. It should replace the existing codebase of the repository as this is for now the most advanced source code which is public available.

So I strongly recommend that death--druid or whoever has permissions to do so replaces the existing code base by the one I posted.

Furthermore it would be nice if someone could compile it and check if it is now working under vista.

thx,

microdev
 

death--droid

Active member
Moderator
ok. But I think this should not just be hosted there as a download. It should replace the existing codebase of the repository as this is for now the most advanced source code which is public available.

So I strongly recommend that death--druid or whoever has permissions to do so replaces the existing code base by the one I posted.

Furthermore it would be nice if someone could compile it and check if it is now working under vista.

thx,

microdev

:p
Deleting the old code now :p
I'll try out you're source code as well while I'm at it.


EDIT:
w00t tested with 1964.

Working with Windows Vista with textures loaded :)


Tested with Project 64

Working with Windows Vista with textures loaded :)(Only problem is the debug panel didn't work properly(Might be my fault))

EDIT2:
Also the new source code has being uploaded.
 
Last edited:

microdev

Member
Great. So you can also close the critical issue concerning the Vista-crashing on the issue tracker.

What problem do you have with the debug console under Project64?
 

death--droid

Active member
Moderator
Great. So you can also close the critical issue concerning the Vista-crashing on the issue tracker.

What problem do you have with the debug console under Project64?

It won't show up :p

I'll get that hi res scanning thing added asap :)
Also one question should it be allowed to be deactivated.
And did you want full tmem emulation stuck on.
 
Last edited:

microdev

Member
It won't show up :p

I'll get that hi res scanning thing added asap :)
Also one question should it be allowed to be deactivated.
And did you want full tmem emulation stuck on.


great. Maybe you want to try the solution I proposed a view posts ago concerning the caching. I think these 2 lines of code do the job as the correponding hires texture description should already be in memory at the time of dumping.

I'm not sure what you mean with your question concerning the full TMEM emulation.

Concerning PJ64: That's strange as it works flawlessly for me & if it shows up under 1964, it should absolutely as well hat to show up under PJ64 as it depends on the plugin not the emu. Are you sure that you compiled it in debug mode & that you have selected the right plugin in the graphic section of PJ64?
 
Status
Not open for further replies.

Top