-------------------------------------------------------------------------12. June, 2005 Version 2.

07

- Some users wanted the possibility to enter a floating point value as framerate limitation. Ok, done (doesn't make much sense, imho, but it will not hurt as well... my personal advice: use the "auto-detect limitation value" option whenever it is possible). - softm reported on my messageboard, that one of the PSX blending modes looked different in my plugins, compared to the real PSX. You will notice the difference only in a few games (softm found Diablo, Legend of Mana and Castlevania), but nevertheless I've fixed this glitch. - In some games the "Flicker-Fix border" option (needed in combination with the fullscreen shader option) actually didn't fix flickering borders. That's fixed :) - Many users requested a "fast forward" key, which deactivates the frame limitation while pressed (to skip boring parts of a game). I've added this feature, you have to configure it in the "GPU key configuration" (hint: look for a small "..." button in the main config window). - smf of MAMEdev found a new psx gpu feature: y sprite mirroring. With his help (thanx for the small psx demo!) I could add this psx gpu capability to my plugins. Don't ask me if a console psx game will use such a mirroring (I've never noticed it), but who knows... there are many psx games out there :) - ShadX and guest(r) created all kind of interesting and nice looking OGL2 fullscreen shaders, which can be found in the shader forum on my messageboard. With version 2.07, even better shaders can be made: I've added the possibility to access own textures (stored as tga files), which can be used as look-up-tables, for example. If you want to know how to use this multi-texture option, I've put two small shader demos on my web site as well. Happy shading :)

"There was no grand design To get to this point No absolutes, no given truths We were not carved in stone" - "Cities Carved In Stone" by Primordial -------------------------------------------------------------------------22. July, 2004 Version 2.06

- This release took some time, as you may have noticed ;) Well, I was kinda busy, and I hoped that certain announced OpenGL extensions, which I could use in this plugin, would finally show up (of course that did not happen). Anyway, this week I had some free time, and I've decided that there were enough plugin changes in the last months to finalize the 2.06 release :) - I've fixed the internal "GLslang smoothing" shader effect. This effect

worked fine with earlier ATI drivers, but after ATI repaired some GLslang issues, the shader was screwed (my fault, not ATI's, by the way). - Related to the custom shader effect files (ARB program as well as GLslang): it's now possible to select the directory where the files are located. In combination with a frontend like ePSXeCutor or Delta you can now create different game configs, each using a different custom shader (by placing the shader files you want to use into separate directories). - Also related to shader effects (and the basic fullscreen filter): depending on the shader effect, the internal rendering resolution and the selected window/fullscreen size, it was possible that irritating flickering pixels were visible at the display borders. It's not easy to fix that cleanly, so I've decided to add a workaround, which will always work: there is a new option in the gpu config, for adding a black border around the display. Simply select a proper "flicker fix border" size (1 or more pixels) until the flickering vanishes :) - Booty made a nice suggestion in my messageboards regarding the gpu in-game menu: in days of old I had mostly "on"/"off" settings, so I displayed the setting state in the menu by filled/empty boxes. Later I used certain patterns for settings with multiple config levels. But of course much better is displaying a number, even more since I already have numbered the different settings in the gpu config window (like "Texture filtering: 0-6"). Funny that I haven't thought of that earlier myself... thanks, Booty :) - My new OGL/D3D ZiNc renderers have a "pause" feature, so you can stop/continue a game without actually quitting the emu. Comes handy when you have to run to the toilet while trying to break the high score ;) Well, most psx emus can already be stopped/continued, but sometimes the gfx card driver doesn't like that (crash boom bang). So I thought that this pause feature would be nice to have in this plugin as well (simply configure a "pause" key in the MSWindows gpu config window... the Linux key is, as usual , hard-coded). - Talking about ZiNc: version 2.06 is fully ZiNc compatible, meaning you can use the plugin DLL with the ZiNc arcade emu. Simply rename it to "renderer.znc" and copy it to the ZiNc main directory, and it will work. Still you will need (at least once) a psx emu like ePSXe, PCSX, FPSE, AdriPSX or PSXeven to go to the config window to configure the plugin, since ZiNc is a console application without a GUI. Maybe a ZiNc frontend coder will add configuration support as well, we will see :) In Linux (XGL2 plugin port) you can use the usual .cfg file to change the settings. Ah, and a final note: since ZiNc games have a bigger vram, you cannot set the "internal X/Y resolutions" as high as with standard psx games: on ATI cards the biggest X/Y values you can use are "X=high" and "Y=high" (since ATI - even the new X800 cards - only support up to 2048x2048 texture sizes), with nVidia cards (support up to 4096x4096 sizes) you can select "very high" for both resolutions, but I would only try that with 256 MB vram (or better) cards :) "I know it's way too late When this dance has begun So put on the heat And let the fire run

Take me away, my black flame" -"Black Flame" by Xandria -------------------------------------------------------------------------04. January, 2004 Version 2.05

- New year, new release :) Well, the 2.05 release is prolly more important for (nVidia) Linux users (the XGL2 plugin comes with nVidia support, a configuration window, and a 'fullscreen-refresh-fix' from Stefan Sperling), but there's some interesting stuff for Windows users as well (like the new custom shaders), so let's take a look: - Since the nVidia Linux drivers don't support the "render-to-texture" extension, I've made a new option, simply called "No render-to-texture" :) I've added the option in the Windows plugin as well, maybe it will help older/uncommon (aka "non-ATI/nVidia") gfx cards to run the OGL2 plugin, who knows. On modern cards it will make no difference if the option is enabled, at least the speed was the same on my Radeon 9700 Pro and Geforce 4200 cards... but hey, it will not hurt you to try it yourself :) - Shaders, shaders, everywhere... ;) Bruno did send me a mail, pointing out that at there was an interesting contribution from Ryan Nunn at the Beyond3D Shader Contest: Ryan was able to port the 2xSaI and Scale2x algorithm to DX9 pixel shaders. Why not add them to the OGL2 plugin as well? Ok, I did take a look, and while the 2xSaI shader needs several passes (and additional textures to store results), I was able to port the Scale2x shader to GLslang (well, it was more like a complete rewrite, damn the ATI 'texture indirection' limitations in fragment shaders). Therefore, if you have an ATI Radeon 9700 (or better) card, feel free to enhance the display (Andrea Mazzoleni's Scale2x algorithm is a nice effect for most 2D games). What a shame that nVidia cards still don't have GLslang support... Oh, and I've made another GLslang shader as well, for rotating the screen in steps of 90. That can be useful for certain games (like Raiden Project), which allow to rotate the display as well, to get a bigger screen size. But where are the shader files? I've archive, you can get them seperately (http://www.pbernert.com). Simple reason: I can update them (or create a new plugin release. Ah, and removed all of them from the plugin from my homepage even add new ones) without the need to there is now a readme file in each shader

package, explaining how to install and use the shader effect (some may need a special plugin configuration). "Wasn't there a dream last night Like a spring never ending Still the water runs clear Through my mind" - "Fiddler On The Green" by Demons & Wizards

-------------------------------------------------------------------------23. December, 2003 Version 2.04

- Some users missed a "Mdec filtering" option in my OGL2 plugin, to make movies looking less pixelated. I've simply forgotten to add it in the previous versions, I have to admit, and I didn't notice, since most times I have some kind of fullscreen filter active (which smoothes the movies as well). Ok, the option is available, please keep in mind that if your card doesn't support texture edge clamping, a small vertical line may appear in the right movie area if the new option is activated (though all modern cards should be fine). - I've fixed a small bug which could cause overbright displays after toggling between window/fullscreen mode. - I've stated in the version 2.01 notes that I wanted to do the fullscreen pixel shader effects with GLSlang (a C alike shading language), but by that time no (ATI/nVidia) driver supported this language, so I used the ASM alike ARB shader program extensions instead. Well, ATI's Catalyst 3.10 driver offers GLSlang support, so of course I started to experiment with it. Funny enough I found myself cursing alot... it's easy to reach the shader capability limits of nowadays gfx cards with GLSlang, and even perfect looking (and compiling) GLSlang shader programs sometimes brought my R9700Pro card to a crawl. Re-arraging the code somewhat: all was fast again. That doesn't mean that GLSlang is useless with nowadays cards, but I think that the driver-internal compilers still have some way to go. Anyway, I've added another fullscreen blur effect, done in GLSlang, in the plugin config, R9700 (or better) cards can run that fine. 'Smaller' ATI cards (or nVidia ones, as long as the Forceware driver doesn't support GLSlang) cannot use the new effect, that's life (well, you don't miss much... the 'GLSlang filter' is very similar to the older shader blurring effects... some more sampling points, and different weights, that's all). Additionally I made it possible for interested coders to create their own GLSlang shader programs. Simply place two files (one called "gpuPeteOGL2.slv", for the vertex program, and one called "gpuPeteOGL2.slf" for the fragment program) in the "shaders" subdirectory. I've added a simple example in this plugin archive, a shader which adjusts the plugin's display brightness (the higher the configurable shader level, the brighter the display... this shader should run without problems on smaller ATI cards as well, btw). - Nothing else... no compatibility fixes, no speed ups, etc. If you see other improvements/failures (compared to verion 2.03), blame your imagination or gfx card driver :) "Stetig steil bergauf, dorthin wo das Feuer lodert. Zieht uns in ihren Bann, der Gottheit wilde Meute. Nah an der Feuersglut, verschmelzen wir zu einem Koerper, werden eins mit der Walpurgisnacht! Runderherum ums helle Feuer, runderherum im wilden Tanz, kreisen Koerper, Geister, Blicke, beruehren sich im Fluge!" - "Walpurgisnacht" by Schandmaul

-------------------------------------------------------------------------10. November, 2003 Version 2.03

- Geforce4 cards with WinXP 4X.XX (or newer) drivers crashed this plugin after a few frames. Since all other cards (may it ATI or nVidia GF2/3/FX ones) were working fine, and even the same GF4 cards had no problems with Win9X drivers, it was obvious that a driver bug caused that issue. So I decided to wait until the offical 5X.XX XP drivers show up, hoping they would fix the bug. Well, what to say? Yeah, they didn't help at all. Therefore... good old golden rule: if you want to have something done right, do it yourself. Since I don't have a GF4/WinXP system, I needed some help to find a workaround . Luckily Phoenix Flame offered an helping hand, and he prooved to be a good and fast tester... big thanx to him :) End of story: workaround found (disabling texturing in the render context before the main context gets activated), and now there is a new config option in the "misc" config section, called "GF4/WinXP crash fix". Enable it and be happy :) Oh, and since we are talking about GF4 cards: no, GF4 cards cannot do Pixelshader 2.0, and therefore the "shader effects" and "PSX texture window shader" options will just give an error messagebox. The same applies to ATI cards lower Radeon 9500, or the nVidia GF2/3 ones. No need to send me emails about that. And another note (but a good one this time): with the latest 5X.XX drivers, nVidia GeforceFX users can activate the "very high internal X resolution" option... that means that textures up to (at least) a 4096x2048 size can now be done with FX cards, very nice :) Come on, ATI, show us you can do the same, ehehe. - A FF9 crashing bug has been fixed (somewhere on disc 3 with certain plugin settings). Thanx to hushypushy for reporting this issue and giving me a memcard save. - A few internal tweakings for the 0x0002 special game fix (used for FF7/FF8, see also the version 2.02 notes). I only have the PAL versions of that games, which are running fine, but some users reported glitches in the NTSC versions. Dunno if that ones are now fixed, if not, please drop me an email. - Some users missed the OGL1 "keep aspect ratio" option in my OGL2 plugin. Well, since the OGL2 plugin internally always has a perfect aspect ratio, the option was not very important, imho, but finally I kicked my lazy ass to add it again. If you like it, go on and use it :) - And a final note: there were some suggestions for a Linux port of the OGL2 plugin. Well, the plugin source code is designed to compile without problems on different compilers, including the Linux gcc one (I even have to admit that during my plugin development I often use the Mingw/Dev-C++ enviroment from Bloodshed Software because of stupid crashing issues with the MS Visualstudio in WinXP on my system... it's no fun to loose source code after a few hours of coding because of a crash). Nevertheless a Linux port is not possible atm, since the needed render-to-text ure

extensions are not available (or very good hidden). The latest official statements I have seen (from ATI as well as from nVidia) are that both vendors will offer such functions in the upcoming OpenGL2 libraries, but not in OpenGL1.X (though it seems that at least ATI is includin g GLX pbuffer support in their latest Linux drivers... so there is still hope). If somebody knows some links to Linux render-to-texture functionality (preferable with ATI cards), drop me an email. - Ah, and it shouldn't matter anymore if you have your custom "shaders" director y in the main emu directory or in the plugins sub-directory (at least for ePSXe, du nno right now if all plugin supporting psx emus call their plugin directory "plugi ns"). "It was summer, or maybe spring, I can't remember It was summer or maybe spring, I can't recall We'd try to always calm our elders (But always we did seem to fall) We'd never try to tame the burning embers (It didn't seem to matter how we'd fare) It seemed we couldn't ever escape December But it was summer, summer, or maybe spring, or maybe spring, maybe spring" - "Hideaway" by Steve Harley -------------------------------------------------------------------------12. September, 2003 Version 2.02

- First, speed: I was hoping to improve my texture caching. Well, I've tried all kind of different approaches during the last weeks, but to be honest: all were slower than my old one. In the end I decided to change the existing caching on ly slightly, to get a better texture load balancing. Seems to work fine, but prolly you will only notice a speedup in certain extreme game situations. - Second, compatibility: while generally the compatibility of this plugin is higher than my standard D3D/OGL ones, there were still all kind of glitches (especially with certain framebuffer effects... you know, mostly used for motion blur, wave effects, swirl effects, etc). Most glitches were already fixable by using the highest "framebuffer effects" option, but since that option is causing an overall slowdown (and it can cause an unpleasable lowres/hires look), I've tried to improve the lower FE modes as well. Ok, after changing a few lines of code (harhar), certain issues had been fixed (like the "clock effect" in Crash Team Racing, or the motion blurring in certain parts of MGS and Vagrant Stories). Not too bad. But then a personal nightmare crept up: the battle transitions of FF8... and also the swirl in FF7 wasn't always visible. After long debug sessions I've decided to add a new special game fix for those two games, to get the best results without breaking anything else. Here's a small guide how to setup the "compatibility" section of the plugin fo r good speed and still good gfx: FF7 (PAL tested): OD=1, FE=2, FU=2 + the new special game fix (0x0002)

FF8 (PAL tested): OD=1, FE=2, FU=2 + the new special game fix (0x0002) FF9 (NTSC tested): OD=0, FE=1, FU=1 Other games: OD=1, FE=2, FU=1 (everything set to "Standard"). If you don't care for speed, you can of course always use the highest options: OD=2, FE=3, FU=2, but only a few games (like for example Ghost in the Shell) will need such to run without glitches... and sometimes this mode will create a mixed lowres/hires display (example: look at the hitpoints in FF9) General rule: the lower the options, the faster the game, but also the chances for glitches will grow. And another advice: it's possible that a game uploads some (non-gfx) data to t he psx gpu's vram, and reads it back later (so it uses the vram as some kind of s wap file). That's no problem with FE=0 or FE=3, but the other FE modes may try to read back that data from your real gfx cards framebuffer, well, and that could cause problems (even emu crashes are possible). I have seen such only with FF9, and I've added special checks to get around that, but if you are having emu crashe s ("unknown opcode" messages, etc), you should try to set FE to 0, maybe it will help. - Finally: there is a special texturing mode in the PSX, called "texture window" . Basically it means that a part of a texture map can be used as a repeated text ure tile... for example a text box background image pattern, or a wall texture, or a street texture in racing games. That's one of the harder things to emulate in a hw/accel plugin, since "repeated textures" have some kind of limitations on PC gfx cards: * you cannot repeat only a certain part of a texture (like the psx gpu can do) , but you have to repeat the complete texture * the complete repeated texture has to be of a "power-of-2" dimension (2,4,8,1 6,32, etc), also unlike the psx which can use different sizes. Yeah, Some pc gfx cards have support for non-power-of-2 sizes, but if you ar e using such, you cannot use the "repeat" mode of the 3D API. Therefore my D3D/OGL plugins (and Lewpy's Glide as well) have to tread such ps x texture windows in a special way: get the texture data, scale it up to power-o f-2 dimensions, and place it in a single texture which then can be drawn in the "repeat" mode. Works, but of course that workaround has some disadvantages: 1. scaling can produce a not 100% display 2. you need a special cache for such textures 3. (only affects my plugins) "hires" texturing ("2xSaI", etc) isn't possible (that's because I use "palettized textures" - if available - for "texture w indows" to get a good speed).

Needless to say that the disavantages were always a thorn in my side... especi ally since ATI cards (and GFFX ones as well) cannot even do palletized textures for a speedup. After some thinking I came up with a solution in my OGL2 plugin: good ole pixe l shaders :) I've created a shader which is able to emulate texture windows perf ectly inside the gfx card. Runs nice and fast on my R9700Pro. And all of the above mentioned issues are fixed (no need for scaling, no need for a special caching , and hires textures can be used without problems). Anyway, it will need a DX9 card (only those support the "ARB_fragment_program" extension), so it's R9500+ and GFFX cards exclusive. Dunno about the speed on GFFX cards, though, the latest statements about the GFFX pixel shader speed we re not very promising, so maybe it's better to turn the shaders off on FX cards. If the new option is activated, and supported on your card, a small chessboard alike symbol will be displayed in the gpu in-game menu. "Let me walk a while alone Among the sacred rocks and stones Let me look in vain belief Upon the beauty of each leaf" - "The Park" by Uriah Heep -------------------------------------------------------------------------16. August, 2003 Version 2.01

- First, thanks for all the mails I've got about the new OGL2 plugin. Most mails were really kind and positive, but of course the new plugin also raised some questions and showed problems on certain systems. Here is a small list: * ATI R7500 surprise that, as * GeForce 2 o big surprise. * GeForce 3 and GeForce 4 (non-MX) cards are usually fast enough to run the plugin at full speed. To be more exact: they would be fast enough. Sadly the plugin crashes after a few frames with such cards.... but only on Win2K/WinXP systems with 4X.XX detonator drivers. W9X systems are working fine. 3X.XX drivers also work fine. There is a workaround for the WinXP 4X.XX drivers, though: enabling "NV1X compatibility mode" with RivaTuner... but it seems that this will als o make the plugin slower, so it's not a perfect solution as well. Well, the nature of this bug (running for a few seconds, then a crash somew here outside of the plugin) makes it impossible to track down the real reason. cards seem to produce all kind of glitches. Well, that was no big to me (I was more surprised that it worked at all), no way around far as I can see. cards are not fast enough to run that plugin at full speed. Also n

Currently it really seems to be a WinXP GF3/4 detonator driver bug, since o lder drivers are working, and no other cards are showing the same issue. Suggestion: report the crash to nVidia. Dunno if they will look at it, but that's the only way to get a clean solution in one of the next driver updates, imh o. Funny enough, a few WinXP GF3/4 users had no crashing problems, even with 4X.XX drivers... * GeForce FX5200 ... oh my... yes, the plugin works without crashes. And yes, it's slow. Honestly: if you are thinking that you have a fast card, just because it has a "FX" brand, you are pretty mis-informed (to put it mildly) . FX 5200 cards are even slow compared to a GF4 (non-MX). Sad, but true (I really hated it to point that out to a few FX5200 users... one of them e ven thought he was cheated by Dell for selling him such a weak card...). But of course: most times you get exactly the performance you have paid for ... and FX 5200 cards are relatively cheap, you know? Personally I wouldn't tou ch a FX5200 (or any nV card with a "MX" brand) with a stick... same is true fo r Ati Radeon 9200 cards, btw. * So who liked the new plugin? Well, ATI Radeon 9500+ and GeForce FX 5600+ users were pleased (and the GF4 users who got the plugin to work without crashes). But beside the increased compatibility and the new full screen fi ltering, there was also one flaw detected: FSAA will not work with the plugin (it wi ll only make it slower, ehehe). But that's not really in my hands... I cannot force a gfx card driver to do FSAA with offscreen buffers, sorry. - Another issue with the previous release was that movies were kinda slow (well, I got over 120 FPS with movies on my Radeon 9700 Pro, so I didn't notice it, sorry). This version will have a nearly doubled speed with most mdecs, so rela x :) - Skullmonkeys... ah, yeah... sorry to say: the game didn't work perfectly with the last release (I was only able to check out one level... and of course othe r levels were still screwed). Well, Parotaku gave me another save state, and I think now everything is right... at least Parotaku was not able to find more issues, so blame him if still something is going wrong ;) - FrancoisC noticed a bad shading in the Breath Of Fire 4 camp fire on his R8500 with my OGL plugins. First I didn't believe that (I played BOF4 alot in the p ast), but then I took a closer look... and he was right. After a few investigations I've found out that nVidia cards and ATI cards are doing a different rendering of connected quad polygons. Seems like ATI cards are handling a single "quad_stri p" polygon like a "standard quad" one, while nVidia cards are handling it like two connected triangles. Don't ask me what's the correct behaviour, and who is to blame, ehehe. Anyway, I've fixed that... now ATI and nVidia cards will work fine.

- Ah, and related to the bad BOF4 shading: the car tires in "Driver" were also m issing on ATI cards, tsts. Of course that's also fixed. - Various small cleanups. Dunno if the speed will increase significantly (I doub t so), but it will not hurt either. - I've started again to add good old 'special game fixes' ;) Well, as stated in the 2.0 readme, the 'Legend of Dragoons' battle transitions were not perfect without the "Full " framebuffer effect setting. Since the "full" mode is not really needed in that game (besid e that battle transition), I came up with a way to show the effects corretly even if a lower framebuffer effect setting ("standard" or "minimum") is active. The same 'special fix' wo rks also with the "RPG Maker" screen fading effects, btw. - This plugin was designed to use nowadays gfx card's capabilities to improve th e pixelated psx graphics... and of course a modern buzz word here is "shaders" ( or in OpenGLish: vertex and fragment programs). My first steps with shaders were done on my old GF3, using some nV OGL extensi ons, but I didn't see much benefits for my standard OGL psx plugin. Well, the OGL2 plugin architecture makes it much easier to add all kind of ful lscreen effects using shaders, and in OGL1.5 a C-alike shader language (GLslang) will be introduced. So I planned to use GLslang as soon as possible to create some nic e realtime fullscreen filters. But then I played with the current ARB shader extensions a bit, and they were working great on my current R9700Pro, so I thought to myself: why waiting? Let's use t hem now, and maybe replace them later with GLslang. A single thought... and it's done, ehehe. This version has some new options to select "shader effects", available are: * fullscreen smoothing - similar to the "screen filtering" option * fullscreen smoothing (black/white) - emulates a B&W tv set * custom... more about that later :) The level of each effect can be controlled as well (minimum, more, medium, maximum), and each effect can be combined with the "fullscreen filtering" opti on. The effect level can also be adjusted in the gpu in-game menu, btw. Oh, and please note: the first two shader effects were created with my R9700Pr o in mind... they are using up to 8 texture units! That means that all cards with l ess units will most likely show an error message.

But what's that 'custom' mode? Well, I thought it would be nice if interested users could create their own shaders. Therefore the 'custom' mode will load and use two external shader files (one for vertex and one for fragment programs). Simply create a main emu sub-directoy called 'shaders', and place a file named "gpuPe teOGL2.vp" (vertex program) and a file named "gpuPeteOGL2.fp" (fragment program) in it. For all users who don't have a clue how to code such ARB programs, I've includ ed already two sets of shader files in this archive... one for doing a "black & w hite" effect, and one which is doing a very simple smoothing (using only 4 texture coord uni ts, so it will work with less powerful cards as well). Experienced gfx coders can of course change the files and try to create even m ore interesting effects (mmm... maybe I should do some shader contest? ehehe). "Somebody bring me some water, can't you see it's out of control Baby's got my heart, and my baby's got my mind But tonight the sweet Devil's got my soul" - "Bring Me Some Water" by Melissa Etheridge -------------------------------------------------------------------------30. July, 2003 Version 2.00

I often get mails like: "Game XYZ is having missing screens in your hw/accel plugins", or "This swirl doesn't look right in D3D", or "Why is the OGL compatibility lower than with the soft plugin?", etc. Well, the basic problem: it's kinda difficult for an hw/accel plugin to detect which part of the psx gpu vram is used to display the current screen, and to map this part to the PC's gfx card's backbuffer. My OpenGL/D3D plugins are full of rules, guesses and tricks to handle this task. And, of course, they still fail. Sometimes it's not very important (like missing menu background gfx in Xenogears), but often annoying (like the screwed battle screens in Vandal Hearts 2). Of course I can try to tweak such detection rules, to improve one game, but to be honest, it's like: "repair one, break two others". So, in 2000 I planned to change my complete inner plugin core, to get an higher compatibility. And I've made an experimental gpu plugin, called "PeteSoftD3D". As the name is hinting, it used D3D, but the compatibility should be more like a soft gpu plugin. At least in theorie :) Yeah, the plugin kinda worked ok (meanin g: zillion of glitches in this stage, and speed not to bad) on my development syste m, and a few lucky beta testers were also able to run it, but it seemed like it was n't the right time for this new approach, since I reached some gfx card/API limits which made the further development pointless.

So it was back to the 'traditional' hw/accel plugins, adding more and more tweak s and stuff, but always knowing that there will be problems with certain games, doesn't matter what I am trying to do. And time went by... gfx cards got better and better, with more and more vram (im portant for the things I wanted to do), and also the 3D APIs (OpenGL and D3D) improved. I watched especially the upcoming OpenGL2 specifications, I liked their color convertion and memory control features (and I was kinda sad about the still not programmable blending stage), and I thought by myself that by the time when the final OpenGL2 is out, I can try my approach from 2000 again. Well, but in spring 2003 I started another emu project, and soon I could see tha t I would end up in the same compatibility mess as with my hw/accel psx gpu plugins. So I begun to do much tests with the currently available OpenGL extensions, to see if I can use them for the basic things I had in mind with OGL2, and luckily it showed that the most important things were working as I hoped they would. And therefore I've decided the time is right to do an hw/accel psx gpu plugin wi th high compatibility... I call it "Pete's OpenGL2 plugin, version 2.0", since I wi ll port it to 'real' OpenGL2 as soon as it's possible. Right now it only uses 'stan dard' OpenGL with all kind of extensions. Be warned: it's an hungry beast. I recommend a modern gfx card with 128 MB vram for best quality. Most 64 MB cards will also work, but with 32 MB it will be ha rd (and/or ugly), and with 16 MB nearly impossible. I've coded some capability checks, but still the plugin could crash on startup if your system doesn't meet the requirements. Also the cpu should run at 2 Ghz to get no big slowdowns in the best compatibili ty mode, and 256 MB system ram would be nice as well :) Ok, let's take a general look at the plugin: * What's better compared to my 'standard' hw/accel plugins? - An higher compatibility: you may notice that all kind of "special game fixes" are gone... because they are not needed anymore :) Bye bye, annoying Legend of Dragoons sprite border colors Rest well, FF7 fix And, and, and... - Correct swirls, correct splash screens, correct special stuff like the "Vandal Hearts 2" battles, or Tifa's Limit Break wheel (FF7) - A nice full screen filter. That one improves 2D games (and games with a 2D background gfx) alot. And best of it: no speed hit at all, and you can toggle it directly in the gpu menu :)

* What's worse compared to my 'standard' hw/accel plugins? - Generally a little bit slower (well, no speed problems on my AMD 2000+ and Radeon 9700 Pro... anyway, I was able to reach the required 50/60 psx fps easi ly on nearly every game I've tried). - You will need much vram to get nice hi-res displays. Yeah, you can choose a 'low resolution' display (will be as low as the soft gpu plugins), but of cour se the main reason for an hw/accel psx gpu plugin is to enhance the graphics... and that will need a powerful card with this plugin. And unfortunately the very best quality (options: "very high Y" and "very high X" resolution) is not possible with nowadays gfx cards/drivers (no luck with the R9700 Pro and GF4200 I have tried). Therefore the best workable settings are "very high Y" and "high X", but a 128 MB card is recommended for that modes. But hey, the standa rd "high Y" and "high X" mode will be good as well... especially in combination w ith the new fullscreen filtering. - Some options been removed oint in the "better" Some of them plugin core, plugin which like 'advanced blending', 'mask bit' and 'alpha multipass' have (mmm... less options? Thinking about it, I should have put that p list, since it causes less user confusion, ehe). are gone because they wouldn't make any sense with the new and some of them because I don't think that they are needed in a requires a modern card anyway.

- No Linux port yet (but it's on my to-do list... dunno if the current ATI Linux drivers can handle all the needed extensions, though... we will see). * And what's the same? - I still offer some options to tweak the plugin for better speed and/or quality and/or compatibility. Since the new plugin works different than my standard plugins, you will need to experiment with the new options until you get a feeling for them, I think :) - Texture filtering/hires textures WILL STILL CAUSE glitches in some games. Complains about it are going directly into my personal NULL device. Use that texture options if you like them, disable them otherwise. It's that easy. - Even in the highest compatibility mode, there will be still a few display issues in certain games. Like the screwed main game menu of Star Ocean 2. That's life :) But what about the old hw/accel plugins? Will they die? No, not at all. They have still enough reasons to exist... they are faster, and less demanding, so many people will still use them. Dunno how often updates will happen in the future, but if I find something to fix or improve, I will do it.

Ok, last suggestion: Check out the included readme file. It will explain the OGL2 plugin's config options, and it offers some configuration and tweaking tips . And, as always, have fun :)

"Ich lache, tanze, springe, sag neue Lieder auf. Ich schlag die Welt zu Truemmern und bau sie wieder auf. Du hast mit Blut geschrieben, du kennst die Regeln auch. Ich hol mir deine Seele, das ist bei mir so Brauch." - "Mephisto" by Subway to Sally --------------------------------------------------------------------------