Rice's Daedalus 5.0.0 source code

[Rice]

Hello, All

Here is the source code.

You are welcomed to join the project, working together with me to improve it.

Important features:

- dynamic ucode detection and switching
- 2xSAI, smoothing, sharpening, 2x texture filtering
- texture clamp, mirror, wrap enlargement
- OpenGL 1.1 combiner
- OpenGL 1.2/1.3/1.4 extension combiner and render
- OpenGL Nvidia TNT extension combiner
- OpenGL Nvidia register combiner
- ATI OpenGL 1.3 extension combiner
- DirectX 8 combiner for all video cards (low end, mid, high end)
- N64 combiner mode compiler
- Full automatic combiner mode generation
- Nvidia TNT DirectX combiner
- Clipping, viewport, scissor for DirectX
- S2DEX/S2DEX2/Sprite2D
- Ucodes for GoldenEye, PerfectDark, Conker, DKR, JFG. Ucodes are well organzied
- The whole project is cleaned up and well organized
- Written in C++ OOP
- Full functional debugger
- Texture dumper (to BMP image file)
- Many other features.


Contant me if you have further questions or comments.



Rice

[nephalim]

If anyone wants to code support for lower end graphics cards, there is a demand of at least one :)

[Gonetz]

imposing list of features

thanks Rice!!!

[nephalim]

Originally posted by Gonetz
imposing list of features

thanks Rice!!!

Seriously, this plugin makes me very jealous of those with decent video cards. Unfortunately for me an upgrade is impossible because I have a notebook. While the processor can handle N64 emulation just fine, and the video card has plenty of speed, it just doesn't have the necessary features :cry:

[Rice]

nephalim

No one can do much about it.

I believe your Mobility M4 is Rage 128 based, (or it is a Radeon based as Mobility M6). The video chip itself is not very bad, could be as good as TNT, TNT2, Voodoo3. But ATI never releases a API to fullly access the chip functions. Under DirectX or OpenGL, you can never get good combiner effects with such a vido chip.

You may want to take the source code, work hard to make special combiner modes for some certain games, to fit this vidoe chip. I doubt some special settings working for all other games, because the video chip is just not as powerful as N64 RDP.

btw, if it is Radeon based, it supports OpenGL better than DirectX.

Rice

[nephalim]

Originally posted by Rice
nephalim

No one can do much about it.

I believe your Mobility M4 is Rage 128 based, (or it is a Radeon based as Mobility M6). The video chip itself is not very bad, could be as good as TNT, TNT2, Voodoo3. But ATI never releases a API to fullly access the chip functions. Under DirectX or OpenGL, you can never get good combiner effects with such a vido chip.

You may want to take the source code, work hard to make special combiner modes for some certain games, to fit this vidoe chip. I doubt some special settings working for all other games, because the video chip is just not as powerful as N64 RDP.

btw, if it is Radeon based, it supports OpenGL better than DirectX.

Rice

Sorry for the whining Rice. :blush:

It's Rage-128 Based, unfortunately. I only wish it was Radeon based. However while it can do practically nothing right, it's got a 350mhz ramdac, AGP 4x, is made for 32-bit color (it's actually faster in 32-bit than 16-bit,) and has 64mb and is pretty damn fast for a crappy laptop chip. I think it even has a framebuffer, I got framebuffer emulation with Jabo's 1.5 without a performance hit.

Too bad ATI values speed and buzz words over functionality and compatibility.

"But ATI never releases a API to fullly access the chip functions."

This is the exact problem...it's not properly DirectX Compatible and the API sucks...nevermind the fact that i'm stuck with Dell's drivers, ATI won't make laptop drivers :(

I would LOVE to write a combiner for my card...but I don't really know where to start.

FYI, i've noticed OpenGL is much much more buggy with my card, although when it works well it works well....however with your plugin it is EXTREMELY slow for some strange reason. Some OpenGL-based software doesn't work at all, like the other OpenGL N64 Plugins (Maya works now, with a new driver update.)

As I said...sorry about the whining, please pay it no heed. I don't mean to discourage you from your excellent plugin, with an unrivaled list of features....

Hey, do you have the (fast) framebuffer working like Jabo's, and the emulate clear effect too? I think that's the only real feature your plugin is lacking, so you might want to add it. Just a suggestion.

Keep up the good work Rice...:)

[ocarina plyr]

Im picking up the code to add a better support for Eva64,
where can i find help?

Maybe adding .jpg support......

[Rice]

Originally posted by ocarina plyr
Im picking up the code to add a better support for Eva64,
where can i find help?

Maybe adding .jpg support......


Ocarina plyr,

You don't have ideas about what is jpg support in N64 emulators or plugins. You may forget JPG first but just work on the Eva64 In fact, there is not much to fix anyway, just need to identify the problems and quickly fix them. Most problems are general problems, not just for Eva64.

Identifying the problems and reporting them may help to improve the game faster than working on the plugin by yourself.

But you are always welcomed to work on it.

[schibo]

Don't worry about jpeg. This is already embedded into 1964 1.0. Besides, you cannot add jpeg to an HLE graphics plugin without a change to the spec. 1.0 supports it.

[marioshroom]

w00t!

:1964:

it is very exciting to hear this, or everything about 1.0!! yay!

[Riven]

Originally posted by schibo
Don't worry about jpeg. This is already embedded into 1964 1.0. Besides, you cannot add jpeg to an HLE graphics plugin without a change to the spec. 1.0 supports it.


How hard is the wait... :1964:

[ocarina plyr]

funny, photoshop 6.0 cant read the bmp format...
(or it was jabo's?)

[PistolGrip]

I think I have narrowed the Direct3D problem down to either a culling or depth buffer problem. I have been poking around the source and playing with the debug options. I need to have a look at the culling code because I can see a lot more on the screen when I turn CULL off in the debug options, which is more then the black screen I get on most games.

It seems PilotWings is one of the only games which shows anything at all now, but it has depth issues.... half of the polygons flicker in and out constantly. Every other game I have tried, unless I turn CULL off I can't see much at all, its just all black except for one or two polygons maybe showing randomly. When I turn CULL off there are a lot of other issues.. but at least the game can be seen somewhat running.

I have noticed some odd things in d3drender.cpp that I will need to further investigate before knowing if they are a problem or not.. there is a lot of source code overall to look at before I better understand this DLL.

[ingonab]

Screenshot: Super Robot Taisen 64 (J) [!]

A. Rice's Daedalus 4.5.0, OpenGL + Normal Combiner
B. Rice's Daedalus 5.0.1, DirectX, Faster Frame Buffer
C. Rice's Daedalus 5.0.1, DirectX, Complete Frame Buffer
D. Rice's Daedalus 5.0.1, DirectX, Faster FB + hack

I *think* it's properly supposed to look like A.

A's OpenGL + Normal Combiner fix only works in version 4.5.0. But I think it works because Normal Combiner in that version ignores alpha blending in some cases. (Which causes visible problems elsewhere.)

I think B is dark like that because it's blending with nothing. I figured both the blue stars and the Banpresto logo have non-one alpha values.

C is extremely slow and looks as though the whole frame was shrunk to a smaller size then blown back up to original dimensions. (Or many individual textures.) The quality looks very poor in that respect. I don't know why using Complete FB emu fixes the blending with black problem but I'd be interested to find out if someone could tell me. :)

D is the same as B except I changed blender's "1/2 Cycle or Copy" from BlendFunc(SRCALPHA, INVSRCALPHA) to ONE, ONE. Hence the stars are mixed with the logo.

I may be speaking out of ignorance, but a possible compromise over the lack of a fast Complete FB Emu could be to stick in a hack that detects when something with alpha is going to be blended in with nothing, and override it to blend ONE, ZERO instead. --Or something along these lines.

[Rice]

Originally posted by PistolGrip
I think I have narrowed the Direct3D problem down to either a culling or depth buffer problem. I have been poking around the source and playing with the debug options. I need to have a look at the culling code because I can see a lot more on the screen when I turn CULL off in the debug options, which is more then the black screen I get on most games.

It seems PilotWings is one of the only games which shows anything at all now, but it has depth issues.... half of the polygons flicker in and out constantly. Every other game I have tried, unless I turn CULL off I can't see much at all, its just all black except for one or two polygons maybe showing randomly. When I turn CULL off there are a lot of other issues.. but at least the game can be seen somewhat running.

I have noticed some odd things in d3drender.cpp that I will need to further investigate before knowing if they are a problem or not.. there is a lot of source code overall to look at before I better understand this DLL.


It is nice to see that someone is reading the source. There are depth problems in both opengl and Directx, together with near clipping problem. Some clipping problem is fixed in 5.0.1.

I hope the whole source code is easy for you to follow.

[PistolGrip]

Yah Rice I like your design, did you just recently OOP it? I've been reading it for about 4 hours or so getting to better understand it. This is my first time looking at a N64 plugin DLL, but I have written emulators and various Direct3d games. I am coming up to finishing another project I am working on so I may have some spare time to throw at it what would you recommend me to read so I can get a better understanding of N64 graphics and HLE. I understand your code.. I just can't compare it to "what it should be" and "how it should work" if you understand me.

I might be able to improve your texture cache and other non n64 gfx related areas though.

[Rice]

If you like, you should read the N64 programming intro manual and N64 function manual at:

http://n64.icequake.net/doc/n64func/
http://n64.icequake.net/doc/n64intro/


Don't worry about the speed of the plugin. It has been largely improved from 5.1.0.

Rice

[LazerTag]

Originally posted by Rice
Don't worry about the speed of the plugin. It has been largely improved from 5.1.0.

Rice

I love when authors around here drop little goings ons like that, not so much as announcement but more of a subtlety :)

[PistolGrip]

BTW your plugin has no problems whatsoever on my machine when using 1964 0.8.5 so I guess now the problem lies with PJ64 not doing something it should be with your plugin or your plugin not liking what PJ64 sends it. I guess you design it using 1964 anyhow so I might as well stick to that for the time being.

[marioshroom]

yes also is the pill blinking in pj64, but a flawless thing in 1964.

excellent rice, it is of my favorite thing!

shroomario