Software renderer and Java6 Update10

[EgonOlsen]

Update 10 is final, so it's time to revive this thread. To make it short: It still sucks! Blitting performance goes from 100% of the speed of the former version down to 10%...it depends on the system. On one of my machines with an AthlonX2 4400+ and a GeForce 7600GT AGP, the fps drop from 56 to 35fps with this piece of crap they call a 2d-pipeline. I don't know how to handle this. Disabling this pipeline by default inside of jPCT like mentioned in this thread isn't a good idea IMHO...but leaving it on isn't one either...

[paulscode]

A compromise might be to write something in the Javadocs and/or print out a message to the Java Console when jPCT starts, stating something like "If experiencing crappy framerates, try disabling the d3d pipeline."

[fireside]

I just installed update 10 and my game seems to run alright on my computer.  I also ran dmouses game and it seemed to run just as well if not a little better.  This is bad news, though.  How come it's slower?  I thought d3d was supposed to speed up 2d blitting?  BTW, I think there's a patch from AMD concerning some types of cross platform games and Athlon 64.  I downloaded it, but I can't remember what it was now.  Not sure if it would relate to this or not.  It had to do with bad frame rates, though.

edit:  looked it up.  It's called the AMD dual core optimizer.  About the middle of this page:
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_9706,00.html

[EgonOlsen]

The dual core optimizer has nothing to do with this. It's for synchronizing the cpus' clock tick counter between the two core, so that a timing that relies on it doesn't go wrong when the scheduler shifts the application to another core (which the windows scheduler does all the time). The problem with the d3d-pipeline has something to do with an access problem to the pixel data in the frame buffer. The bug that is linked to an earlier post describes it pretty well.

[fireside]

OK.  I don't know what you should do either, really.  It seems to work just fine on my system.  I can't remember what frame rate I was getting in the FPS example, but I went back and ran it and it was adequate and seemed as fast or possibly a shade faster than it had been the last time I tried it in software.  If it doesn't actually make it faster, it might be better to just turn it off in jpct and leave an option for the author to turn it back on and do another solution if he chooses like some kind of start up option or something.  Maybe we could do some tests on our different systems with it turned off and see if it matters or not.

[Melssj5]

Well, if that can be enabled or disabled it should be able to do it in execution time, becausse it differs from machine to machine, to maybe it should do a small test with the first calls to display and cheking that it should take the desicion. Maybe?!

[EgonOlsen]

But you can't disable it once it's initialized, and you can't test without initializing it...and so you are trapped. I think i'll add an option to config and a warning and that's it.