What's new

Rice's Plugin Source <discussion>

rabiddeity

Plugin Hacker
Not quite yet, you need to replace "long long int" with "__int64" and there are a couple other issues. If you don't mind, I'll fix them in one commit as soon as I get it to compile without warnings. If you have any problems with the commit, feel free to roll it back.

One more thing, please move the BMGLib stuff into the trunk. In other words, move the /bmglib/lib folder to /trunk/lib, make sure the .h files are in there, put the .lib file exactly where it needs to be, and then make sure the /bmglib tree is gone from the root; basically, if you need it to compile the code, it should go into the trunk. (Putting it under version control also ensures we're all working with the same version of the lib files too.) That way anyone can pull the trunk and compile and it should work.

edit: still getting linker errors from VS .NET, from the BMGLib.lib file posted. Gonna see if I can work it out on my own.
 
Last edited:

mudlord

Banned
I performed that subversion management task.

I really don't mind what changes you make. :) Having support for more compilers just opens up the opportunities for more devs to get involved. :)
 

rabiddeity

Plugin Hacker
I performed that subversion management task.

I really don't mind what changes you make. :) Having support for more compilers just opens up the opportunities for more devs to get involved. :)

Got it, needed to change the project's default calls from __fastcall to __cdecl. That fixed some things, but now I've got some other errors to wade through. I'll get back to you.
 

Cyberman

Moderator
Moderator
so, we are saying we keep the games original calculations for depth and ratio, but we do it on the graphics API end, so the game has zero idea what happened???
Right the game keeps all it's information the same, the API handles the extra stuff to the side. Although depending on how the game implements cliping we might have to do some cliping adjustments. Might be good to try this on a complete 3d games first like CBFD Super Mario 64.

Another thing to check would be the screen's aspect ratio For example my one of my Samsung's is a 4:3 display with 1280x1024 resolution the other is 1440x810. If you know the native display resolution and actual aspect ratio this helps immensly making the image look right. (ACK that reminds me I need to adjust my Xwindows aspect ratio to 16:9 I've had this stupid thing almost a Year and haven't changed my X display settings LOL).

Argh it looks like source forge changed to SVN 1.4 without warning people or someone else did on a project. What a pain. I hate it when people update and make everyone else update as a consequence.

Cyb
 

rabiddeity

Plugin Hacker
Yay, I got it to compile under DX9!

OK, here's what I needed to change:

BMGLib.lib file-- I needed to recompile it. Your version included calls to ftol2_sse (needs to link to libcntpr.lib). You should remove the driver DDK from your include path when compiling BMGLib, or specifically tell your IDE to ignore it. I compiled with just Windows SDK and DirectX 9 SDK as my include paths. This should make it possible to compile without requiring libcntpr.lib (and as a nice side benefit not require kernel calls), and will hopefully still work on your system. I'll hold off on pushing this to the server for now, because it seems to be giving me duplicate symbol errors under DirectX8 compile.

Calling conventions: changed all from __fastcall to __cdecl. If you had tried to compile a debug binary, you would have run into this issue as well. We might be able to switch this back later, but since the BMGLib.dll file is compiled on __cdecl, we need to call it like that. Changed in all the .vcproj files, including yours.

Removed references to $(Emu1964Dir) in .vcproj files, and replaced them with sane defaults.

Changed "Optimize for Windows Application" to FALSE in Video 7 and Video 7.10.vcproj; this will produce unstable code when used for a DLL.

Changed long long int to __int64 in UCodeDefs.h

Still doesn't link right under dx8 mode here, but I think it's because I lack the proper libraries or don't have something set up right.
 

rabiddeity

Plugin Hacker
OK, now that I can compile it, let's take a look at what needs fixin.

I'm looking at a slew of implicit conversion warnings, double to int and double to float. I've fixed a couple of them by changing exp to expf, things like that (change from funcs that take a double and return a double to funcs that take a float and return a float). It's no faster, but it at least shuts up some of the compiler warnings.

The rest that I didn't fix, well those involve taking an abs of a float or double and only requiring an int in return... if I remember properly there are a couple functions in the Mesa library that do those sort of things really fast. I'd rather use those than (int) casting, which is dog slow, so I'll leave those alone until we can get an optimization team to look through it.

BTW, which functions in the video plugin are currently the slowest? The least stable? (This is a question for both the D3D and OpenGL portions individually.)
 
Last edited:

Cyberman

Moderator
Moderator
There are a few bugs in the plugin that aren't obvious in most games.
Resident Evil 2 brings MOST of these out. First there appears to be a depth sort issue with the background textures and 3d. Without hacking the game (gah), my guess is this has to do with another obvious bug in the game. Certain static 3d objects in the game are the original game size and location. The obvious one is when you enter the RDP and go to the computer you see this weird flickering spot on the screen that doesn't relate to anything in the evironment. Bullets and Ink Ribbon are correct and in the right place. Just not the monitor flicker. This isn't likely the games fault. :) As for depth on the display, hmmm not sure where this might be happening. Obviously it's NOT the game and ALL plugins have this issue last I checked.

My guess is there is some depth sorting issue and it's neglecting a 3d object or two that are implement uniquely in the game (flickering light objects only I might point out).

Wire Frame mode has a missing feature, or a bug, it doesn't clear the display between frames so it looks weird. Obviously textures etc aren't visable in this mode, so it might be good to clear the display between frames. Jabo used on is 1.6 Beta a nice features of making the textures transparent on 3d objects. This might be good for 2d surfaces all together.

Is there a dumping/debugging version of the updated plugin?

Cyb
 
Last edited:

rabiddeity

Plugin Hacker
You can compile as Debug but you probably want to compile against a Debug BMGLib; call it BMGLibDbg.lib

Does anyone have a version of d3dx8.lib they can send me? Newest DirectX SDK doesn't include it. Or should we just abandon the DX8 line? I don't think that's unreasonable, as everyone should have 9.0c by now, even the Win98 users.
 

mudlord

Banned
Here's a link for that D3DX8 lib file (and some others):

Here

I don't see the problem with dumping DX8 support, at least it will make the source code cleaner! (by not having seperate DX8 specific things) And besides, the DX9 code is quite stable and works from my testing...Only problem I can see
is people moaning about upped requirements, but meh.....Windows 95 support is deprecated by Microsoft anyway....:yawn:

Currently, the most severe problems in the plugin are:

* Framebuffers (easily the least stable, as motion blur seems to be a major problem, often leading to crashing. The P-buffer code in the OpenGL section is particulary horrendous. The current render targets code for Direct3D need to be tuned up for speed, though.)
* Depth buffers (for example Zelda OoT and the sun, and coronas in the two Zelda games and PD. Many other games have problems too with this, however RE2 has a particular issue to do with depth as well.)
* Texture mapping errors (like with BK, SM64's sky textures and some other games with texturing problems...)
* A size problem with dumping hi-res textures


I might even start writing a compatibility list for the plugin, to go in the documentation...to document what might need to be fixed.
 
Last edited:

rabiddeity

Plugin Hacker
I might even start writing a compatibility list for the plugin, to go in the documentation...to document what might need to be fixed.

That would be a great start. Also, if any fixes depend on other fixes or might be affected by other fixes, you should write that down (i.e. if we change from p-buffer code in OGL, will it require changing a bunch of code for depth buffers too?)
 

mudlord

Banned
Cool, I'll get right on it, I guess now I betta start playing through some games (which will be fun...) :)...

And...I did a debugger build. The main issue with it is that BMGLib seems to have a problem with compiling this way, which means the debugging plugin crashes whenever hi-res texture loading/dumping...But I don't see why people would use a debug build for playing games though...:p...the debugger functions all work great BTW.
 
OP
Enzo Dragon

Enzo Dragon

STFU, NAVI
I think RE2 might not run because of core emu, rather than video plugin crap. I say this because as far as I know, it doesn't run on any emu or any video plugin.

From what I know about RE2, the cart itself is different from other 64 carts to begin with. The game spans two carts, first off, and it probably has an on-board mod. I can't find a lot of info on it, though. =/
 

mudlord

Banned
Also, RE2 uses a custom sound system for voice compression (seems to be MusyX, from my sources..), which is very picky on timing....So, I agree about the core issues. I managed to get RE2 to run on Mupen64 0.5.1 and the latest PJ64 beta fine, with no problems, though...Main graphics issues for this game though are the flickering and depth buffer problems...
 

Cyberman

Moderator
Moderator
RE2 is fully playable last I checked on PJ64 1.6 with the latest RDB (8/13/2006). Sure there are bugs in the audio, however I've played the whole game through (without the audio working 100%). Thank goodness for gamefaqs huh? :D

Back to the actual graphics bugs, I don't know how RE2 handles the depth sorting, I noticed that the plugin incorrectly puts forground and background objects of the 2d layers in the display all together the way it is now. This likely indicates that the background information is stored in a buffer that is then 'die cut' and put to the display in a certain order. Perhaps steping through a scene to see how it's being assembled from the plugin's standpoint might be a good idea.

Now some thoughts on what the GAME is doing that might provide clues as to what the plugin SHOULD be doing. FF7 uses a tiled background etc for it's scenes. RE2 uses 3d objects for interaction therefore it doesn't support a detailed multilayered background like FF7. However FF7 assigns a DEPTH to each layer in the background so that it knows when a character is in front of or behind an object. The same is likely what RE2 is doing. The cut out sections are sorted by depth and pasted in order of depth (along with the models and such). From observation some 3d objects are obscured by the background. I believe the bug is directly related to the weird scaling issues that are present with certain 3d objects. Running the game in the original display dimensions does not make things magically work however. (I tried it trust me). I suggest instead of pointing fingers at different things such as the 'core', one should look at how the GPU on the N64 thinks it's supposed to work.

How about finding test sections of the game to use for debugging, that is how I found out how the battle models worked in FF7. It's also how someone deciphered the animation format. Thank goodness PJ64 has save states to peer into to see what's up huh?

Cyb
 

mudlord

Banned
I suggest instead of pointing fingers at different things such as the 'core', one should look at how the GPU on the N64 thinks it's supposed to work.

I think I didn't point my fingers at the core, I only agree with the audio being core/RSP related (which it is). I know that its purely a video plugin related matter.


I noticed that the plugin incorrectly puts forground and background objects of the 2d layers in the display all together the way it is now. This likely indicates that the background information is stored in a buffer that is then 'die cut' and put to the display in a certain order. Perhaps steping through a scene to see how it's being assembled from the plugin's standpoint might be a good idea.

Z-buffering, perhaps? Explains why Glide64 requires HWFBE for perfect emulation for this game, since it uses the depth buffers...

The same is likely what RE2 is doing. The cut out sections are sorted by depth and pasted in order of depth (along with the models and such). From observation some 3d objects are obscured by the background. I believe the bug is directly related to the weird scaling issues that are present with certain 3d objects. Running the game in the original display dimensions does not make things magically work however.

Sounds like a definate depth buffer sorting issue...not so sure about the scaling, I better check this out to see how the plugin is doing it though...

How about finding test sections of the game to use for debugging

Opening scenes are definately great sections for debugging this. There is noticable sorting errors, like with the car objects etc...

Thank goodness PJ64 has save states to peer into to see what's up huh?

Yep!
 

Cyberman

Moderator
Moderator
I think I didn't point my fingers at the core, I only agree with the audio being core/RSP related (which it is). I know that its purely a video plugin related matter.
Twernt you I was refering too. :D

Z-buffering, perhaps? Explains why Glide64 requires HWFBE for perfect emulation for this game, since it uses the depth buffers...
My guess is yes, it manually sorts through the displayed objects possibly but using of course the 'microcode' from the RSP/RDP (and the PDQ too many abreviations dude).
Sounds like a definate depth buffer sorting issue...not so sure about the scaling, I better check this out to see how the plugin is doing it though...
Well unfortunately I could give you images tell cows moo like parots, however that won't be too helpful. Apart from seeing the weird flaw. Of note it only happens on CERTAIN objects, those that flicker in the game, light sources such as the computer monitor, card swipe machine, the shutter controls etc. I think the 3 stones you stick into that piece on the wall also show some of the errors. Ribbons and bullets are positioned correctly (just visable from every direction) and the storage locker is correct.

Opening scenes are definately great sections for debugging this. There is noticable sorting errors, like with the car objects etc...
Ehh I've been using that to test the depth issues. The scene with the computer in the main hall that is where you'll find the weird positioning and scaling issues. I noticed SOME of the object is obscured so it might actually be doing the depth sorting, just on the wrong scale. IE the depth buffer might not be scaled acording to the 3d object sizes.

Cyb
 
Last edited:
OP
Enzo Dragon

Enzo Dragon

STFU, NAVI
Ah. I wasn't aware it was fully playable! I guess I'm stuck in the past? Sorry for the incorrect info.
 

Rice

Emulator Developer
Guys,

I just stopped by. I am very happy that the source code has been picked up by your guys. Thanks very much.

RE2 renders the scene backgrounds as static 2D sprites + static 2D depth buffer sprites. To support such functions, the depth buffer texture needs to be load into the depth buffer directly (after conversion / enlargement / value renormalization ...). Most video cards do not support depth image loading feature, at least not may ATI 9600 card, so I left such feature out.

There are some thing could be done to get around such a depth buffer usage, but nothing will be easy.
 

Cyberman

Moderator
Moderator
Guys,

I just stopped by. I am very happy that the source code has been picked up by your guys. Thanks very much.
We thought you died... we had the funeral all planned too ... sigh.

RE2 renders the scene backgrounds as static 2D sprites + static 2D depth buffer sprites. To support such functions, the depth buffer texture needs to be load into the depth buffer directly (after conversion / enlargement / value renormalization ...). Most video cards do not support depth image loading feature, at least not may ATI 9600 card, so I left such feature out.
Hmmm I played RE2 for the PS1 last night, the RE2 version for the N64 is mostly the data from that ported. Obviously they had to do some interesting things to make it work. As for why the depth buffer issues yeah that makes more sense than anything else I can speculate about. This explains why you dump the entire background as you do.

There are some thing could be done to get around such a depth buffer usage, but nothing will be easy.
I wonder if this is similiar to the problem in Banjo Kazooie and the jigsaw mess there? Eventually such things will need to be supported). As for a way around the problem, how about switching between Orthogonal view matrix and a perspective matrix to do the trick at least for OGL (DX I have no clue about). This is what we are doing with Q-gears and the background scenes in FF7. (of course we aren't using DX at all).

Anyhow great to see you are alive Rice. :)

Cyb
 

Top