----------------------------------
29.12.2005 Version 2.08

- same features as the Windows version (I couldn't test the FBO rendering 
  mode on my system, though... but prolly it will work ;)


----------------------------------
12.06.2005 Version 2.07

- same features as the Windows version (well, the "fast forward key" is not
  possible in the Linux version, due to limitations of the plugin interface,
  sorry).


----------------------------------
22.07.2004 Version 2.06

- same features as the Windows version, including ZiNc support.

  For changing the custom pixel shader directory, you have to
  edit the .cfg file manually, though (no directory selection
  option in the plugin config window, sorry).

  Ah, and the new "Pause" function is mapped to the "F6" key.
  That's life ;)



----------------------------------
17.01.2004 Version 2.05 (release 2)

- a special release: the current ATI 3.7.0 drivers are causing troubles with my Mesa/XGL2
  plugins, and after some time I've found that this drivers are falling back to software
  rendering when the main app (for example epsxe or pcsx) isn't linked with the GL library.

  Well, since I cannot change each and every main emu (and it wouldn't make sense anyway
  to link all main emus to GL... that's the point of a plugin system, the plugins have to take
  care about what they are using), I cannot fix that myself.

  Luckily Nikhil has found a workaround for that issue (until the ATI driver guys are fixing it):
  simlpy do a "export LD_PRELOAD=/usr/lib/libGL.so" before running the emu... that will force
  a GL library pre-loading, and all will be fine.

  Well, nearly all: the 3.7.0 drivers also showed another problem with my XGL2 plugin, if any pixel
  shader func has been used (by turning on "tex window pixel shader" or the fullscreen shader
  effects): I've forgotten that in Linux the extension function pointer names have to be different
  than the real extension functions in the gfx driver, otherwise: crash boom bang. It made no
  differences with the 3.2.8 ATI drivers, so I didn't notice, sorry. Ok, that problem is fixed
  with this "2.05 (release 2)" plugin...

  have fun :)


----------------------------------
04.01.2004 Version 2.05

- same improvements as the Windows plugin

- New configuration tool (cfgPeteXGL2), see the readme for correct installation.

- nVidia cards may now be able to run the XGL2 plugin: try to enable the "no ATI
  render-to-texture" extension (and don't use any shaders if you have a GF4).
  I cannot say how fast it will be, with the ATI Linux drivers there is a big
  speed drop without native "texture rendering".

- Stefan Sperling gave me a patch for my X Window handling code, to avoid refresh rate
  problems in fullscreen mode. Thanx alot!


----------------------------------
26.12.2003 Version 2.04

- same improvements as the Windows plugin

- ...

- ahem, mmm, yeah:

  additional notes:

  Ok, ok, I know I've stated in the Windows OGL2.03 version notes, that 
  a Linux port of the OGL2 plugin is very unlikely, since the needed extensions
  (mainly pbuffers in combination with render-to-texture) are not available.

  But I had some free time on the first cristmas holiday, and I decided to tune
  my Linux partition. While doing that I stumbled about some ATI source code in 
  my /usr directory... fglx_gears. Well, I knew that it was an example for 
  handling pbuffers, but I never did take a closer look, since ATI stated in their
  driver's readme: "pbuffer support only for FIRE GL cards, _not_ for Radeons or
  other boards, so this demo will not work with such". 

  And "glxinfo" doesn't report the pbuffer extension with my card, so I always
  thought the readme is true. Well, but this time I tried to compile and run the 
  demo... and... it worked... amazing :)

  Ok, but what's about real 'render-to-texture'? I've never seen an example how to 
  do that with Linux, and there is no documentation about it as well. During my
  research I've found some #defines in an ATI header file, which were luckily
  similar named to the Windows 'render-to-texture' stuff, and, hey, after a lot 
  of try-and-error work ("what attributes have to be set where?") it really was 
  working :)

  Since my OGL2 plugin already was designed to compile in Linux as well, it didn't
  take very long to add the necessary functions to it... and it also worked nicely!
  
  So what do you need to run this plugin?

  - an ATI Radeon card. No nVidia support right now (well, at least I don't think
    that nVidia is supporting the "GLX_ATI_render_texture" extension, eh?)

  - prolly the latest ATI drivers (3.2.8 on my system right now)

  - well, first I wanted to name the plugin "MesaGL2", but as a matter of fact it 
    doesn't use Mesa at all (Mesa wouldn't support the required extensions anyway). The
    plugin dynamically links to the libGL library instead. So I used "XGL2" as
    plugin name.

  What are the differences compared to the Windows plugin?

  - not much... I haven't done a nice config window yet, so you have to edit
    the configuration text file manually, that's the main difference. 

    Everything else is exactly like the Windows plugin, so you will get all 
    the goodies... fullscreen filtering, pixel shader support, etc.

  The only things which are missing (not in the plugin, but in the current 3.2.8
  ATI driver): 

  - GLslang support (plugin shader effect #4 and #5). As soon as the driver will
    offer GLslang, the plugin can use it, of course.

  - It's not possible to use "very high" internal resolutions (HiresX/Y=2 in the
    config file). The ATI Windows drivers are supporting "very high Y", but funny
    enough the Linux driver doesn't... don't ask me why, use the "high" settings
    (HiresX/Y=1) instead, and wait for a new ATI driver as well, maybe they will
    fix that somewhen... or maybe it's just my system, who knows? :)

  Mmm... that's all to say about the new plugin, I think. Prolly I will do a
  special option in the plugin in the future, which will make it compatible to
  nVidia cards as well (will take twice as much vram, though... and dunno about
  the speed, we will see). 


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