View Full Version : Kazzuya's GPU
gunblade89
August 19th, 2001, 01:45
in kazzuya's software driver (beta 1.61) the full screen size is just too blurry. HELP
1up
August 19th, 2001, 07:51
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
August 19th, 2001, 14:26
well' i guess i''ll use pete's.....
Zephon
August 19th, 2001, 16:27
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
August 19th, 2001, 18:01
thanks
kazzuya
August 20th, 2001, 00:13
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
August 20th, 2001, 05:59
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
August 20th, 2001, 09:08
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
August 20th, 2001, 10:06
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
August 20th, 2001, 10:31
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 :D
Pete Bernert
August 20th, 2001, 14:17
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
August 20th, 2001, 14:24
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
August 20th, 2001, 15:59
Lewpy when are u coming up with D3d for DX8 Plugin
Lewpy
August 20th, 2001, 18:42
Originally posted by liaqatali
Lewpy when are u coming up with D3d for DX8 Plugin How about after you've done yours? :D
Ali
August 20th, 2001, 19:35
Originally posted by Lewpy
How about after you've done yours? :D
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
August 20th, 2001, 20:40
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
August 21st, 2001, 01:45
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
August 21st, 2001, 09:32
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 :D 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
August 21st, 2001, 18:09
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
August 21st, 2001, 18:39
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... :)
Cyberman
August 21st, 2001, 20:45
Kazz:
Well the logs are just the last 6 frames before failure...
It happens no matter what also I noticed. I think it's just before they use a special affect and it's on a DMA chain as well when things go bye bye.
The logs however are only 10K so I'm attaching them to this post (simpler)
Pete: Now I know why hardware is faster, fewer bugs in the software ;)
Well thank goodness all the GTE codes are done by something else, it means I can just deal with the polygons alpha transparencies and textures. (yeah right JUST)
Cyb
kazzuya
August 22nd, 2001, 07:19
It's kind of odd that this msg board doesn't let to reply to single messages in a threaded fashion umm.
Anyhow..
Lewpy and Pete: my main idea was no caching at all indeed, cause caching is a pain ! You have to keep track of changes etc etc.
I've wrote a couple of more efficient GPU emulations before: the OGL one would only convert (4/8 to 16bits) the areas that were fetched. For that I kept a list of rects of converted and non-coverted areas. But I didnt go as far as checking for dynamic palettes 8P
The other one was similar to that, but I was using an API that assumed palette was present. So only need to convert 4bit to 8 bit. Then the API would generate a different texture for each palette ! ..That was on FF8 and worked fairly well ..especially since we got rid of the palettized fog in the 3D map 8)
In that case I also got a decent subractive rendering. Usually subtractive is used for shadows, so I'd convert the RGB texture into an alpha texture (alpha palette with Voodoo or 4444 for other cards).. something like:
alpha_texel = (R + G + B) / 3;
r_texel = g_texel = b_texel = 0;
The idea this time was more like a soft gpu using the hw acceleration at the very last stage, when the textures are all nice and ready 8)
Cyberman: got the logs, thanks. I'll see what I can understand form those. Do you think there is a chance to get a savestate as well ? 8)
I won't be checking this stuff anytime soon though. I'm leaving the country in a couple of days and I'll be busy setting things up for about a week to come. Right now I'm not on my PC..
baubau
Ali
August 22nd, 2001, 11:19
DAMIT!.......I CAN"T UNDERSTAND ANY OF THIS ****
Prafull
August 22nd, 2001, 15:12
Yes I seriously want to thank all you plugin developers for taking emulation to a new height.Actually I live in India and almost no one here knows about emulation but since I got into it some months ago I have been trying to make as many people aware as possible.
It was really nice to read all this stuff in this thread even if i cant undertstand the technical details and terms.Just a final word for you all---"You are doing a great job,keep up the good work".
Cyberman
August 23rd, 2001, 02:45
Kazz:
Yes I can but it's 1938K.
It doesn't compress more than 1% either.
Up to you what you would like to do with that, I suppose.
Lewpy
August 23rd, 2001, 09:01
Originally posted by Cyberman
It doesn't compress more than 1% either.That's because ePSXe uses a ZIP-type algorithm on the save-states, so they are already compressed ;)
Ali
August 23rd, 2001, 09:55
Originally posted by Lewpy
That's because ePSXe uses a ZIP-type algorithm on the save-states, so they are already compressed ;)
ok..........now tell me when the new plugin is coming.......eheh.......don't get mad........just curious.....!
Lewpy
August 23rd, 2001, 11:02
Originally posted by liaqatali
ok..........now tell me when the new plugin is coming.......eheh.......don't get mad........just curious.....! What new plugin?
Adair
August 23rd, 2001, 13:14
*yawn*
I don't remember exactly, but someone asked Pete if he would do a DX8 plugin and Pete said it wouldn't happen anytime soon if ever and to ask you(Lewpy) about making one. Then I think someone posted that they had read something that gave them the impression that you were going to do the DX8 plugin. So there's this rumor. I would like it if the rumor were true, but I'm not getting my hopes up about it. It may have happened slightly different than that as I don't exactly remember who said what.
I think some people tend to forget that you and Pete don't spend 100% of your time coding plugins for other people's enjoyment.
Ali
August 23rd, 2001, 13:45
Originally posted by Lewpy
What new plugin?
Okay since U donnot understand what I mean so just leave......Im sorry..........!:)
kazzuya
August 23rd, 2001, 17:17
HOT NEWS !!
LEWPY IS ABOUT TO RELEASE A DX8 PLUGIN !!!!!!
eheheh just kidding...
Cyberman: a savestate would allow me to play up until the game crashes and have the debugger stop exactly where it crashes.
Anyhow if 2MB is too heavy for you I understand that.. I was on a 56K modem until a week ago and I was fearing megabytes !
baubau
Ali
August 23rd, 2001, 18:52
Kazzuya I ntoiced that your plugin runs a bit faster,but it lacks compatability.Will u be fixing it.
Cyberman
August 24th, 2001, 04:02
Kazz:
I've no problem uploading a 2Meg file I just need to know how to get it to you. That's the real problem I can't attach it like the other one ;)
liaqatali:
I think it's a hobby of his and very I'm impressed it works so well as it does :)
Cyb
Ali
August 24th, 2001, 07:19
Originally posted by Cyberman
liaqatali:
I think it's a hobby of his and very I'm impressed it works so well as it does :)
Cyb
Well I guess I know that,all I was doing was just asking...buddy
Cyberman
August 27th, 2001, 20:12
Kazz:
I sent you a personal message with the URL to grab that save state. The save state (2) is just before a level 3 attack on some critter. I know fun stuff.
liaqatali:
I suppose it's worth asking, he's a busy person it seems :)
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.