No, no errors unfortunately. The disassembly is rather interesting:
Access violation reading location 0x00000024.
692A8C57 call 692E4920
-> 692A8C5C mov ecx,dword ptr [eax+24h]
seems somebody's forgetting if(ret==NULL) 🤣
For further testing, I've compiled 4 versions of dosbox (disabled all render optimizations, so it was drawing full 70fps):
1. original texture format (GL_UNSIGNED_INT_8_8_8_8_REV)
2. GL_UNSIGNED_BYTE
3. PBO + GL_UNSIGNED_INT_8_8_8_8_REV
4. PBO + GL_UNSIGNED_BYTE
The results on my ATi are (tested on dualcore...50% = 100% of a single core)
1. 50 % cpu usage
2. 20-25 % cpu usage
3. 50 % cpu usage
4. crash
Tested with nvidia card:
1. 5-10%
2. 5-10%
3. 0-2%
4. 0-2%
The results are rather interesting. Seems my PBO code does work 😀. Also on ATi, changing the texture format from GL_UNSIGNED_INT_8_8_8_8_REV to GL_UNSIGNED_BYTE gains more than 100%! Why is GL_UNSIGNED_INT_8_8_8_8_REV used anyway? I read it's some kind of architecture independant format, but should that matter in dosbox?
Next step, I wrote a simple app, just drawing some random texture to the screen. Made the same 4 builds:
ATi:
1. 42fps
2. 222fps
3. 46fps
4. crash
nVidia:
1. 293fps
2. 274fps
3. 1122fps
4. 1183fps
Again, using GL_UNSIGNED_BYTE works 5(!) times faster on ATi. Again, using PBO seem to help a lot, unfortunately the most interesing thing crashes with ATi. I hope this will be resolved in the next driver version...
Attached: my test app 😀