[gunblade89]

in kazzuya's software driver (beta 1.61) the full screen size is just too blurry. HELP

 

[1up]

Um, i'm not knocking his plugin, but why aren't you using either Pete's or Lewpy's?
Do you have some weird video card, or do you just like Kazzuya's plugin over the other two?
It is a beta after all, but maybe someone else has
had the same problem and will be able to help you more. I've never really used it because
Lewpy's works great for me.

 

[gunblade89]

well' i guess i''ll use pete's.....

 

[Zephon]

If you have a 3d card don't even bother trying soft gpus. Unless you want to check if the game really don't work or the 3d plugin is just badly configurated. Then I think it's useful to have a soft plugin, and I would reccomend Pete's soft.

 

[gunblade89]

thanks

 

[kazzuya]

blurry plugin

The blurring is probably due to the videocard stretch that automatically does bilinear filtering.
Go to the options and disable "hardware stretching".
Then when you are playing, using the Fkey (F7 ?) to change blitting mode, choose "simple stretch".
I also do that sometimes.

On how one may want to use my plugin: I think it's mostly if one doesn't have a 3D card (nowadays are so common but when I started working on PSEmu Pro they were a bit more rare).
So far my software plugin seems to be still the fastest. Knack's is pretty fast too and displays higher framerates but I think there is something different in his FPS counter which reports faster speeds than mine.
I usually profile optimizations with Tekken 3 and there I notice sensible speed difference. But I guess that's not so important now that everybody has fast CPUs and that PSX emulation is more about playing games than technical wonder.

In any case OGL, D3D and Glide plugins are generally faster, look better (hires) and sometimes pretty compatible too (Pete and Lewpy).

baubau

 

[1up]

I finally got off my #$% and tried your plugin man, It's pretty cool. It actually makes epsxe run better on my friends pc! Well, sorry if i hurt your feelings or anything, that was not my intention. I think you guys that make the plugins are just way beyond me
I've been learning Vis C++, and i know how hard
coding anything can be, especially graphics based
apps. What language do you (and if you know) and the other plugin authors write in? I'd like to give it a try when i get better.

 

[kazzuya]

sensitive plugin developers

Hehe.. don't worry, didn't hurt my feelings.
My plugin was born when I joined Duddie and Tratax on developing PSEmu Pro. At the time PSEmu was being released with Duddie's GPU ..which really isn't his kind of job nor he had time for that.
Later on there was quite a bit of competition against the very well written Psyke and the cockier than faster Bleem which a bit too often resorted to double frameskip (although still pretty fast).
Then PSEmu faded away for its own reasons and I stopped working on the plugin for a few centuries.
Incredibly there are still people that use the plugin for a reason or another, so I decided to update it every now and then.. to iron bugs, or if I think of a new optimization or a new feature.

I think I got way off topic.. all this to say that basically I just keep alive the plugin for the sake of it.. and mostly if I get new ideas to optimize or improve something I invest some time in a new version.
But overall it's a plugin of the past.

PSEmu plugins are usually written in C with Visual C++ .. I don't suggest trying to make aplugin as a first project because it's not very well documented and requires quite a bit of experience not only with PC but also with PSX.
I'd suggest to download the code of some public plugin (if any) and try recompile that. Then you can try modify things and improve where possible.
Programming always requires quite a bit of time.. so be ready to spend sleepless nights just to see a colored pixel on screen 8)

baubau

 

[1up]

Yeah, sleepless nights....I already know what you mean. (Endless hours on MSDN and Codeguru..sigh)
I've written a few internet apps, chat program,
get/head server requester, and a program that makes bootdisks for every win operating system
Anyway, it's all been hard work, so i know where you're coming from so to speak. I'll look for a open source plugin... hopefully one exists out there somewhere. Speaking of sleepless nights, I just spent 2 hours tracking down some evil javascripts that were trying to change my connection settings to dial out to porn 900 numbers! ARGGGH!

 

[Lewpy]

Oh master Kazzuya, we are not worthy of your presence amoung us :heh:
Actually, I still have nightmares from seeing some of the code from your plugin :eyespin:
Seriously though, Kaz's softGPU is _fast_. Pete's softGPU is derived from Duddie's original softGPU, and that had some "dubious" techniques for triangle rendering

 

[Pete Bernert]

Pete's softGPU is derived from Duddie's original softGPU, and that had some "dubious" techniques for triangle rendering

Harharhar... that must be the reason why we use it in our OD funcs, eh?

Actually my soft plugin is a mix of Lewpy's (and my hw/accel.) plugin's basic interface funcs (for register and data writes/reads, fps calculations, blabla), enhanced duddie's drawing funcs (faster line calculations, many bug fixes and addititional primitives which were never included in duddie's plugin), and some stupid stuff of my own (the directx handling, per-pixel calculations).

It just tries to be as compatible as possible... usually I don't suggest to use it for playing games... owner of slower pcs _really_ should use the Kazz plugin...

 

[Lewpy]

Originally posted by Pete Bernert
Harharhar... that must be the reason why we use it in our OD funcs, eh?

I know, I can't really complain: whenever I attempt to "enhance" the software routines, it always makes it crash :smash: :emb:

 

[Ali]

Lewpy when are u coming up with D3d for DX8 Plugin

 

[Lewpy]

Originally posted by liaqatali
Lewpy when are u coming up with D3d for DX8 Plugin

How about after you've done yours?

 

[Ali]

Originally posted by Lewpy
How about after you've done yours?

hehe oh man lol......I don't know how to program a plugin......Well U can see my website....I have got some great words for you in it......!So as I am done with my website.....U can come with your plugin so I can put some more excitment in my website.........eheh........j/k.........!

 

[kazzuya]

the plugins nightmare

Cool we got Lewpy and Pete involved 8)

Just for fun, some time ago I tried a new approach for a DX8 plugin. Since my TNT2 doesn't support palettized texture, my main issue was to reliably deal with dynamic palettes. My approach was then a raw power one: generate 16 bit texture pages with one rectangular sub-texture for each polygon.
Basically for every polygon I'd allocate some space in VRAM with the required texture and then render all those polygons later.
Unfortunately texture uploading isn't very fast at least when using DX8 lockrect without any kind of double buffered DMA trick.
The advantage of that were:
1) Only need one NxM texture. For example a 512x512 texture can handle up to 256 polygons if the PSX textures are about 32x32 ( (512/32) * (512/32) = 16 * 16 = 256 ).

2) Brute force palette to 16bit conversion for every polygon guarantees success with dynamic palette (fog or just a billion 16 color palettes like in Tekken 3).

3) Because every polygon's texture generated is converted from PSX RAM into a secondary destination one can afford the luxury or padding the texture margins with a little more work therefore eliminating the issues with bilinear grabbing the texels of nearby textures.

Too bad the framerate was sad..
So.. don't try that at home !

 

[Cyberman]

Lewpy: All I can say is about the directX8

kazzuya: I've been thinking of picking away at Duddie's GPU and making a one that's a modification of it. Unfortunately things have been kind of rearranged in my life lately, too look for work instead. Enough of my sorry state (grin). I assume the source Duddie bequethed unto us has no texture support and no alpha support either, since I never noticed such things when I tried it (I went insane one day and was curious). Works better than anything I would have done. Anyhow onto the point. Is it a good framework to start from for a soft GPU?

There is a glitch in your soft GPU I've found when Playing Chrono Cross, it happens when you select the highest possible attack and what happens is that ePSXe crashs out completely, it gives me the "This program has performed an illegal operation." I don't get this with Pete's soft GPU, and Knacks thought you might want to know. I know you do this when you have time, so .. I have no expectations.

Pete: hey Pete your soft GPU works slow but it works, that's better than anything I've done.

I'm stuck with an S3Virge until work comes my way so soft GPU's is it for moi.

Cyb

 

[Lewpy]

Re: the plugins nightmare

Originally posted by kazzuya
Cool we got Lewpy and Pete involved 8)

What can I say, we lurk in mysterious places

Just for fun, some time ago I tried a new approach for a DX8 plugin. Since my TNT2 doesn't support palettized texture, my main issue was to reliably deal with dynamic palettes. My approach was then a raw power one: generate 16 bit texture pages with one rectangular sub-texture for each polygon.
Basically for every polygon I'd allocate some space in VRAM with the required texture and then render all those polygons later.
Unfortunately texture uploading isn't very fast at least when using DX8 lockrect without any kind of double buffered DMA trick.

Thankfully, I've never had to attack this problem head-on, since Glide has solid support for paletted textures. The only bummer is it doesn't support 4bit paletted textures, but that can be simply worked around.

The advantage of that were:
1) Only need one NxM texture. For example a 512x512 texture can handle up to 256 polygons if the PSX textures are about 32x32 ( (512/32) * (512/32) = 16 * 16 = 256 ).

Is the advantage of this simply because it is one texture? ie. one is easier to track than many, and it is quicker to upload than many small textures?

2) Brute force palette to 16bit conversion for every polygon guarantees success with dynamic palette (fog or just a billion 16 color palettes like in Tekken 3).

Oh, don't we just love Tekken3 and it's animated 4-bit palette tricks

3) Because every polygon's texture generated is converted from PSX RAM into a secondary destination one can afford the luxury or padding the texture margins with a little more work therefore eliminating the issues with bilinear grabbing the texels of nearby textures.

Yes, a nice advantage.

Too bad the framerate was sad..
So.. don't try that at home !

You don't mention anything about inter-frame caching: are you saying you were generating this large texture and uploading per FRAME? OUCH! That reminds me of my early support for texture windows: watch Ridge Racer 4 crawl I would have thought, at least, you would need to cache the small texture between frames, and re-use if possible. Even if you have to generate a new "big" texture. If you are really clever, you could just copy on the new textures over the patches of old textures in the "big" texture, and then upload, thus not having to generate the whole "big" texture per frame ... if that makes sense
I think I could adapt my texture caching code to handle controlling converted paletted textures: I would need to add a variable to the cached area, dictating the size and location of the palette (on top of x, y, s, & t). Texture type (4/8/16bit, currently tracked) would merge in to size of palette: don't need both. The garbage collection routine would have to be modified not only to check for VRAM modification to the texture area, but also to the palette location. That's not too bad a change, just a little bit more checking.
It took me a long time to get my "dynamic texture caching" to work correctly, and without crashing Lots of fun with pointers, pointers to pointers, pointers to pointers who used to be pointers and are now not

Anyway, I am sure Pete can be very insightful about this caching problem, as he has to deal with it

 

[Cyberman]

Kazzuya:
If you are interested I have a GPU command dump of data sent to the GPU before it crashed, it's a heck of a long log if you can imagine but should be adequate. I can dump when it's not the highest and when it's the highest to catch the difference. It's amazing the size of the log file to read that stuff.

Cyb

 

[Pete Bernert]

My approach was then a raw power one: generate 16 bit texture pages with one rectangular sub-texture for each polygon.

Harhar... that's nearly my dynamic caching strategy... just not per polygon, but for every used small texture rect (or maybe that's what you are meaning with 'polygon')... but I don't use one big texture, but sort the texture rects again in N 256x256 textures (N depends on the cards vram), since that's the size that should work on all consumer gfx cards.

Of course there are much more things to consider... fast funcs to check if the texture rect is cached, to mark it invalid, if new vram data gets uploaded, to check, if the texture rect is using a different pallette than the already stored one, and so on...