SuperVidel with BadMooD?

[viking272]

Hi all,

An early release of BadMooD (Doom game) for the 68060 CPU was released last night. General info is in the bmalph02.zip file.
It's in the downloads area here: http://devilsdoorbell.com

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]
There are minor bugs (like a random freezing of the screen) and it's limited currently to 12 FPS, but '060 should push this much higher in a later release.

There is another topic for the development of this project, so any feedback would be nice:
viewtopic.php?f=68&t=24561&start=1450

Cheers

[evil]

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]

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).


However, optimizing for SuperVidel is easy;

1. Reserve screen memory with Mxalloc() as usual, at least 16 byte boundary
2. or.l #$a0000000,d0 (to screen address, now it ends up in SuperVidel ram)
3. Create chunky (or offscreen..) buffer in TT-RAM, also aligned by 16 bytes boundary
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.

Oh, I filmed BadMooD on SuperVidel with my phone. 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! So the movement in the video is pretty silly. But when thinking of it, not sure how I should have controlled it with mouse+keyboard and still hold the phone for filming. I need a third arm.

http://www.youtube.com/watch?v=Go1ntERAFxQ

[dml]

Evil,

The SV guys did a great job with compatibility!

In fact I think it only manages to run here because it is slowed by STRam bus while plotting floor pixels. Otherwise 060 would outrace DSP and it would die very quickly.

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.

[dml]

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!

The 'default' config uses arrow keys for move and turn, with ALT (I think) to strafe and CTRL to shoot. Some other keys are probably bound for strafe left/right but they aren't primary keys.

If you load the 'pro' config it expects mouse under the right hand, and arrow keys under the left hand (strafe+move).... well left handed works also, of course

[viking272]

I just ran it on SuperVidel.
http://www.youtube.com/watch?v=Go1ntERAFxQ

Excellent stuff, thanks evil!
It looks great on your setup.
I'm sure with the power of SV and an '060, 70 fps would be achievable...

[evil]

The SV guys did a great job with compatibility!

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.

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.

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.

[dml]

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.

While I do like OpenGL, it does remove a lot of the fun from that side of things

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.

I definitely won't spend time doing 060 optimized code - at most making it understand different kinds of RAM (e.g. SV RAM). In fact BM had 'fastram buffering' even in the old versions - because I did the same optimization for AB40 (build the framebuffer in fastram, then copy with move16). Of course the importance of this is now much greater on SV but it means I probably don't have to do a lot of work

Note: It needs a CPU-based floor texturing option anyway, to make it work safely with other accelerators so I don't count it as 060 code, even if it will help there much more than it will for other kinds of upgrade.

[shoggoth]

dml:

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]

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).

It does. Basically the VIDEL is still generating these interrupts, so if you did the soldered install, these interrupts should occur at the right times / locations. The scenario will be slightly funny in SV-specific resolutions however, because the VIDEL may still be generating the VBL and HBL:s, but they'll have no relation to the SV screen output. There's simply nothing to do about that unless people want to solder 500000 wires to their motherboard and replace the on-board chipset.

[dml]

Hi,

dml:
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!).

The 'splitscreen' timerb sets the video address counters - moves physbase for the next line onwards until the next VBL. It also resets line doubling on RGB, if it was enabled on the VBL. So you can have low-res play area and high res status bar on RGB.

I did try to 'splitscreen' the horizontal 'fat pixel' state at one point on VGA, but found that doing so required other register changes which resulted in the VGA wanting to re-sync on the next line, and my monitor went dark with much whining. It might be worth trying again with more time to experiment but I gave up pretty quickly.

So the current version touches only the display address and the double line flag.

Hardware fat pixels on VGA will only work in fullscreen mode with no status bar. There's a bag of logic in the window resize code to figure out which hardware modes are compatible with statusbar/monitor/window combinations and which need filled in with software doubling...

Note: The raster does not attempt any kind of hardsync with VIDEL (!), but does implement a 'softer' sync with MFP timerb data, inserting 1 scan of padding time before displaying data. If pixels are displayed on the transition line they corrupt - but at least the status bar doesn't jump when you move the mouse etc. I haven't quite finished tidying that side of things - there should be an empty line immediately above the SB and there isn't.

[dml]

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!).

I just noticed I probably didn't answer your question

On VGA only, and in fullscreen only - yes it uses wide pixels in hardware. In all other configurations it is stuck with software fat pixels.

On RGB it can use line doubling at any time, including with status bar, windowed/fullscreen and statusbar remains un-doubled.

[EDIT]

Just a pity line doubling looks more ugly than VGA's fat pixel mode

[shoggoth]

Sounds to me like maybe the SuperVidel doesn't allow mid-screen changes to the screen address? Or at least not in HC?

Tobbe, Henke?

[instream]

Sounds to me like maybe the SuperVidel doesn't allow mid-screen changes to the screen address? Or at least not in HC?

Tobbe, Henke?

Nope, it only starts to use the new value of the screen address after Vsync.
And hardware double or even quad pixels works. I'm pretty sure that I have tested it at some point.

[dml]

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.

[dml]

BTW Hatari does something different with physbase updates too - it seems to pick up the address on a new frame just *before* the VBL interrupt, so attempting to set the register in the VBL routine is already too late. On real HW it's not observed until the display begins, or some time deeper into VBL period so you can set physbase on the interrupt and it gets picked up.

Not exactly related - but display address stuff seems to be a bit of a compatibility fuzzy area on Falcon

(TBH the Hatari issue seems to be more of a hazard than splitscreen stuff - likely to be more common for a start and less obvious what's wrong)

[shoggoth]

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.

Basically you check if the "SupV"-cookie is there. If it is, you're on SuperVidel. Ignore the value of the cookie.

[dml]

Basically you check if the "SupV"-cookie is there. If it is, you're on SuperVidel. Ignore the value of the cookie.

thx. will do Can even blit the SB properly now since it's going to be fast enough

[instream]

IIRC the new video address is picked up just before the first line to display on the new screen redraw. So you have a few lines of time margin after the Vsync.

[mikro]

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.

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.

[shoggoth]

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.

New driver is sort of ready, at least for beta testing. This feature is highly experimental and I don't think it should be released into the wild before some degree of testing... remember to always wear goggles + helmet.