--------------------------------------------------------------------------

29. december, 2005 version 2.08

- trickyfree suggested on my messageboard to have some different types

of the display stretching. ok, done: beside the old "full screen
stretching" and "keep psx aspect ratio" modes, i've added two more
ways to stretch the psx display to your screen.

- shadx and guest(r) are still doing amazing full screen shaders for
the ogl2 plugin. therefore you can find many shaders in the
messageboard section of my site (http://www.pbernert.com). to make
the shaders somewhat faster, they suggested to get additional pre-
calculated values from the plugin. done. now the "ogl2invsize"
uniform is available for new glslang shaders... let' em coming :)

- well, i have got a geforce 6800 ultra card over half a year ago, and
while trying to make this baby sweat, i've added an "ultra high"
internal y resolution mode. if you want to activate this, you will need
a card with 4096x4096 texture size support (newer nv cards or ati's
1xxxx ones), and 256 mb vram is also recommended. by the way:
the rendering speed will still be very high with this new setting,
but psx framebuffer effects can now last a couple of seconds (!!!).
therefore this "ultra" resolution is not really usable with psx games
which are doing much fb effects. you are warned :)

- in july 2003 i've started this psx ogl2 plugin. basic idea: don't map
the psx drawing commands on-the-fly to the pc's gfx card's backbuffer
(like my standard ogl and d3d plugins are doing it), but to create a
offscreen buffer in the same size as the real psx gpu vram (or a
multiple of it), and draw into that buffer. well, by this time the
only way to do this was to use "p-buffers" in opengl, and yeah, i got
it to work nicely.
much later (spring 2005) a nicer way to handle offscreen buffers were
added to the opengl specifications, called "framebuffer objects".
fbos promise a better speed, and are easier to handle than the clumsy
p-buffers, so i finally decided to add them in my plugin as well.
you can change the render mode in the plugin config, if you are looking
for some more speed, but to be honest: on my system every psx game
runs like mad (without frame limitation), so i cannot tell if fbos
are really faster. you have to try it yourself...

"the leading horse is white,

the second horse is red,
the third one is a black,
the last one is a green."
- "the four horsemen" by aphrodite's child

--------------------------------------------------------------------------

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 removed all of them from the plugin
archive, you can get them seperately from my homepage
(http://www.pbernert.com).
simple reason: i can update them (or even add new ones) without the need to
create a new plugin release. ah, and 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-
texture
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 including
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" directory
in
the main emu directory or in the plugins sub-directory (at least for epsxe,
dunno
right now if all plugin supporting psx emus call their plugin directory
"plugins").

"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 only

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 for
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 the

psx gpu's vram, and reads it back later (so it uses the vram as some kind of
swap
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 crashes
("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
texture
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,16,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 are
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 psx
texture windows in a special way: get the texture data, scale it up to power-of-
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
windows"
to get a good speed).

needless to say that the disavantages were always a thorn in my side...

especially
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 pixel
shaders :) i've created a shader which is able to emulate texture windows
perfectly
 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 were
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 cards seem to produce all kind of glitches. well, that was no big
surprise to me (i was more surprised that it worked at all), no way around
that, as far as i can see.
* geforce 2 cards are not fast enough to run that plugin at full speed. also no
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 also
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
somewhere
outside of the plugin) makes it impossible to track down the real reason.
currently it really seems to be a winxp gf3/4 detonator driver bug, since
older
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, imho.
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
even
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 touch

a fx5200 (or any nv card with a "mx" brand) with a stick... same is true for
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
filtering,
there was also one flaw detected: fsaa will not work with the plugin (it will
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 relax
:)

- 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 other
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
past),
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_strip"

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
missing
on ati cards, tsts. of course that's also fixed.

- various small cleanups. dunno if the speed will increase significantly (i doubt
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 (beside
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'
works also with
the "rpg maker" screen fading effects, btw.

- this plugin was designed to use nowadays gfx card's capabilities to improve the
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
extensions,
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
fullscreen
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 nice

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
them
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"
option.
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 r9700pro
in
mind... they are using up to 8 texture units! that means that all cards with
less 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
"gpupeteogl2.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 included
already two sets of shader files in this archive... one for doing a "black &
white" effect,
and one which is doing a very simple smoothing (using only 4 texture coord
units, so
it will work with less powerful cards as well).
experienced gfx coders can of course change the files and try to create even
more
 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 (meaning:
zillion of glitches in this stage, and speed not to bad) on my development system,

and a few lucky beta testers were also able to run it, but it seemed like it
wasn'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 tweaks
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
(important
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 that
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 with

high compatibility... i call it "pete's opengl2 plugin, version 2.0", since i will

port it to 'real' opengl2 as soon as it's possible. right now it only uses
'standard'
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 hard
(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 compatibility

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 easily
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 course
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 standard
 "high y" and "high x" mode will be good as well... especially in combination
with
the new fullscreen filtering.

- some options like 'advanced blending', 'mask bit' and 'alpha multipass' have
been removed (mmm... less options? thinking about it, i should have put that
point in
the "better" list, since it causes less user confusion, ehe).
some of them are gone because they wouldn't make any sense with the new
plugin core, and some of them because i don't think that they are needed in a
plugin which 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

--------------------------------------------------------------------------