viking272 wrote:I wonder if anyone can test with SuperVidel please? As far as I know there isn't any specific SV code in the build. [yet]
evil wrote:I thought there was a bug with strafe-mode being stuck, but it was just me not realising that you had to use the mouse!
dml wrote:The SV guys did a great job with compatibility!
dml wrote:I should be able to replace the floor texturing with a CPU-friendly version for 060 and then it should work safely plotting to a fastram framebuffer and copying it over as you suggest. When this happens I'll raise the FPS cap back to 25 (or 35?) to see what happens.
evil wrote:Yeah, I think their approach is more sane than trying to stick a Radeon to a PCI-bus like some other solution. It's a lot of more work to do of course, but the end result is worth it. If one's after quick Open GL on the Atari, then maybe not, but for the rest, I think SuperVidel got it right.
evil wrote:35 Hz game logic sounds good for a 060, I don't think it has a problem traversing that junk-code But doing different code-paths for rendering on 060 sounds like a big job, perhaps best spend the time to get it ready for 030 machines before poking into that stuff, after all, BadMooD is really a great showcase for standard Falcon 030.
evil wrote:I just ran it on SuperVidel. Almost works. The splitscreen effect for the status panel doesn't work. I'm not sure if SuperVidel allows HBL/Timer-B HBL at all, or if it's due to that I havn't done the solder install (which uses sync signals from the motherboard).
What exactly happens in your splitscreen code?
Does the 160x200 option use "wide pixels in hardware"? (awesome in such case, because that means the SuperVidel is actually compatible with this, and I don't think any of us tested that before!).
shoggoth wrote:Does the 160x200 option use "wide pixels in hardware"? (awesome in such case, because that means the SuperVidel is actually compatible with this, and I don't think any of us tested that before!).
shoggoth wrote:Sounds to me like maybe the SuperVidel doesn't allow mid-screen changes to the screen address? Or at least not in HC?
dml wrote:If that's the case it might be a good idea for BM to detect SV and use the same workaround as is used for Hatari - no raster involved.
I think the rest should be ok though.
shoggoth wrote:Basically you check if the "SupV"-cookie is there. If it is, you're on SuperVidel. Ignore the value of the cookie.
evil wrote:4. Render frame in TT-RAM
5. move16 from TT-RAM to SV-RAM
Plotting pixels direct to SV-RAM is not a good idea, there's a big penalty for many small writes.
At least when doing 8-bit/pixel tests, this method was much faster than rendering directly to SV-RAM.
mikro wrote:This is not the case anymore. Slight change to the PMMU tree results in super fast byte access which happens to be the fastest, too PeP is working on new version of his drivers.
Users browsing this forum: No registered users and 1 guest