Reply 20 of 30, by jusid
Original dosbox 0.63 with Full core produces the same error. Other cores works well.
Original dosbox 0.63 with Full core produces the same error. Other cores works well.
Well, I'm not sure how to go with this. Since the number of executed cycles fluctuates a bit the code will sometimes need to raise the number of cycles as well or it will just lower it all the time 😀
I was more thinking of posting the update to the smartscreen update patch as the previous obviously has problems with some games...
wrote:Original dosbox 0.63 with Full core produces the same error. Other cores works well.
It works in the CVS version, though. I was actually wondering why didn't jusid use a CVS version for the build.
Works very well on this K63-400. Fast way to test the results is to load up Dr. Hardware and use the video benchmark.
DosBox using just timesync the video benchmark test is in the 500's.
DosBox using timesync and the smartscreen patch it's bumped up to the 1000's. So 2x the performance in a synthetic benchmark. Now actual gameplay will probably be much less than this....I think the major benefit of this patch will be lower CPU overhead for better audio quality (and of course non-freezing systems when they load DosBox for the first time 😉 ). Would be interesting to see what the guys using DosBox on XBOX/handheld devices think of it.....
My first impression of the code was that it won't work
with e.g. scrolling-only screen updates. Found an example
in the Second Reality demo from Future Crew, the sidescroller
at the very beginning jumps at certain points.
The demo shows some other problems of the patch, too.
I added some
vga.draw.need_refresh = 1;
to the vga-port write handlers for testing, which seems
to work (but should be refined).
Also in vga_memory.cpp the memory write access handlers
(like VGA_GFX_256U_WriteHandler) got a need_refresh.
hth
Latest smartupdate and autocycles adjustment patch.
Smartupdate doesn't work correctly with any modes of this S3 driver.
http://www.winsite.com/bin/Info?4009
(A Windows 3.x S3 864 driver)
The way how Win3 256-color driver work it may produce challenges to any smart update scheme. It switches between chain4 and unchained mode all the time and actually draws pixels in both modes. I've seen it in Tseng driver and I'd expect S3 to do the same.
vasyl, you seem to know a lot about dosbox graphics system. Do you have any ideas how to improve smartscreen patch? Somehow I don't feel trapping memory writes is the most efficient way...doesn't it reduce memory write speed?
First of all, disclaimer: I haven't looked into your patch so some stuff I say may not apply or is already there.
Yours is tough question. You have to compromise in one place to get significant improvement in another. You have to trap somewhere and the earlier you trap the more you save. That means memory access. All you can do is decide the trapping unit: is that a pixel, or a scan line, or a chunk, etc. I would not worry about trapping EGA or unchained mode in VGA_GFX_256U_WriteHandler, that should not be that expensive. Trapping chained modes which use page mapping can get much worse if you attempt to get your unit below 4K. I would probably set up some flags to detect access patterns. If all accesses are EGA or unchained VGA I would use smaller units and precise tracking. If there are any chained accesses I would switch to 4K pages. Fancy implementation would have mixture of 4K and smaller chunks. Does this make sense?
a simple way would be to use 2 sets of write handlers.
one that detects wether something changes. if it changes then install the regular writehandler and set the update screen variable to true.
Not sure if it's the most efficient, but it would save a test on each write
Water flows down the stream
How to ask questions the smart way!