SoftGraphic graphic plugin

[et500]

Nice work! Would be great to see a GPU-assisted fullscreen mode which stretches the software generated graphics to fullscreen using a high quality method.

[MarathonMan]

Very nice! It's nice to see HLE emulators making use of LLE components.

If memory serves, the RDP code isn't vectorized at all (and is amenable to it). You could probably get an enormous speed boost if you used SSE.

[the_randomizer]

Originally Posted by MarathonMan

Very nice! It's nice to see HLE emulators making use of LLE components.

If memory serves, the RDP code isn't vectorized at all (and is amenable to it). You could probably get an enormous speed boost if you used SSE.

Hopefully, a speed boost is an eventuality. Even on my Core i5 3570, I doubt I'd get full speed, as powerful as my CPU is. Obviously, as a first release, speed isn't essential, but over time, I'd imagine it could be

[ShadowFX]

I wonder, what would really be the difference for software rendering using DDraw, OpenGL or D3D? Also, DDraw isn't handled well from Vista and up in my experience. Maybe defaulting to OpenGL for drawing to the screen would help with filtering and such.

[MarathonMan]

Originally Posted by ShadowFX

I wonder, what would really be the difference for software rendering using DDraw, OpenGL or D3D? Also, DDraw isn't handled well from Vista and up in my experience. Maybe defaulting to OpenGL for drawing to the screen would help with filtering and such.

Besides vendor lock-in, there shouldn't be any difference for this low-level of a plugin as it can't make use of conventional graphics cards. Both DDraw and D3D/OpenGL will likely end up using the same calls to raster the frame to the screen.

TIL: M$ doesn't even support DDraw well anymore... excellent.

[HatCat]

So why not open-source this sort of thing?

I understand that the changes are not totally significant, but maybe other people could help. It would suck if the N64 scene was only full of people who just wanted to download binaries all the time right?

Also, I'm not sure if I'm misinterpreting this bit of the MAME license, but it appears to suggest that redistributions of the derived work should include the source code (which is why I put the MAME license up on my Git repository):

Redistribution and use of the MAME code or any derivative works are permitted provided that the following conditions are met:

* Redistributions may not be sold, nor may they be used in a commercial product or activity.
* Redistributions that are modified from the original source must include the complete source code, including the source code for all components used by a binary built from the modified sources. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
* Redistributions must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Originally Posted by MarathonMan

TIL: M$ doesn't even support DDraw well anymore... excellent.

haha, They don't even support DirectInput anymore.

Microsoft just says use XInput/RawInput or a standard window message loop for keyboard/mouse.

Also: The DirectDraw version on my win7 appears to fixate a blur on some of the right-hand pixel columns of the game screen, so it is less pixel-accurate than the SDL video plugin I was maintaining.

Originally Posted by et500

Nice work! Would be great to see a GPU-assisted fullscreen mode which stretches the software generated graphics to fullscreen using a high quality method.

It's not possible to do with a software-accurate generated graphics plugin.
Remember that pixel-accurate means it draws the pixels.
If you resize the screen the pixels get resized, not sharp geometry.

You would have to alternate between a pixel-perfect mode and a pixel-imperfect HW mode to make effective use of fullscreen if you don't like the pixilation. Personally, I find pixilated N64 3-D graphics in full screen to be sexy.

[GPDP]

Just wanted to say that you guys are doing god's work. A plugin that is accurate to how the N64 actually looked was well overdue. While the various hi-res plugins can look nice, I'm tired of dealing with graphical glitches, low-res 2D elements that clash with the sharp 3D, and having to mess with configurations and RDBs to get games to display without major issues. PS1 emulation has had great software-based solutions for a good while now, and having N64 emulation finally catch up to that is a most welcome development.

Oh, and I might as well state that this plugin does not seem to work with Super Smash Bros. unless you set the CPU core style to Interpreter. Having it on Recompiler gives the following error after the N64 logo appears:

Break point found at
.\N64 System\Mips\Memory Virtual Mem.ccp
1570

I haven't tried all my games with this plugin, but none of the others that I've tried give me this error. Even Rogue Squadron runs well (although the menus give a black screen, but if you manage to go in-game, everything looks good there).

Edit: Never mind, I lied. RS needs to be set to Interpreter, otherwise there's graphical glitches out the ass.

[HatCat]

It's funny how suanyuan keeps stressing that none of this work is his/mine, yet everybody continues to call us gods lol.

I'm only using it to learn about the RDP and optimize the living shit out of the code, but the actual reverse-engineering and implementation of the RDP was the real challenge, and I feel quite saddened that we were shortsighted enough to compile MAME/MESS/angrylion/ziggy's work and maybe even share the results with everyone, only to have everyone naively credit the people releasing the compiled, updated plugins as gods and not the people who actually implemented all of this information.

I really dislike, strongly have a distaste for the way the original code was organized/not optimized, though; I will say that. Past that, it was really them who should be getting the credit here.

I think maybe all this thread has succeeded in doing was violating the MAME open-source license of angrylion's code.

Originally Posted by GPDP

Oh, and I might as well state that this plugin does not seem to work with Super Smash Bros. unless you set the CPU core style to Interpreter. Having it on Recompiler gives the following error after the N64 logo appears:

Break point found at
.\N64 System\Mips\Memory Virtual Mem.ccp
1570

Sounds interesting, maybe 8 MB RDRAM addressing mem range could also fix it.

[shunyuan]

Originally Posted by FatCat

So why not open-source this sort of thing?

I understand that the changes are not totally significant, but maybe other people could help. It would suck if the N64 scene was only full of people who just wanted to download binaries all the time right?

This plugin is an open source project without questions, since it is base on other open source project.

But it is still in very early stage, I didn't touch any rendering code yet, so if you think it is not proper to put the binary for download without source code, I have no problems to take out the download.

If someone else wants to contributes time and intelligence to N64 emulation, why not start from z64gl or angrylion's rdp.

[HatCat]

Well, I'm not going to like, ask you to remove it.

I never really understand the point of software licenses as anybody can still physically do what they want over the Internet and get away with it, even construct artificial evidence with enough changes claiming the code is actually all theirs.

I think what will happen is a lot of people will download this and be like ewwwwww not yet finished/not fast enough/too blurry without even knowing the facts about what it could become later. It's for reasons like that, that I would much rather have not released anything, but, in a final optimized product I wouldn't mind if you took my modifications, modified them etc.