Joined
·
119 Posts
Kazzuya's GPU
1 - 20 of 35 Posts
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.
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.
Joined
·
119 Posts
well' i guess i''ll use pete's.....
Joined
·
119 Posts
thanks
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
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
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.
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.
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
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
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!
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!
Joined
·
538 Posts
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
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
Joined
·
874 Posts
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...
Joined
·
2,615 Posts
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.........!Originally posted by Lewpy
How about after you've done yours?
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 !
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 !
Joined
·
412 Posts
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
about the directX8kazzuya: 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
Joined
·
538 Posts
Re: the plugins nightmare
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
What can I say, we lurk in mysterious places
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.
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?
Oh, don't we just love Tekken3 and it's animated 4-bit palette tricks
Yes, a nice advantage.
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
Joined
·
412 Posts
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
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
Joined
·
874 Posts
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...
1 - 20 of 35 Posts
