-------------------------------------------------------------------------12. June, 2005 Version 1.76

- Ok, some of the new 1.76 plugin features I have described in the OGL2 version file (OGL2 V2.07): * * * * floating point fps limit value y sprite mirroring (thanx to smf) fixed psx gpu blending mode (thanx to softm) fast forward key

So there's no point to repeat it all again :) A few extra things needed to get fixed/added in the standard OGL/D3D plugins, though: - I've added a "pause" key, if you have to do a break, and you don't want to quit the emu (my other gpu plugins already had this option) - I've noticed the "G4 polygon cache" special game fix (for FF9) was a bit overdone :) Should be better now.

"All the seats are taken in the house that makes the rules. All the seats are taken in the Parliament of Fools." - "The Parliament of Fools" by Skyclad -------------------------------------------------------------------------10. November, 2003 Version 1.75

- Not much done in 1.75 (at least as far as I remember, ehe). The major change was some tweaking of the internal texture caching, which will sometimes cause better FPS, and sometimes (insignificant) less FPS, depending on the game engine. Anyway, the new caching is somewhat cleaner, and cards with little vram (32 MB or less) will like it better in certain games using many different texture palettes. Therefore: if 1.75 works better with your system/games, use it, if 1.74 works better, feel free to keep it, you will not miss any new feature by doing so. "images of sunshine lease, to make the words rhyme let me die in eight-time let me write a tale to no-one let me write a tale to make you think you're someone and 'Can you think of one good reason to remain?'" - "Death Trip" by Steve Harley -------------------------------------------------------------------------16. August, 2003 Version 1.74

- A few fixes from the OGL2 plugin also affected the standard OGL/D3D

plugins, so I've decided to release them as well. Things fixed (shameless copy of my OGL2 version text): - 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. "He disappeared In the early haze of morning And with him left his prophecies They didn't care..." - "Send Me A Sign" by Gamma Ray -------------------------------------------------------------------------01. August, 2003 Version 1.73

- calb detected a gpu bug with the Skullmonkeys game (missing graphic layers), and gave me a save state. I was able to fix that bug without the need of a new 'game fix', and hey, maybe some other games will also be affected for good (but I don't want to know how many games will break because of it, ehehe... naah, none of the games I've tried had shown any bad side effects). - ePSXe 1.6.0 is offering multitap and gun support. Old plugins only could give infos if the emu was running in "A"nalog or "M"ouse mode (a symbol appeared in the gpu menu), now the menu can display the currently used "A"nalog, "M"ouse, "G"un or "D"igital pad mode, and also the pad/input device number (1-4). "Das ist die Zeit der Nebel, der Kraehen und der Raben. Die Schnitter muessen maehen, und keiner kommt zum saeen. Es geht ein duester Reigen" - "Herbstzeit" by Subway to Sally

-------------------------------------------------------------------------14. Juny, 2003 Version 1.72

- It's summertime :) That means that I don't spend much free time for emu coding right now, and since the hw/accel psx gpu plugins are kinda mature, there is no big need to do so as well. Nevertheless, since ATI cards get more and more common, I wasn't exactly happy that there were still some ATI issues reported with my plugins. But since I used only nVidia cards for the last years (I liked their driver stability), I never got a real chance to check out what was going wrong on ATI cards. Of course I had a lot of offers to do beta testing from ATI users (thanx to Laurent, Omegadrive, Tuan, Tarcel, and everybody else for the support), but I am not so a big fan of remote debugging (that's usually a tiresome, time-consuming business). Therefore I was nicely surprised when Alan, from Woodstock (USA), offered to send me a free Radeon 9700 Pro. So this gpu release is dedicated to Alan, it wouldn't been possible without his donation. - First some general words about the ATI card (you can skip this section, if you can't stand my engrish, long winded explanations, and you just want to know what's new in the plugins... you may want to read on if you are planning to upgrade your system to an ATI card as well, though). Before replacing my old trusty GeForce 3, I de-installed all nVidia drivers from my W98 and WinXP systems. After that I shut the PC down, put in the 9700 Pro, and bootet up again, WinXP first. I ignored all the blabla on startup, installed the 3.4 Catalyst drivers and the ATI control panel, rebootet again, and all was up and running. Well, running at 60 Hz, of course. First I adjusted the frequency in the monitor settings (like I used to do with my GF3 card), setting it to 85 Hz... and nothing happened... still 60 Hz. After some research I found out that I had to increase the frequency in the ATI panel as well, tsts. Finally 85 Hz :) At least on desktop... fullscreen games of course still were running at 60 Hz... the typical WinXP problem. So, running RefreshForce (which I also used for my GF3) fixed that issue, nice. Otherwise everything else was working without problems (ah, of course WinXP detected a 'major change in hardware', so I had to activate XP again). All PC games I started up were running fine, and because of the faster gfx card I was able to max out all the video settings (like in Morrowind, Gothic2, Aquanox2 and GTA Vice City), without performance problems. No stability issues as well. So I booted Win98, installed the Cat3.4/ATI panel as well, and... also 60 Hz. Well, no problem I thought, went to the ATI panel... and... no tab for adjusting the frequency there... eh? Changing the W98 monitor frequency without the ATI panel didn't work, and therefore I tried many things (like installing different monitor drivers, reinstalling the ATI drivers, using a driver cleaner tool, etc). No success. After searching in various ATI forums I found a solution: create a new binary key called: "DALRULE_ALLOWNONDDCCRTALLMODESUPTO1600x1200" in the "HKLM/Software/ATI Technologies/Driver/0001/DAL" registry section, set it to "01 00 00 00", reboot, and yeepee... finally it was

possible to change the monitor frequency to an higher value. Big flaw in the ATI drivers, imho... ok, prolly it's caused by my BNC monitor connection, but I think that an average user would have been lost. I also noted that the mouse cursor in W98 tends to get screwed (after leaving the ATI panels?), but I was able to fix that by adjusting my MS IntelliMouse settings. Anyway, it seems that's another W98 ATI bug lurking in the dark. - Ok, now on to the plugins: yeah, with the ATI driver the emu crashed on exit. Funny enough only with the psx gpu OpenGL plugin, not the Zinc one, or with any other of my other OGL projects. Wtf? It was getting worse: it didn't crash in the plugin, but in the main emu (prolly when it was trying to destroy the renderer window). Hard to debug... so I tried the good old 'trial and error' approach, and found out that if I don't delete the OGL rendering context, no more crashes. Well, anyway I didn't like this solution, very unprofessional. After some more research I found out the real problem: it seems that the ATI OGL driver is subclassing the renderer window when it creates the rendering context, and de-subclasses it again on context deletion. Dunny why it is doing that. But it conflicted with my own window subclassing. Aha. After swapping a few lines of code: tadaaa... no mor 'crash on exit' bug, and fullscreen window toggling now also worked as expected. Ok, one issue solved :) - Now I started up several psx games which are known to use framebuffer textures/framebuffer access. Nice: in OpenGL the framebuffer texture option works very fast on ATI cards (at least on the R9700 Pro). But the framebuffer access (reading vram to system memory) has an horrible speed... at least 5 times slower than my old GF3. I've tried all kind of different color formats, and read through the ATI OpenGL extension specs, but no luck: slow. So I decided to do a new 'special game fix' (I should rename that section into 'special hardware fixes', it seems), calling it 'Mixed software FB access'. What does it do? It minimizes the real vram reading to a minimum, whenever the 'framebuffer access' modes 1 (reads), 2 (moves) and 3 (read&moves) are used, and uses software drawing instead. Unlike the FB access mode 4 (full software drawing) it will not use the soft funcs all the time, only if they are really needed, when a psx game is doing such special effects. - Then I moved on to the D3D plugins... didn't expect much problems, but then I noticed an horrible slowdown with 'FB access' and even with 'FB textures'. Well, I did know that my D3D code to emulate such effects were optimized for older (DX6/7) hardware, but I never suspected that newer ATI cards were choking that bad at it. Anyway, since the new OGL plugin is working really nice on new cards, I didn't change anything with the D3D code, I just added the new 'Mixed software FB access' special game fix as well. Therefore: if you want to play psx games with my plugins with an ATI card, I suggest to use the OGL plugin. If (for whatever reasons) you want to use one of the D3D plugins, you should at least enable the new fix, and set the 'FB textures' option to 3 (card buffer + software), never to 2 (card buffer). - Last but not least: the D3D DX6 plugin produced stupid glitches. My fault... I screwed the internal 'palettized textures' detection in the DX6 plugin, and of course never noticed it because my old GF3 supported

that kind of textures. Tststs. Ok, repaired :) - Oh, and sorry... I didn't have time yet to change my Linux installation as well, using the new 9700 Pro. I haven't even decided if I simply replace the Linux nVidia drivers, or if I should upgrade to a new kernel, etc. So, no new Mesa plugin version right now, but it will follow 'soonish', I hope. - Conclusion: nice and fast card, and not-to-bad drivers. Some problems in my W98 desktop, but fixable. On the downside: A bad frame reading speed - can maybe get improved with newer drivers, who knows - and of course no palettized texture support. But be aware (if you right now have to decide if you want to get a Geforce FX or one of the newer ATI Radeons), that all of the nVidia FX cards _also_ have no more palettized texture support. Yup. Personally I find that a shame... it will even produce strange situations when you compare the speed of your old card to your new one, and the old one will win the race with certain games (not only psx ones, like 'Ghost in a shell'... also PC games were using pal textures, like the Unreal 1 based ones, or the PC version of FF7). But ATI, nVidia (and Intel as well) have decided that palettized textures are expensive to support, and so it's gone. Like it or not. "If I could have my wasted days back Would I use them to get back on track? Stop to warm at karma's burning Or look ahead, but keep on turning? My lifestyle determines my deathstyle" - "Frantic" by Metallica -------------------------------------------------------------------------19. April, 2003 Version 1.71

- I've adjusted the OpenGL fullscreen handling somewhat. I don't know if it will help with the ATI 3.2 Catalyst drivers (which seem to tend to crash when the rendering context is getting released), but it should not hurt as well. - The results of my experimental 1.70 alpha texel handling were interesting. As expected, some Intel and Kyro card users reported black areas, but also ATI cards were affected. So, I've adjusted the alpha values again, this way the texture handling (without filtering) will be OK on all cards, and also activated filtering will be fine with most cards (thanx to Badara for checking it on his ATI card). For cards still having filtering troubles I've included a new special game fix: "Use old texture filtering", which will handle the filtering like version 1.69 (or older). - A small OpenGL plugin bugfix for the lovers of the 'keep aspect ratio' option: now you can use the 'direct framebuffer upload' special game fix without problems. Thanx to F-3582 for reporting that issue. - Beside the usual bugfixes (as described above), I also wanted to add some new eye candy and improved compatibility. Snu suggested to use a new kind of hires textures: simply

scaled ones, without any interpolation like 2xSaI. First I was sceptical, and my first checks seemed to proove me right: I couldn't see any image quality improvements at all. So I dropped that idea for a few days, until it came to my mind that I've used a too small window resolution (640x480) for my tests. And yeah: Scaled hires textures combined with extended texture filtering and a resolution of 800x600 or higher gives a nice display: there will be a slight (not very strong) filter effect on 2D backgrounds, without tile effects or much texture glitches (well, there are the usual exceptions like FF7, which simply hates any kind of texture filtering). So, it's a good alternative to the standard texture filtering (which often screws 2D backgrounds), use it if you like it (and your hardware can handle it, of course... like 2xSaI you will prolly need at least 64 MBytes vram with most games). - As for compatibility: it's well known that the current hw/accel psx gpu plugins have to do all kind of compromises, resulting in lower compatibility (means: missing screens, screwed displays, flickering, etc) with some games. And it's not easy to improve the compatibility of one game without screwing a dozen other ones. Anyway, in 1.71 I've tried to improve my 'splash screen' upload detection (hopefully in a way that it doesn't harm games), but I've noticed still missing screens in Tony Hawks (demo), Soulreaver (demo) and Colin McRae (demo). So I've decided to do an even nastier screen detection as well, but this one has to get activated manually as a new special game fix, since it surely will act badly with much other games (for example ChronoCross). _Only_ activate the new fix when you are missing important information screens (and of course there is no guarantee that the fix will help your game). "Cought in neverland In the place of many eyes Make it be What they are allowed to realize" - "Neverland" by Avantasia -------------------------------------------------------------------------15. March, 2003 Version 1.70a

- The D3D DX7 plugin had a small bug with 8888 textures and extended filtering (crash boom bang with some games), so I've updated the archive as quickly as possible. -------------------------------------------------------------------------15. March, 2003 Version 1.70

- The 'old skipping' game fix from version 1.69 ignored the frame limimation setting. That should be fixed. - I have disabled the automatic "force 15 bit framebuffer updates" option, which kicked in when a 16 bit color depth has been used. That should give better colors with mdecs in some 16 bit color depths (depends on the color format your card is using), as long as the config option is not activated.

- The main reason for this early release: I did take a look if it would be possible to improve the texture filtering. And I came up with a solution which gives nicer filtering results when 32 bit textures (RGBA8 or BGRA8) are selected. So, if you are using one of the 8888 texture types, and you have enabled "alpha multipass" as well (recommended settings for good systems anyway), especially the standard + extended filtering modes will be behaving somewhat better. For example "extended" filtering will not produce such ugly fat texts anymore (most times), and the occasional 'transparent halos' will be smaller as well. Of course the tile effects with some 2D backgrounds or the 'colored thin frames' which are showing up with texture filtering sometimes are _not_ fixed (and I highly doubt they ever will - psx games are usually not designed for texture filtering). To archive the better filtering I had to drive the texture alpha bits to their limits... which _could_ cause glitches on some cards, even if no filtering is activated. That's the main reason why I call this release 'experimental'. If you suddenly are encountering black areas around sprites, for example, please drop me a mail, and tell me the name of your gfx card. My Geforce 3 has no problems at all, and according to my texture benchmark results most cards will be fine, too (exception: old Intel cards and most likely older 3dfx cards as well), but I strongly believe at the good ole SNAFU principle, so we will see :) "In the splendour of the night I've found company Once again I feel that life's begun All the wrongs seem to be right Drowned in ecstasy Every star is like a newborn sun" - "A feast for the vain" by Kamelot -------------------------------------------------------------------------08. March, 2003 Version 1.69

- The new frame skipping has been improved again, there were certain situations where the skipping didn't work right (like with mdecs or screen smoothing) or caused some semi-lockups (like in the 'Pause' mode of FF8). - Some users liked the old frameskipping better (since that one only skipped every other frame, making the display smoother... most times the game will be too slow with that, but not as 'jumpy' as with the new skipping method). Therefore I've added a special game fix for the old way of skipping, use it if you like it. - Some "nice"/"fast" default settings were really buggy (the funniest thing: hitting 'fast' in the D3D plugins caused a forced "vram size" of 4 MB... not really the fastest way to run the plugins). I blame Microsoft for doing a crappy Visual Studio resource editor :) - My plugins had an internal hack in the past, to get around issues with ChronoCross (lock up in the status screen). Well,

it showed that the real bug was in the main emu, so I removed the internal hack in 1.69. But as long as you are using epsxe 1.5.2 (or previous version), you will need the hack to play CC, so I made a special game fix instead (called "odd/even bit hack"). Turn it on, if your game is suddenly showing lock ups, which didn't happen in 1.68. Ah, and no, I don't know when the next epsxe release will happen, poor calb has little time right now to do some coding. - Like the P.E.Op.S. soft gpu, my hw/accel. plugins are now supporting a special "cursor display" function, which can get used by the main emu. Right now only private epsxe betas are using it, and again: no, I don't know when the next epsxe release blablabla :) - The "texture garbage collection" option has been removed. The plugin now will decide internally if it's needed, making the plugin configuration a little bit easier (let us be honest: nobody but me knew what this option was for anyway, eh? ;)) - And another one bites the dust: the OpenGL "change desktop" option has been removed as well. The plugin will now auto-detect if it needs to change the desktop resolution/color depth. Thanx to JNS, his never-ending coding questions forced me to look at that part of my source (ehehe, JNS, keep up the good work... there are no stupid questions, just stupid answers). - ATI users often complained that they couldn't start up the OpenGL plugin in fullscreen, they had to start it up in Window mode, and toggle manually with ALT+ENTER to fullscreen size. Well, it showed that the ATI drivers were dropping the rendering context, I have now done some more security checks to prevent this (even if it seems that the newest ATI OpenGL drivers wouldn't need it anymore). Thanx to Lindsey for checking it on his ATI systems. - If you are visiting my homepage from time to time, you prolly have noticed the small benchmark application I have done to check out your OpenGL driver capabilities and texture speeds. A lot of users did mail me their results, so I was able to see what is supported on nowadays gfx cards, and how fast certain modes behave. Because of that informations I was able to make the following improvements: * the "faster palettized texture window" option has been removed. That option caused some troubles with ATI users in the past (for example screwed displays). That will not happen anymore, the plugin will now 100% auto-detect if palettized textures are supported, and activate/deactivate them properly. Of course that doesn't mean that ATI cards can now do magically that kind of textures, the plugin will simply not use them with such cards. That's not a big deal, though, only a few games (like 'Ghost in a shell') will really be faster if palettized textures are available. * A new option for slower systems, which are having troubles to run psx mdec movies at full speed in OpenGL. It's called "Force 15 bit framebuffer updates", and, as the name already is hinting, it will cause a small color loss when the game is using 24bit psx mdecs. So it's your choice: better speed or better colors. Oh, and btw: the plugin will use that mode automatically when you are playing in a 16 bit color depth, so you only have to enable the option if you are having speed troubles in a 32 bit desktop/fullscreen

color depth mode. * The benchmark also prooved that some cards/drivers are having a better texture upload speed, when a BGR color ordering is used. So I've made a new texture quality option as well, called "B8G8R8A8". How can you know if you should select the new or the old 8888 texture type? Easy: run my benchmark application :) A full description can be found on my homepage, in the "Fairy tales" section. * Some other facts I could extract from the benchmark results: I am already using the fastest possible way to do the "framebuffer texture" effects. So, if it's slow on your system, I cannot help you at all. Another thing to mention (it seems I have to do that again and again): activated FSAA will cause a big slowdown with framebuffer textures. So better deactivate it, if a game is using FBT (motion blur, water effects, battle swirls). Packed 4-4-4-4 textures are very slow on ATI cards. So I recommend not to use them, if the benchmark is showing a slow performance with that texture type... more about that in the Fairy Tale as well. * Last but not least: the 'ATI reverse subtractive blending' game fix is still needed if you want to use the OpenGL plugin right now with ATI cards. At least there is hope: Mwarhead showed me a forum thread on rage3d (http://www.rage3d.net/board/showthread.php?s=&threadid=33671156) where an ATI employee stated that the Cat3.2 or Cat3.3 divers will fix that issue. "Because no, nobody knows, nobody knows Because nobody knows anything" - "Nobody knows anything" by Anthrax -------------------------------------------------------------------------03. December, 2002 Version 1.68

- Fixed a small bug in the vram upload detection, this caused a strange flickering in ChronoCross with certain Offscreen Drawing modes. - Finally I was able to get Final Fatasy Tactics, to investigate the 'missing world map' issue, which was reported by some users. Well, that issue was no real one at all (you just need to set the correct framebuffer access/texture options to see that map), but the game showed me another small bug, which was in my plugins since ages: sometimes the 'fast palettized tex windows' option caused (wrong) transparent textures. Fixed. Ah, and no, it doesn't mean that now TNT2 or ATI cards can use that option, it simply means that a few text boxes in FFT are now drawn opaque, the way it should be. - And now the biggest chance: frame skipping. Ah, Lewpy's old skipping code hasn't been improved since I've added it in gpuPeteTNT version 1.11 (released in May 1999!), so it was really about time, eh? :) Well, good frame skipping is a bit tricky to do, the old method tried to measure the average psx frame rate, and skipped every second frame if the speed was too slow... yup, some speed up, but not very accurate.

The new skipping will measure each drawn frame, and decide automatically how much skipping is needed to get the right speed... if you use it together with frame limitation (really recommended!), you will most likely get a correct speed in every situation: doesn't matter if you had 15 fps or 40 fps without skipping, or if speed was dropping only in certain situations, now you should always reach the magic 50 (PAL) or 59.94 (NTSC) framerate if you are enabling frame skipping + frame limitation together (well, there are some limits: if your system is only able to reach 1 or 2 fps without skipping, forget it). Of course there are still some things to consider: * Frame skipping will cause glitches/missing stuff in some games (depends how skipping-friendly the game has been coded). And most likely your favourite game will be one of them. That's life. * Skipped frames make a game more 'jumpy', less smooth. You will not notice that very much if just a few frames have to get skipped, but the more, the uglier, of course. * The plugin FPS display (at least in my or Lewpy's plugins) doesn't show the real PC gfx card frame rate, but the vsync count of the emulated psx gpu. Therefore: * A big frame rate (higher than 50/59.94) doesn't mean a smoother display, it only means a too fast game play (and usually screwed sound). It's not like in a PC game, such games can draw additional frames, if your system is fast enough. In PSX emulation your goal should be a steady 50/59.94 frame rate, nothing more, nothing less. * It's important that the main emu timing. Otherwise the speed will emus like ePSXe usually have the the 'PC fps calculation' special is ignoring the main emu timing, issues most times). is generating the correct vsync be wrong. Luckily modern psx right timing, only in a few cases game fix will be needed (that fix but of course that will cause other

* Some spu plugins are offering a framerate limitation as well (done with the SPUAsync interface, or by measuring the XA frequency). If you want to use the gpu frame skipping, you cannot use such external fps limitations at all. Ah, and of course the golden rule: if you don't need frame skipping with your system and game, don't enable it! - Also related to the new frame skipping: some motherboard chipsets are having a bug with MSWindow's high performance counters (see also the version notes for version 1.52, 26. August 2001). While the plugin tries to correct that bug automatically if only the fps limitation is used, the correction cannot be done with the new skipping code. Therefore I've decided to add a new special game fix, called "low-res fps timer", which will fix that issue on that systems (by using a different, less perfect, way to calculate the times). So, if your system is having some weird timing behaviour, try the game fix, and check out if it helps. "Magic potion Crystal clear

It's too late Open lips and Open heart Tristan's fate" - "Tristan's Fate" by Grave Digger -------------------------------------------------------------------------23. October, 2002 Version 1.67

- All the small fixes I've added to the P.E.Op.S. soft plugin 1.9 are now included in my hw/accel plugins as well. A big 'thanx' goes to Farfetch'd for his valuable infos :) Here a small list of game improvements: * Transparency issues in FF6 (semi-transparent people) are solved * Madden doesn't need the 'old coord check' special game fix anymore * Many 'big polygon' troubles are fixed (don't ask me for game names, I only had save states for tests, but I am sure that the users who gave me the saves will notice the differences :)) * The ChronoCross Fort Dragonia scene will now work fine without any game fix (I've removed the old CC fix in this release). Prolly also all other CC scenes with similar glitches are now fine, too. - The 'nVidia FSAA' special game fix is now somewhat stronger, hopefully it will help the games which showed black rects when FSAA was activated. - I was able to enhance my internal texture alignment: there are now less glitches with texture windows when filtering is enabled, and, more important, some small but stupid texture glitches are now fixed as well (for example with Grandia texts, Jumping Flash status displays and a few Wild Arms1 texture garbage happenings). - Ok , that's all... it's getting harder and harder to make real improvements, but I guess that's 'a good thing', eh? :) "Un minuto come un ora come un giorno o forse piu' un minuto anche stasera per dimenticare un minuto un minuto per sempre..." - "Un minuto per sempre" by Prozac+ -------------------------------------------------------------------------12. September, 2002 Version 1.66

- The first improvement was actually the work of Lewpy and E}I{: finally texture window coords are (hopefully) emulated right. That kind of 'repeated texture areas' is often used as background pattern in text boxes, so for example the FF7 text box border glitch was caused by not 100% correctly handled TWs. Well, now it seems to be fine, so FF7, RRT4, Gauntlet Legends and Casper are repaired. There is still a "FF7 special game fix" in my hw/accel plugins though, it's not needed for the text borders

anymore, but it will handle some issues with the offscreen battle hand cursor and the swirl effects. - I've also repaired the FF8 'scanline effect' in the intro of that game Mmm... nothing more to say about it :) - Also related to the FF8 intro: prolly you have noticed that the screens are very slow, even if you have a powerful system. The same slowdowns can been found in the FF7 intro, and some other games as well (as far as I remember during a special 'wave' effect in Persona2, and some transitions in Action Man or whatever it was called). Reason for the slowdowns: the games are uploading hundreds of single lines of screen data each frame, what is a 'bad thing' with modern gfx accelerator cards: the rendering pipelines on the cards stall hard by frequent texture upload/draw actions during one frame. In the D3D plugins the speed can be improved by selecting 'unfiltered framebuffer updates' (since then 'DX surfaces', not textures, will be used for uploading screen data, causing less stalling), but in OpenGL the speed was always slow, tststs. So I've tried certain things to improve the 'upload screen data' speed in OGL, and to my surprise in the current nVidia Detonator drivers the direct buffer draw commands have a very good speed (two years ago the speed was very, very bad). So I've decided to add a 'special game fix' called 'Direct framebuffer updates' in the OGL plugin, which will improve the speed greatly on certain cards/drivers (like my GeForce3 with Detonator 30.82). You can easily check, if your card can handle the 'direct FB updates' at a good speed, by running a mdec (movie) with and without the game fix. If the fix is enabled and speed is the same (or even better), your card is doing fine. If speed is much slower, well, forget it :) Oh, btw, activating the fix will cause more pixelated (unfiltered) mdecs. - And some more FF stuff: I was able to fix the battle transitions and the transparency of certain battle effects (magic spells and such) with FF6. - By pure luck I found a small annoying bug, which caused heavy dancing textures in some games, if texture filtering has been activated. The issue happened since version 1.58, and is of course repaired again in 1.66. - Last and least (ehehe): I think I've seen a news post on www.retrogames.com some months (or years? mmm) ago, announcing a funny display feature in an (non-psx) emulator: the emu had a special display effect, which distorted the screen in the same way as a very old TV, causing a 'cushion' effect. Last week the idea popped up in my mind again (it's sometimes really funny how all that small brain cells are working, isn't it?), and I had to sit down and code such an effect myself. Since it's just a fun mode, I don't expect that anyone will really use it for playing games, and so I've added it only to the Windows OpenGL plugin. Speed will be the same as the 'screen smoothing' mode (btw, you can't use the 'cushion' and the 'smoothing' mode together), so prolly you will need a more powerful system to enjoy it For the best laughes try it on a scrolling 2D rpg game :) Ah, and if someone knows which emu introduced such an effect for the first time, please send me a mail, I really want to know :) "I hear a very gentle sound"

- "When the music's over" by The Doors -------------------------------------------------------------------------05. August, 2002 Version 1.65

- Many users reported me wrong black areas in certain NTSC games. Thanx to Cobra95, by using his Spyro3 save state I was able to investigate and fix that issue. - Lewpy suggested a small trick to prevent FF9 from crashing when framebuffer access is activated. I have followed his suggestions, but still I advise NOT to use the FA options with that game (it will not crash anymore, but glitches in battle will happen). Well, it's up to you :) - I've removed the "FF9 mdec mask bit" special game fix, hopefully now all mdec polygons and mdec texts will be fine without. Thanks to Dimitri for reports and Yazoo for his save state. - Since Lewpy did a very nice dynamic loading of the kernel funcs for disabling screensavers/power saving modes in the P.E.Op.S. soft gpu plugin, I couldn't find any more reasons against a 'disable screensavers' option (without Lewpy's piece of code such an option would have crashed with Win95/WinNT in the past). So, if you were tormented by suddenly starting screen savers while playing a psx game before, you can now easily disable them in the gpu configs. - I've found a small bug in the D3D plugins with the "Unfiltered framebuffer updates - faster mdecs" option. I don't know what games suffered by that bug, but I've decided to fix it nonetheless ;) Oh, btw, I did notice that this option does not (and never will) work right with emulating the psx mask bit. So, if you are seeing flickering displays, or missing stuff, try to turn that D3D option off (OpenGL will always be ok, though). - Finally I was able to find out what was going wrong with the 'Monkey Hero' game (that one was really messed up with all of my gpu plugins), and yeah, I've fixed it. Will be interesting to see what other games will also run better because of the fix (and I hope that speed will not drop much because of it... at least on my system I didn't notice any slowdowns). "Life is the future, not the past - it's the Wizard's Seventh Rule" - "The Pillars of Creation" by Terry Goodkind -------------------------------------------------------------------------10. July, 2002 Version 1.64

- While the last releases were mainly bug fixes and compatibility stuff, 1.64 has only one purpose: to improve the graphics (yeah, we all love that :)) - Ok, the first change takes care about some unwanted texture shaking that was happening in my hw/accel plugins. That doesn't mean that now all psx texture wobbling is magically gone, only some issues caused by the internal texture alignment has

been improved. Thanx to Shadow Lady for the 'shaking Lara' save state :) - And now for the real graphical boost (note: if you don't want to read (maybe boring) background informations, you can skip this part): I was long time no friend to special texture filtering ideas. I always did see big problems arise when the original psx texture data gets changed by filters, and it's already hard enuff to render the original unfiltered psx textures on hw/accel APIs without glitches. Anyway, last week there was a small ngemu forum discussion about filtering again, and to proove E}I{ wrong (who was telling that 2xSaI filtering on textures should work well), I downloaded the latest OpenGL plugin from NickK, to make some screenshots with that texture filtering method. NickK always is a pioneer when it comes to interesting new ideas (like his full screen smoothing or... tada... 2xSaI texture caching), but this time I wanted to use his plugin to show the various problems which will occur with pre-filtered textures (shame on me ;)) Anyway, I've tried all kind of games with his plugin and 2xSaI textures, and yeah, I did see glitches caused by the filtering, but strange enuff not the problems I have expected to see (only some texture alignment gaps and garbage, and big slowdowns, but not the expected texture distortions... good work, NickK, btw :). So of course I had to do two things: a) to apologize to E}I{ for prooving _me_ wrong (tststs, ehehe), and b) to drop a mail to Derek Liauw, the creator and copyright holder of the 2xSaI algorithm, asking him for permission to use his func in my (not GPLd yet) hw/accel plugins. And yeah, Derek happily allowed me to use the 2xSaI func (since he is enjoying epsxe and my plugins, too :)), and I have to admit it wasn't difficult to add to my source... I had to change it somewhat to handle my texture color depths and alpha values, and to avoid problems at the texture area borders, but that was all... - So, a new option in the gpu config is available, called "Hi-Res textures (2xSaI)". You can activate it with all available texture color modes, and of course you can even combine it with filtering, smoothing, whatever. The option will improve the textures in many games, making small fonts more readable, and most textures will look sharper. It even will help the standard bilinear filtering, less 'blocky' look that way and not much black borders. On the other hand some rendering techniques (like multi-layered 2D backgrounds) will cause glitches (thin lines appear, for example, or small gaps between textures), and that is nothing I can fix! So mailing me issues with FF7/8/9 or games using a similar rendering style is useless and will get ignored (well, maybe I will flame a few mailers, depends on my mood :))... and if you don't believe me, feel free to code your own psx gpu plugin and add 2xSaI textures... good luck :) And also be aware of the following: a) your gfx card has to be able to handle 512x512 textures. Otherwise you will get no textures at all. So, for example, no Hi-Res textures on V2/V3 cards and prolly some other older brands as well. b) Hi-Res 2xSaI textures need 4 times as much vram as the 'normal' textures. That means for example that your 32 MB gfx card can handle the same amount of 'hires' textures as an 8 (!!!) MB gfx card with

'normal' textures. And that's not very much, and prolly will cause slowdowns... users with 64 and 128 MB cards will not encounter much speed problems, though... runs great on my 64 MB GF3 with most games :) Finally some tips for using my Hi-Res texture option, if you are having speed problems: - use a lower display resolution, for example 640x480 in 16 bit color depth - use a lower texture quality mode, for example 4-4-4-4 or 5-5-5-1 textures - turn off the 'mask bit' emulation option, that saves some vram as well - don't use the 'screen smoothing' option, and absolutely turn off FSAA in your display properties. - I have seen strange autodetected vram size values in the DX6 plugin with my nVidia GF3 card (I am absolutely sure that I don't have over 80 MB vram, ehe). The exactly same func reports the correct size in the DX7 plugin, though. So maybe a generic advise is to set the 'vram size' value manually to the correct value in all plugins, just to be sure. On the other hand, maybe it will help if you set the 'vram size' option manually to an higher value (for example to '64 MB' even if your card only has 32 MB). Will depend on the game, your hardware and the phase of the moon, though ;) Have fun! - btw, I've decided to keep the D3D-DX6 plugin alive. The 1.63 DX7 changes did help a lotta cards (thanx to all users reporting their results), so the DX6 plugin isn't that necessary anymore, but I've nearly forgotten the poor WinNT 4 users, who can't use anything above DX6... thanx to DarkWatcher for reminding me :) - Ah, and a final note: I've added an extra FAQ file with this release, covering many standard questions. Check it out if you are having problems. "Du musst glauben, du musst wagen, denn die Goetter leih'n kein Pfand..." ah, bah, enuff text for this release, listen yourself: http://www.dhalia.de/musik/sounds/daten/sehnsucht_dhalia.mp3 -------------------------------------------------------------------------23. June, 2002 Version 1.63

- The nicest change in 1.63 (imho): no more "short dmachain" game fix, no more "Ignore dmachain 0" game fix... the handling of bad dmachains is now done automatically without much speed loss. That means you can now play Tekken3, Tekken2, Syphoon Filter, Ghosts'n Goblins, Persona2, MetalSX and prolly some more games without any special options. Ehe, I really like that :) - Another internal change: correct support for write vram wrappings. I've noticed missing textures in a soccer game (can't remember its name, but the players looked funny without heads), that one at least is fixed. - And some more internal adjustments: I've was able to reduce the garbage frames which can happen after/before a 24 bit mdec is displayed. You can see that with FF9, for example. - Also some flickering issues (for example in FF7 after a battle, or in

some Wild Arms1, BOF4 and Silent Hill splash screens) are corrected. The same code will also help drivers which are doing page flipping in fullscreen mode. - Some additional splash screens/menus will get displayed with the highest Offscreen Drawing setting. Still I suggest to use the highest setting only if you are missing some gfx screens. Never use it with FF8/FF9 :) - NTSC games can have a border at the top/the bottom of the display. No, 1.63 can't remove that borders (as a matter of fact the borders are right and needed), but 1.63 will now display the borders most times correctly with a black color instead of a fancy color. Thanx to Gary for some save states :) - A new mode for the framebuffer texture option, called "gfx card buffer & software". Framebuffer textures are needed to get some special effects (swirls, motion blur) right, and they are harder to emulate in hw/accel gpu plugins. The new mode (which is working like in Lewpy's Glide plugin) will help users with slower gfx cards, still a lotta cpu power will be needed. For example the pure "gfx card buffer" hardware mode is much faster on my GF3 compared to the new mode, but on other systems the results may vary... try it yourself, and use the option which makes you happy. Compatibility note: sometimes the new "gfx card + soft" mode will display certain effects more correctly (for example blurring in ChronoCross, or the "enter battle" effects in Legend of Dragoons). - I've removed the the "framebuffer read" and "framebuffer read on move" special game fixes, and combined them together with the old "Full vram primitives" option into a new main option called "Framebuffer access". That way you can control framebuffer effects more easily in the gpu in-game menu. Otherwise the new option works exactly like the old game fixes, use the framebuffer access only if it's needed (Xenogears, for example), and turn it off if it causes problems (FF9 will crash, for example) - By removing the "framebuffer reads" and "dma chain" special game fixes I've now some free slots for new fixes, ehehe. I decided to add two fixes in that release: one for FF9 polygon mdecs (it seems that the 1.62 mask bit handling can cause slight problems, so you can now turn the special handling on/off with the new game fix), and the other game fix is only for the bad polygons in ChronoCross Fort Dragonia (thanx to Nave for a save state). - Last but not least I've changed my texture handling in the DX7 D3D plugin. It should now work fine with cards which needed the DX6 plugin in the past. So please: if you used the DX6 plugin, try the new DX7 one, and mail me if it works correctly on your system. If I don't get negative feedback for a month or so, I will stop the DX6 plugin, since it isn't needed anymore :) "The maidens of beauty and swains so forlorn that carelessly wander away from their home I am off by the moonlight and break of the morning I'll be found in the mountains of Dark Iniseoghain"

- "Dark Iniseoghain" by Dhalia/traditional -------------------------------------------------------------------------29. May, 2002 Version 1.62

- Most fixes and improvements in this version were only possible because of nice feedback and save states from active psx emu lovers. Thanx to all of you :) - Black areas in Bloody Roar 2 are fixed (well, that means you don't have to turn off Offscreen Drawing anymore to play that game). - The radar in Ace Combat 3 is now visible. You will need the 'mask bit' option for it, though. - In the Chrono Cross battle menu the small dots will blink again (I screwed that somewhen in version 1.5x). Since the dots are very small I'd never noticed the bug :) - A new special game fix called "Ignore DMAchain '0'". The dmachain address checks I've introduced in 1.60 worked well with all of my games, but I got a big feedback from "Persona2" lovers (sadly I don't have that game), because it stopped to work with the new funcs. So V1.62 is doing the same checks as the versions before V1.60 (that means that Persona 2 will work without any special option), but if you want to get the "Ranma 1/2" menu screen right, you have to enable the new game fix. - When I played (and finished) FF9 with ePSXe one year ago, I noticed that polygons which were drawn on top of mdecs looked upsidedown. I always thought that it's prolly a main emu bug (sending the polys in the wrong order to the gpu), but now I've investigated the issue more closely, and actually found a solution for it. Everything should look fine in V1.62, you simply have to enable the 'mask bit' option to correct the problem. - I've improved my Offscreen Drawing detections, many annoying flickering effects (like in Rebel Assault 2, DW7, Jumping Flash) are fixed by it (and I hope that speed isn't going down much). - Speaking of Jumping Flash: that game was always really slow in my plugins since it uses a (imho) stupid offscreen rendering technique with lotsa repeated textures (aka texture windows). V1.62 is now using my newest soft plugin functions (the same I've added to the P.E.Op.S. soft plugin V1.6), giving a nice speed up in that game :) - Last but not least: some new eye candy (if you like special screen filtering effectst). "grahf" from the ngemu message boards suggested to try a new filtering mode,and first I didn't like the idea (because I usually see new problems arise with any filtering). But after I've looked what the suggested "Monitor dot matrix" mode is exactly doing (the Kawaks emu is offering such a mode, for example), I didn't find it very hard to add it to my existing scanline functions. So now you can enable it by turning on scanlines and setting the scanline blending to "-1". The best results you will get with 2D games, I think, but of course it's just a matter of taste :)

Btw, I've checked the filter only with my GF3 card, hopefully other cards will not screw the texel alignment (otherwise the filter will look kinda distorted). "Where do we go from here There must be something near Changing you, changing me forever" - "Never Satisfied" by Judas Priest -------------------------------------------------------------------------28. April, 2002 Version 1.61

- I didn't had a lot of time for emu coding in the last weeks, so V1.61 has just a few changes... nevertheless I think the new code is worth an update, so try it and give me some feedback. Speaking about feedback: _don't_ try to send me emails with attachments... I will not even see them. The latest email worms were very annoying, so I use a filter right now, deleting every mail with attached files. If you want to give me save states, pictures or whatever, please send me a pure text mail first, asking if I need the files, and I will reply how to proceed. - The first change is the least important, imho, added on request of some users: while the gpus are running they will prevent the activation of screen savers. Seems to be needed when you are using USB pads and an activated screen saver, since the pad actions will not count as user input, and therefore the saver will kick in after a while. I am using a different approach as syo's code in the P.E.Op.S. soft gpu, we will see how it will work (I've checked it on my Win98 and WinXP systems, and it's ok here). - Re-coded some of my C texture caching funcs in pure asm. That will squeeze out a few more frames per second, at least in games using lotsa textures. Mmm... funny... I needed most of the time for this new functions, but now I dunno what else to write about it :) - The nicest feature in 1.61: I was able to remove the "Adjust extreme coords" special game fix, replacing it with a much better detection of weird running wild polygons (btw, big thanx to calb). The new detection is enabled by default, you can turn it off by activating the "Disable coord check" game fix if you are having troubles (missing polygons, for example). But I checked a lot of games, and the results were very good: no more big poly glitches in Metal Gear Solid, Deathtrap Dungeon, Colony Wars, Timecrisis, Rally Championship, Fighting Force 2, Lucky Luke, to name a few... Well, there are still a few games with problems (like the big polys in one level of Chrono Cross), but there has to be some work left for the next versions, eh? :) "Spark in the nothingness Heat of creation Make the ice start to melt Life wake up in the void." - "Ginnungagap" by Therion --------------------------------------------------------------------------

31. March, 2002

Version 1.60

- Yeah, the easter release :) It contains mainly small fixes, correcting all kind of gfx glitches with certain games (luckily no new config options were needed for the fixes) and speed will also be more or less the same. A small config bug in the ogl plugin has been repaired (a wrong text did show up when pushing the 'nice'/'fast' button in the gpu config), and this time the linux archive _really_ contains the right plugin version, thanx to everybody reporting that issues. Ok, let us have a look at the fixed glitches: - Support for "textured lines" (that means 1 psx-pixel wide textured triangles). "Doom" will now look perfectly, and the water effect in one stage of "Sould Edge" is now fine as well. Thanx to Lewpy for infos and calb for the save states :) - Improved dmachain checking. That will make the start menu of "Ranma 1/2 Battle Renaissance" visible (thanx to tatunoko for the save state), but I've noticed that now Tekken2 will need the "short dma chain" special game fix (otherwise you will have to wait a long time until the game starts up). Ah, and no, Tekken2 is not playable right now (streched polys), but that's a confirmed main emu bug, the gpu plugin can't repair it. - Interesting internal adjust of Texture Window coords. That's needed for some "Tales of Destiny 2" graphics, thanx to E}I{ for very helpful infos and save states :) - Improved sprite texture coord wrapping. That will fix garbage glitches with "Tales of Destiny 2" as well, and the clouds in a special level of "Wild Arms" are now fine, too. - Faster sign checks, that will prolly not give a noticable speed up in my hw/accel gpus, but it's looking nicer in my source code, ehe :) Thanx again to E}I{ for suggestions. - The "moon" symbol in "Devilsummoner Soul Hackers" (wow... what a name...) is now displayed correctly, thanx to gunshinn for a save state :) "It's just the same as imaginary snow in summertime Never able to make winter come." - "Isn't it?" by Wild Silk -------------------------------------------------------------------------23. March, 2002 Version 1.59

- First of all: the FF7 battle swirls are now working (they should have been working in 1.58 already, but a last minute fix disabled them). You have to enable the FF7 special text border fix, use the highest Offscreen Drawing setting, enable the "gfx card" frame buffer textures and the "Framebuffer read on move" game fix is also needed (oh my). The performance of the effects will (as always) depend how good your card is supporting framebuffer accessing. But it's fine on my GF3 ;)

- The Lunar1 special game fix is now available in the hw/accel. plugins as well. That will repair the black screens when entering a house or a menu in the same way as in the P.E.Op.S. soft plugin. Ah, and talking about special game fixes: I've decided to combine the nVidia FSAA fix with the ATI subtract blending fix in the OGL plugin. Since both issues are bugs in the drivers, (hopefully) fixed somewhen with one of the next driver releases, I didn't want to waste too much of my (up to 32) possible game fixes ;) - A few games were showing wrong MDEC colors due to some lines of code I've included for doing screen centering. None of my games had shown that glitch, so I can't be 100% sure that this issue is completely fixed, but there is hope ;) - A new texture option, called "Faster palettized texture windows". Well, texture windows (mostly used in psx games for text box background gfx, or in some racing games) are having a separate cache in my hw/accel. plugins, and that one is working fine for most games... I have seen only one game (Ghost In A Shell) which is stressing the cache so much that the game crawled at 40-50 fps on my system (quite unusual). The only solution I've found for that game was using pal textures, causing a fine speedup (2 - 3 times faster). So, if your card can handle pal textures (like GeForce cards with newer drivers), you can safely enable the new option, otherwise (TNT cards for example) you cannot use it at all (a filled Smiley sign in my gpu menu will show you if the option is working). - Biggest change: improved "texture garbage collection" option. When I introduced that option in 1.58, I just did an easy approach to reorder the internally used texture space, to check out if the function is working okay. Well, the new version does a much more complicated job to optimize the texture usage, we will see how that code will work on less powerful cpus/gfx cards (it's very fine on my Athlon 1.2/GF3 system). Still: the cleanup will only kick in, if it is really needed, most games will not activate it anyway. Games needing the garbage collection _may_ stall the game for a short time (while doing all the texture optimizations), depending on your system's power. "Schume nur mein wildes Herz, in des Zornes Wehen Bin aus leichtem Stoff gemacht, muss wie Luft vergehen Ohne Schiffer treibt mein Kahn, auf des Meeres Spiegel Niemals fesselt mich ein Band, riegelt mich ein Riegel Suchte meinesgleichen, fand nur Snder ohne Zgel" - "Lebensbeichte" by In Extremo -------------------------------------------------------------------------16. February, 2002 Version 1.58

- Damn, since the release of 1.57 I couldn't stop gpu coding... so it took only two weeks for a new release this time. Well, enjoy :) - To help gfx cards with slow texture uploading speed and/or a very limited vram size, I've coded additional functions which will optimize the texture usage even more. Of course that will mean a little bit more work for the cpu, but hey, somebody has to do the job... Ok, so, if you have encountered irritating slowdowns in your

game (caused by the gpu, NOT by cdrom accessing ;), you should give the new "Smart texture garbage collection" option a try... even my GF3 does like it in some games (well... it doesn't matter much for me if a game runs with 100 or with 300 fps, but if it does help my system, it should help slower ones even more). Oh, and one more hint about the texture caching: some users reported a big speed up by selecting "64" Mbytes vram on their 8 MB cards... - Hurray, hurray... one "special game fix" has been removed: The "no sprite transparency" one for the Oddworld games. Those formerly "special fixed" glitches are now confirmed main emu bugs, so the option will be useless with the next epsxe release anyway. And since that fix did cost a lotta additional testing in the soft funcs, I've decided to remove it as soon as possible... and that's now :) - Hurray, hurrraaarrrggg: Oddworld fix is gone, and a new fix has taken its place instead (in the OGL plugin). nVidia is well-known for their good and fast OGL ICDs, but there is a stupid bug (at least) in the W9X 23.51 drivers: if you are using FSAA with OGL, the driver will reset the alpha testing state each frame, causing black areas and other glitches in my OGL plugin. Well, the 21.xx WinXP driver is doing FSAA fine, as far as I could see, but if you want to use FSAA in W9x you should enable the new special game fix... or pray to nVidia to release drivers without that bug. - Improved psx vram moves, that will fix glitches with a few special effects in FF9 and BOF4 (seen in certain magic effects during battles). Mmm... and most times "full vram prims" and/or a certain framebuffer setting is needed to get such effects right. - Wrapped sprites will work perfectly again (they were broken in 1.57), so the glitches in (for example) Tales of Destiny 2 are gone (thanx to expert464 for the save state). - Oh my... some optimization I've done in version 1.20 (or so) of the OGL plugin caused missing tires in "Driver", screwed hair in "Blaze&Blade" and prolly it was responsible for some more screwed textured polys. That issue is fixed as well. - Improved the Offscreen-Drawing detections. Much cleaner now, and as far as I remember the FF8 "distant hill flickering" will be fixed by that... mmm... and the FF7 swirls should be visible with hw/accel. FB textures, using the highest OD settings. - And finally: screen smoothing. This new option will blur the whole screen, so especially 2D games will look less pixelated. It will need a good gfx card, though (something in the Geforce class should do the job), and the higher the used resolution, the bigger the slowdown with screen smoothing. Activated smoothing will cost around 1.5 - 3 MByte vram (no big issue with my 64 MB GF3, ehehe), and your gfx card must be able to use textures bigger than 256x256 pixels (well, that means for example no smoothing with 3dfx V2/V3 cards). Anyway, if the option does work fast enuff on your system, and you like the smoothed look, use it... if I did everything right, there will be

no emulation compatibility issues at all. Oh, a small hint: of course you can combine the old texture filtering with the new screen smoothing, the results are really nice most times. Oh, and another remark: yes, motion blur would be also possible. But, no, I will not include it in my gpu plugins. I will leave that effect to NickK's NextGL/Next3D plugins, his gpus are getting better and better with every release, so go and check them out :) "Those are the pictures of what was of what is of what is to come We are the people the rolling people the why people the waiting people the wanting people..." - "Altamont" by Aphrodite's Child -------------------------------------------------------------------------04. February, 2002 Version 1.57

- Let's start with the biggest change: I did a big cleanup in my texture caching code. Now you can't select between different caching modes anymore, the plugin will work with a slightly optimized "dynamic" caching method. Still there is an option in the gpu plugin config window, which is controlling the behaviour of texture caching: "Gfx card vram size [MBytes]". Here you can select "Autodetection", which will work without problems on nVidia cards, or enter the size of your gfx card's ram manually (needed for example on 3dfx cards in OpenGL mode, but prolly it's safer with other vendors as well). A wrong big value can cause heavy vram system memory swapping, you will notice that when the game speed is slowing down without a reason, and a much too small value can cause an heavier cpu usage and constant texture uploading, so it's up to you... :) Well, some examples: - with D3D, all cards should be reporting the correct vram size, so you can set it to "Auto" as long as you don't want to make some experiments ;) - with OGL, nVidia cards will report the correct vram size as well (at least they did the last time I've checked it =), so you can use "Auto", too - Other vendors may need some tweaking in OGL: Gfx cards with 64 MByte (or more) will always be fine, you can set the vram size to "64", enable FSAA or whatever, and be happy. With gfx cards less than 64 MBytes you should be more careful, try first to enter your real gfx card vram size (for example 16), and if you notice slowdowns you can try to lower the size (15, 14, 13...) to get better speed. Ah yes, and if you have an onboard gfx card you can try to set a much bigger value to get

the best speed. - OK, so the different caching modes are gone... no need to get sad, though. With just one mode left, I was able to improve my texture alignment further: now FSAA will work better, and some of the filtered textures will not look as blocky as before (yes, there are tile edges in the filtered modes, yes, I know, no, I can't do nothing about it, sorry). Still some adjustments have to be done with textured windows, ah, but that's for another day and release. - Improved some dma chain checking, now certain games which were showing black screens before will be running without problems (for example The Mummy or T'ai Fu). - Changed (again) my MMX palette code, finally it seems to be working without any problems. For example the battle menus in FF4 are ok, maybe even the red/yellow cards in Winning11 will be visible again? We will see :) - A new special game fix has been done as well, this time it's a goodie for all Capcom 2D fighter fans: you can enlarge the screen area at the right side of the display, and see all the background gfx without any cut-off (well, glitches can happen, too, you are warned :) - And some more small changes :) "I've been searching everywhere Looking for the final freedom Where there are no boundaries When you never need a reason Well, it has been taking me some time 'Till I've got it what I've tried to find" - "Welcome to the other side" by RAGE -------------------------------------------------------------------------06. January, 2002 Version 1.56b

- OGL/D3D plugins: the fullscreen/window toggle blending fix screwed sometimes the transparency mode on startup. Therefore version 1.56b fixes the fix :) -------------------------------------------------------------------------05. January, 2002 Version 1.56

- OGL/D3D plugins: New special game fix: "Adjust extreme coords". It's the same fix I've included in the P.E.Op.S. soft gpu 1.3, it helps a few games showing weird polygons running wild across the screen. So, try to enable it if a game is having polygon troubles, but don't use it as default setting (because games which doesn't need that option might get screwed). And, no, it doesn't fix Tekken 2. - OGL/D3D plugins: I've also included all new soft funcs (for Offscreen Drawing) which I've changed in the P.E.Op.S. soft gpu 1.3. Not a big deal, though. - OGL/D3D plugins: my texture caching on 15 bit psx textures had

a small bug, it wasn't caching the transparency bit. Thanx to Matesic Darko for telling me about the problem. - OGL/D3D plugins: smashed a sprite Offscreen Drawing bug which has been crept in with version 1.54. The Medievil 1 gravestone menu is now fine again. - OGL/D3D plugins: repaired a small texture window sprite overlapping issue. The Guardian's Crusade in-game menu is correct now. - OGL/D3D plugins: improved my MMX color lookup table code. Some color rotation effects (Vagrant Stories, Blaze&Blade water) are finally working perfectly. - OGL/D3D plugins: sometimes blending was screwed after toggling between window and fullscreen mode. Thanx to JNS for kicking my ass until I've fixed that ;) "On the day of the night things were always well But on the night of the light all night things fell" - "Mystical End" by Iced Earth -------------------------------------------------------------------------02. December, 2001 Version 1.55

- The SOFT gpu has gone Open Source and is not part of the archive anymore. You can find newer versions of the soft gpu (renamed to P.E.Op.S soft gpu) at: http://sourceforge.net/projects/peops - OGL plugin: the "Framebuffer read" and "Framebuffer read on move" special game fixes were giving a yellowish display some times. That's fixed. Still my old advise: activate the FB options only if you really need them, some games (FF9 for example) will not work if the options are turned on. - OGL/D3D plugins: repaired a small scissoring issue and coded a new special game fix... this time it's an option called "Lazy upload detection", and it can be used with Dragon Warrior 7, to repair the flickering effects with text boxes in that game. It's not a 100% fix, since the text boxes will not get semi-transparent if the fix is enabled, and the bkg graphics will not be animated anymore, but at least the flickering is gone... well, you can also turn off the fix and turn on "Full vram primitives", if you have a powerfull cpu, that will emulate the text boxes more accurate, but the bkg gfx will get ugly low-res... well, it's up to you :) I only had a save state, not the full game, so I can't tell you if there are more issues with DW7... but if the rest of the game is coded like the text boxes (using a third display buffer for uploads, bah), I am sure there will be more problems ;) Oh, and the text boxes are using the psx mask bit as well (sure... simple pseudo triple-buffering would be too easy ;) So if you don't see any text boxes at all, try to turn off the "mask bit" gpu option... that will help gfx cards which don't like my mask bit emulation.

- OGL/D3D plugins: tadaaaa... two additional filtering modes... most of you will know the problem with filtering pre-rendered background graphics (the gfx will have a tiled look if filtering is enabled). Well, my advise in the past: use "filtering without sprites", since most games are using sprites for the bkg scenes, and personally I think it's better to have a pixelated display than staring at annoying box edges. My new advise: use "filtering with smoothed sprites" :) Sprite smoothing will work fine with many games (yes, yes, including FF9), and I hope it will not cost too much speed on an average system. Of course it will not help games which aren't using sprites at all (for example Wild Arms), and it will produce glitches with other games (like Legend of Dragoons or FF7). Still it's a good choice for many sprite-based games and rpgs. "Since we've reached the point of no return We pray for starlight, we wait for the moon The sky is empty Alone in the unknown We're getting nowhere" - "And then there was silence" by Blind Guardian -------------------------------------------------------------------------04. November, 2001 Version 1.54

- All plugins: finally I have added psx polyline support to the "WriteData" interface funcs. Polylines were only supported in dma chains before, and, to be honest, I haven't seen any game using them outside of dma chains. Well, Matesic Darko's great GPU Test Windows application is using polylines without dma chains, so I have used that one to check if all is working fine. Btw, you can get the GPU Test app at: http://mrdario.tripod.com in the "Tools" section. - OGL/D3D plugins: Xenogears... yup... well, that game is using a hard to emulate framebuffer texture/framebuffer move combination in cutscenes and transition screens, which only could emulated properly by using "Full Vram primitives" in my hw/accel. plugins before. FVP tends to need a lot of cpu power, so I've looked if I could do an option to let the gfx card do most of the work... and there it is: a new special game fix called "framebuffer read on move". Unfortunately reading the gfx card framebuffer is also slow with most nowadays gfx cards, so I dunno how it will perform on average systems. Speed is fine on my GF3 in OGL, and kinda slow in D3D. So, my advise: use the new option only in Xenogears, or if you want to try to remove similar glitches in other games. Btw, XG needs the new FBOM option with activated "gfx card" framebuffer textures and don't use the highest Offscreen drawing setting! Oh, and I removed the special game fix for Tomb Raider 3... that one only was needed in the old PSEmu Pro emu to repair some of the GTE bugs, but since all newer emus can play the game

without the fix, I don't think that it is needed anymore. - All plugins: the biggest change in 1.54: all software drawing funcs have been redone (lotta work), and the new soft gpu is now up to 20% faster than before. Therefore also the Offscreen drawing and FVP options of the hw/accel. gpus have gained more speed. Another nice thing with the new soft funcs: g-shaded quads are now rendered in the real psx way, check out the quad polygon in the first Sony BIOS screen (hi Galtor :) On the other hand there is a very small chance that little g-shaded textured quads get slightly distorted... during my tests I didn't notice anything bad, but if you encounter some new glitches, drop me a mail. - OGL plugin: while adding the new soft funcs in the OGL plugin, I've noticed that the D3D plugins had a bigger security psx vram area, preventing nasty crashs. OK, now the OGL one has it, too. - Announcement: 1.54 was the last release of "Pete's Soft GPU"! Why? Well, I have done all I wanted to do with the soft gpu plugin, and I think the time is right to go Open Source :) So, in a few days the Windows & Linux sources of the soft gpu plugin will be released, but what does that mean exactly to the users of the soft plugin? 1.) the name of the plugin will change... not a big deal, I think, but I don't want to label a plugin with "Pete's whatever" when (hopefully) a lotta more people beside me are working on it. 2.) improvements in games I don't own myself... I can't investigate some issues if I don't have the game, but now the chances will be higher that another coder is able to fix the problem. 3.) more features I never cared about... maybe a smarter frame skipping? or a native FPSE interface? some special gfx modes? Dunno :) 4.) the plugin will not get bundled in my "gpupete" archive anymore. We will have to wait and see how often a new release of the OS soft gpu is happening... And what does it mean to the psx emu/gpu plugin coders out there? There will be much informations in the source, for example the proper usage of the gpu interface, fps handling and, of course, the soft drawing funcs themselves. OK, so: 1.) the license will be GPL 2.) still I don't want to force any freeware coder to go Open Source himself, if he is using parts of the soft gpu source in his work. So, I will allow the usage of the soft gpu funcs in closed source projects, too, if a) the project is freeware b) credits are given c) any improvements in the open source funcs are reported back to the Open Source project. I hope that way everybody will be happy :) And if the OS way is working well, chances are high that my hw/accel. plugins will go Open Source, too :) "Pissing in a river, watching it rise Tattoo fingers shy away from me

Voices voices mesmerize Voices voices beckoning sea Come come come come back come back Come back come back come back ... Should I pursue a path so twisted ? Should I crawl defeated and gifted ? Should I go the length of a river, (The royal, the throne, the cry me a river) What about it, what about it, what about it ? Oh, I'm pissing in a river." - "Pissing in a river" by Patti Smith -------------------------------------------------------------------------07. October, 2001 Version 1.53

- All plugins: the 1.52 fps limitation bug fix for special chipsets seems to work fine (thanx to all users reporting it), so I've added the fix also to the displayed fps rate, and to the 'Use PC fps calculation' option. - All plugins: added a "copy settings to clipboard" button to the gpu config dialogs. A simple mouse click will now transfer your current gpu settings to the clipboard, you can paste them into bug reporting mails or forum messages. Unlike Lewpy's similar func I don't include your cpu speed, OS, etc... only the pure settings and the name of your gfx card. - OGL/D3D plugins: again small adjustments in the screen upload detection, for example the GT1 main menu will be fine now, the Soul Reaver (demo) menu will get displayed and the Aeronauts (demo) language selection is shown. As always the advise: if you are missing some menus or screens, play with the Offscreen Drawing settings. If there is garbage in the screen border areas, play with the Offscreen Drawing settings. If you are feeling bored, play with the Offscreen Drawing settings ;) - All plugins: fixed a small scissor problem which could happen on very rare occasitions (if the game was using strange screen centering values). The text boxes in Star Ocean 2 will now pop up fine with the D3D/OGL plugins. - All plugins: I've improved all triangle soft drawing funcs, you will get a small speed increase with the Soft gpu in games using lotsa triangles. Since the hw/accel. gpus are using the same funcs for offscreen drawing and full vram primitives, a small speed increase can happen with them, too. Thanx to Lewpy for suggestions :) - OGL/D3D plugins: if you are using the "gfx card buffer" frame buffer textures option, you prolly will have noticed shaking screens effects in some games (for example sometimes in ChonoCross battle screens, in Alundra2 underwater levels/cutscenes, in Megaman Legend 2 water/desert stages, in some AITD4 effects... yawn). Well, what to say? It's fixed :) "And what have started long ago Is heading towards the end

There's no easy way out There's blood on my hands But I am sure in the end I will prove I was right Runes of a long forgotten time Ancient spells in endless rhymes Soon the other world appears Roam to the ghostly river Rhine Leave the misty shades behind I can feel I'm getting near" - "Blood On My Hands" by Demons & Wizards -------------------------------------------------------------------------26. August, 2001 Version 1.52

- All plugins: I've added some code to list all available desktop resolutions of your gfx card. That way you have a bigger choice for the gpu fullscreen modes (and I don't have to add more and more resolutions in every gpu release ;) - OGL plugin: changed the "InitFullScreen"func. I hope it will now work better with certain cards, and with the W2K OS. Please note: toggling between the window/fullscreen mode (ALT+ENTER) is still unstable, if your desktop color depth is not the same as the desired fullscreen mode. - All plugins: Lewpy told me about a bug with high performance counters. Our plugins are using such counters to calculate the framerate and to do the fps limitation. The bug will show up only on certain chipsets under heavy PCI bus load, and it can cause weird speed behaviour with our gpu plugins. I've tried to make a workaround for that issue, let us see if it helps (no problems on my system, so it's hard to check by myself...). If you want to know what MS is saying about that bug, or check out if your chipset is known as buggy, look at: http://support.microsoft.com/support/kb/articles/Q274/3/23.ASP?LN=EN-US&SD=g - All plugins: my new system (Athlon 1.2C, GF3) is very fast... that's fine, of course, but it also brought me some troubles: usually I play psx games at the 'auto-detected' speed (50 or 60 fps), and if some (boring) scene happens, or if I have to do some (uneventfull) walks in the game, I just turn off the fps limitation in the gpu menu. On my old system (P3-550, GF1) speed usually doubled, so I had a kind of 'fast forward' function, until I enabled the fps limit again. Well, on my new system the 'fast forward' tends to be a 'hyperspeed forward', making walking around nearly impossible... so I've now enhanced the old "limit on/off" switch in the gpu menu into "limit off", "limit manual setting" and "limit autodetect". that way I can toggle between "auto" and "manual" (I set the manual value to 120 fps), and now I am happy again ;) - All plugins: if you are running a game at a "manual" limited framerate, you can change the manual value in the game using the gpu menu: set the menu arrow to the FL option, and press SHIFT + HOME or SHIFT + END. On each keypress the manual value will in/decrease by 1 FPS, so you can try to adjust the manual

value within the game to a framerate which suits you. - SOFT plugin: oh no... a glitch! In my 'oh-so-compatible' soft plugin! While checking out a few game demos I've noticed a wild shaking screen in the Pandemonium2 demo. After a little debugging I've pinpointed the problem to wrongly called psx vsync signals from ePSXe. So I've double-checked the demo with FPSE, and to my surprise the vsync calls were even worse (in ePSXe the vsync comes at a wrong time with that game, in FPSE the vsync comes at a wrong time AND far too often...) Ah, well, to get around the bug I made a 'special game fix' for P2. It's called "Lazy screen updates", and if you want you can try the option also with other games, they may become faster if it is activated. Of course it can also cause unwanted side-effects (missing parts of the screen, for example), so use it with care. Btw, in the hw/accel. gpus Pandemonium2 needs also an (already available) option, the "Swap front/back detection" special game fix. Btw, part 2: the psx vsync is very important to get the 'right' FPS limitation, so don't be surprised if some games are running at a wrong speed in FPSE... the only way to get around that problem (beside a fix in the main emu core, of course) is to set a manual FPS limit until the game 'feels' right (the new in-game "manual FPS limit adjust" as described above can help you with that). - OGL plugin: and another special game fix... pfff... well, it's not really a game fix, it's more a 'bad OpenGL ICD' fix... in version 1.51 I've introduced a perfect "subtractive blending" mode, if the gfx card driver is reporting it can do it. Well, I should have guessed that some vendors will report they can do the feature, but in reality they just screw it (did I say S2000? no, I didn't ;) You can now force the gpu plugin to ignore the OGL extension for subtractive blending by the new game fix. - OGL plugin: "keep psx aspect ratio" option. In version 1.50 I did that option for the soft plugin, now it is available in the OGL plugin as well... it does a 'ratio correct' stretch in x/y, causing lotsa screen borders , of course. Use it, if you like it, or turn it off (like I do ;) I am not sure if I should code that option in the D3D gpus as well (it's really lot of work) . - OGL/D3D plugins: in december 2000 (version 1.42) I made the black scanlines option, promising that all requests for 25% or 50% scanlines will get ignored :) While looking for new ways to improve the image quality, I stumbled again over the scanline func, and played a bit with it... the result: you can now set the scanline brightness in a range between 0 and 255. 0 is like it worked before (black scanlines, dark display), higher values will make the scanlines brighter (blended over the image, not just simple lines in one color)... I suggest to try a value of 200 to get a nice smoothed display, of course it also depends of the used resolution and your personal taste :) - OGL/D3D plugins: some small changes in compatibility: when you play FF7, using the special game fix for the text box borders, the battle hand cursor will also be fine now. Also I've tried to remove some screen garbage which showed up occasionally in some games (usually between splash screens), if your OD mode is 3 (enhanced) or smaller.

"It's not the end Not the kingdom come It is the journey that matters, the distant wanderer Call of the wild In me forever and ever and ever forever Wanderlust" - "The Wanderlust" by Nightwish -------------------------------------------------------------------------06. July, 2001 Version 1.51

- All plugins: _Demo_ suggested to use a 59.94 fps NTSC timing (instead of the old 60 fps one), if autodetected fps limitation is enabled. Well, done... (don't ask me if that will improve anything... most of my games are PAL ones anyway :) - D3D plugins: I wanted to add a few more fullscreen modes to the D3D plugins in version 1.50, but somehow I've forgotten to add the 320x240 and 320x200 D3D modes, tsts. Oki, fixed. - All plugins: it is now possible to redefine the gpu hotkeys in the gpu config windows (look for a small "..." button). - OGL/D3D: added some mmx asm to squeeze out a few more frames per second. The optimizations were done in my texture caching funcs, the speed increase will be in the range of 0 - 10 more fps (depends, as always, on the game and your pc specs). No mmx was added to the soft gpu (main reason: most time in the soft gpu is used up in the per-pixel blending funcs, and that ones are very mmx-unfriendly right now... well, I've checked out some other optimizations in the soft gpu, giving me around 2 additional fps, but the gpu dll size was doubled and the code was a really big mess, so I've dropped that again). - OGL plugin: the best is yet to come: 100% perfect subtractive blending! Well, one of the psx blending modes is hard to emulate in hw/accel. gpus, because that kind of blending was not supported on older pc gfx hardware. But lately I've found an OGL extension to get that mode right, and luckily my GeForce1 DDR card can do it without problems. Version 1.51 of the OGL plugin will check your card's opengl capabilities, and enable that special blending mode, if it is available. Prolly all GeForce cards can do it, I don't know if it is supported on other cards as well, though. The gpu ingame-menu will show a little 'moon' symbol, if the extension can be used. Of course the gpu plugin will fall back to the old blending func, if it's not possible to use it. Quite easy, no special option needed :) You will notice the new blending mostly with correctly faded menu backgrounds in FF9, or with darker shadows and lighting in CC. Oki, and now let me answer some new FAQs _before_ they have a chance to get FAQs ;) 1. Q: Is it possible to do the new mode in the DX6/DX7 D3D plugins? A: No 2. Q: Would it be possible in a DX8 D3D plugin? A: Yes

3. Q: Will you code a DX8 D3D plugin? A: No... at least not in the near future :) Ask Lewpy to do one... :):):) - All plugins: there is _no_ new option for the wrong mdec colors with fpse 0.9! I did think alot about it, if I should do a 'special fpse game fix' or something like that, but in the end I've decided against it. Why? Well, the wrong colors are caused by fpse, not by the gpu plugins, and I think in terms of compatibility it was a bad decision by the fpse team. And if I would do a special fix, hey, maybe the fpse team would never correct the colors... and maybe the next emu team would decide to display the mdecs up-side-down, and I would have to add another bunch of useless convert funcs... nonono ;) And one fpse member already told me that they want to fix the mdec issue themselves, so hey, don't worry :) "There was a man found hanging in a jail cell And they said it was suicide A man was found hanging in his jail cell And they told me it was suicide Now you can blame the social system But I still say it was his necktie" - "Necktie" by Michelle Shocked -------------------------------------------------------------------------24. May, 2001 Version 1.50

- D3D plugins: sometimes there were disturbing lines in unfiltered mdecs on Matrox cards. Fixed. - OGL plugin: because of PSEmu Pro I always had to do a delayed gpu init (otherwise the screen would stay black in this emu). Well, I've noticed a problem (crash, boom, bang) with one demo because of that delay, so I do now some more 'init' checks. - SOFT plugin: a new stretch option: "scale to window, keep aspect ratio". That one will keep the original psx screen proportions, of course you will get black screen borders, if the aspect ratio doesn't match your window size. That option is much harder to do on the OGL/D3D gpus (because many of my funcs are relying on a fully rendered window), but maybe I will do that in a later version... we will see :) - OGL/D3D: a new special game fix for FF9: "G4 polygon cache". If it is activated, the yellow character selection rect in battle mode will be displayed. All cudos are going to Lewpy, who has developed that fix :) Btw, enable it ONLY with FF9. No other game will need it, and it can cause glitches! - OGL/D3D: a workaround for horizontal wrapping display positions. Now my XPloder demo cd is working, maybe it will help with some more 'black-screen-only' games, too. - OGL/D3D: Thanx to Gabi, who did send me her original RRT4 game cd, I could investigate (and fix) some more

glitches: * disabled screens are now handled more correct. That means: less garbage with some games (like the garbage in RRT4 before/after mdecs). * clipping areas with a width/height of 0 are now fine... It seems that sometimes I do too much checks ;) The disturbing bottom menu boxes in the RRT4 menus are gone. * Changed my line offset code a little bit. Result: less disturbing dots/lines in RRT4 (most times while driving below bridges). - OGL/D3D: fixed a wrong clipping area which was caused by toggling between fullscreen/window mode. Because of that bug sometimes only a part of the screen got updated after switching to fullscreen mode. - All plugins: I've changed the gpu config dialogs, so now there is a better description for most options. Don't get shocked when you are opening the config window for the first time :) In the D3D/Soft plugin you will also find some more fullscreen resolutions (added by user requests). - All plugins: Well, if you have visited www.psxemu.com, you will already know about the new "save state pic" feature. Of course the main emu has to support it, and right now there is no released emu with that ability yet, but hey, we are prepared :) You can still check out that feature, though: when you hit the "INSERT" key, and no fps menu is displayed, you will see a nice pic with the gpu version number. If the fps menu is enabled, a description text of the selected option will be shown instead... kind of an online help :) - OGL/D3D: I've hidden an easteregg... yup... a very slow one, though... try to find it... I will tell no more, all requests to reveal it will be ignored :) Oki, just one thing: somewhere I've placed an _obvious_ hint how to activate it... "Master of the lightnings, rider on the storm, wearer of a crown of swords, spin ner-out of fate. Who thinks he turns the Wheel of Time, may learn the truth too late. (From a fragm entary translation of _The Prophecies of the Dragon_, attributed to Lord Mangore Kiramin, Sword-bard of Aramaelle and Warder to Caraighan Maconar, into what was then called the vulgar tongue ( circa 300 AB))" - "The Wheel of Time" by Robert Jordan -------------------------------------------------------------------------28. April, 2001 Version 1.49

- OGL/D3D: improved my screen clearing detection, so some garbage borders (like the ones in Legend of Mana) are now history. RIP :)

- D3D plugins: while doing the above mentioned improvement, I've noticed a wrong clipping on block fills in the D3D plugins. The OGL plugin was fine, though - All plugins: Lewpy suggested to do some more coord checks like the ones needed for the silent hill maps... well, it's done, and it doesn't seem to hurt, so we give it a try, eh? :) - OGL plugin: fixed a stupid bug which caused the gpu to crash after a race in GT2 when offscreen drawing was enabled. The D3D plugins only worked because of some strange kind of luck ;) - OGL plugin: a wrong ZBuffer init caused troubles with some games, if the mask bit detection was enabled (for example: wrong shadows and missing texts in GT2). Conclusion: never forget to remove debugging code... tststs - OGL/D3D: I've tried to get more game menus/splash screens to work. Currently the screen detection is a real mess... but always when I've started to recode the funcs, I've ended up with the same zillions checks. So I decided to leave the funcs in the current state, and just to add a few more or less clever lines of code if the "Offscreen Drawing" mode is set to "4: extended". The new code works not too bad in g