| commit | a5ceb7d045c65fea450a0c9b4e9ed2c9be9f340d | |
| author | Hominem te esse <hominem.te.esse@googlemail.com> | |
| Sat, 11 Feb 2012 14:33:02 +0000 (11 15:33 +0100) | ||
| committer | Hominem te esse <hominem.te.esse@googlemail.com> | |
| Sat, 11 Feb 2012 14:33:02 +0000 (11 15:33 +0100) | ||
| tree | 884f76786cb3e239c0f381003537ca1cfdaab6bb | treesnapshot (tar.gz zip) |
| parent | d2727768eb0de8b5eceaee289d082d1889927e70 | commitdiff |
NOTE: Concerning my comment in R606, I'm sorry Volca, the code wasn't "dangerous" and didn't write memory out of bounds (thanks to the check < MAX_GS_MODE)
However, after reading carefully again, I still consider some part of the code "buggy", it wouldn't support any GS_MODE > 16, and really, I don't see the point of using the intermediate rm_gsmode_table.
Don't hesitate to clarify this if you feel I did sh*t ;)
-------------------------
* Fixed some bugs concerning vmode/vsync handling that I introduced the revision before ;)
* Process the vmode/vsync as normal settings, saved into the conf_opl.cfg (see forum extract below)
I now (at least !) understand why a new config file was introduced for supporting vmode. I first thought it was to be able to revert from an invalid mode set/tried by deleting the file. But as in such case you would not be able to save the settings in case of garbaged screen, so that change would not be final.
In fact it was for the OPL "startup timeline". As before we loaded the configuration files only after initializing everything else. The problem is that the component rendering the screen (renderman) is started first, and it needs the vmode settings. So the file was added to hold only this settings and load at start before the others.
The problem with that ... is in such case this file is not managed through the "alternate device mode".
We have the choice now:
1. having a bug with the loading/saving of vmode (someone who would like to use the alternate device mode can't load/save vmode at all), BUT having a nice startup
2. put the vmode into the main config file, supporting the alternate device mode fully BUT having the screen flickering at startup (due to the renderman being first inited, then the setting file loaded, then the renderman changing the resolution to what the user saved)
As a side note, the flickering in 2, would not be experienced by 99% of the user who are in mode=AUTO, only for those selecting another mode as AUTO.
However, after reading carefully again, I still consider some part of the code "buggy", it wouldn't support any GS_MODE > 16, and really, I don't see the point of using the intermediate rm_gsmode_table.
Don't hesitate to clarify this if you feel I did sh*t ;)
-------------------------
* Fixed some bugs concerning vmode/vsync handling that I introduced the revision before ;)
* Process the vmode/vsync as normal settings, saved into the conf_opl.cfg (see forum extract below)
I now (at least !) understand why a new config file was introduced for supporting vmode. I first thought it was to be able to revert from an invalid mode set/tried by deleting the file. But as in such case you would not be able to save the settings in case of garbaged screen, so that change would not be final.
In fact it was for the OPL "startup timeline". As before we loaded the configuration files only after initializing everything else. The problem is that the component rendering the screen (renderman) is started first, and it needs the vmode settings. So the file was added to hold only this settings and load at start before the others.
The problem with that ... is in such case this file is not managed through the "alternate device mode".
We have the choice now:
1. having a bug with the loading/saving of vmode (someone who would like to use the alternate device mode can't load/save vmode at all), BUT having a nice startup
2. put the vmode into the main config file, supporting the alternate device mode fully BUT having the screen flickering at startup (due to the renderman being first inited, then the setting file loaded, then the renderman changing the resolution to what the user saved)
As a side note, the flickering in 2, would not be experienced by 99% of the user who are in mode=AUTO, only for those selecting another mode as AUTO.