SuperVidel with BadMooD?

News, Support and Development discussions relating to SuperVidel.

Moderators: Mug UK, moondog/.tSCc., [ProToS], lp, instream, Moderator Team, Nature

User avatar
viking272
Captain Atari
Captain Atari
Posts: 242
Joined: Mon Oct 13, 2008 12:50 pm
Location: west of London, UK

SuperVidel with BadMooD?

Postby viking272 » Sat Jan 25, 2014 12:04 am

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
Last edited by viking272 on Sat Jan 25, 2014 9:45 pm, edited 1 time in total.

evil
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 139
Joined: Sun Nov 12, 2006 8:03 pm

Re: SuperVidel with BadMooD?

Postby evil » Sat Jan 25, 2014 7:13 pm

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]


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

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: SuperVidel with BadMooD?

Postby dml » Sat Jan 25, 2014 8:02 pm

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.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: SuperVidel with BadMooD?

Postby dml » Sat Jan 25, 2014 8:04 pm

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!


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 :)
Last edited by dml on Sat Jan 25, 2014 10:03 pm, edited 1 time in total.

User avatar
viking272
Captain Atari
Captain Atari
Posts: 242
Joined: Mon Oct 13, 2008 12:50 pm
Location: west of London, UK

Re: SuperVidel with BadMooD?

Postby viking272 » Sat Jan 25, 2014 9:47 pm

evil wrote: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
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 139
Joined: Sun Nov 12, 2006 8:03 pm

Re: SuperVidel with BadMooD?

Postby evil » Sat Jan 25, 2014 10:28 pm

dml wrote: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.


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.


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.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: SuperVidel with BadMooD?

Postby dml » Sun Jan 26, 2014 11:01 am

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.


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

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.


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.

User avatar
shoggoth
Nature
Nature
Posts: 854
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: SuperVidel with BadMooD?

Postby shoggoth » Wed Jan 29, 2014 10:03 am

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!).
Ain't no space like PeP-space.

User avatar
shoggoth
Nature
Nature
Posts: 854
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: SuperVidel with BadMooD?

Postby shoggoth » Wed Jan 29, 2014 10:06 am

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


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.
Ain't no space like PeP-space.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: SuperVidel with BadMooD?

Postby dml » Wed Jan 29, 2014 10:14 am

Hi,

shoggoth wrote: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.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: SuperVidel with BadMooD?

Postby dml » Wed Jan 29, 2014 10:16 am

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


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

User avatar
shoggoth
Nature
Nature
Posts: 854
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: SuperVidel with BadMooD?

Postby shoggoth » Wed Jan 29, 2014 10:48 am

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?
Ain't no space like PeP-space.

instream
Nature
Nature
Posts: 165
Joined: Mon Aug 03, 2009 9:08 am
Location: Göteborg, Sweden
Contact:

Re: SuperVidel with BadMooD?

Postby instream » Thu Jan 30, 2014 10:16 am

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?

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. :wink:

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: SuperVidel with BadMooD?

Postby dml » Thu Jan 30, 2014 10:40 am

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.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: SuperVidel with BadMooD?

Postby dml » Thu Jan 30, 2014 10:47 am

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)
Last edited by dml on Thu Jan 30, 2014 10:49 am, edited 1 time in total.

User avatar
shoggoth
Nature
Nature
Posts: 854
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: SuperVidel with BadMooD?

Postby shoggoth » Thu Jan 30, 2014 10:48 am

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.


Basically you check if the "SupV"-cookie is there. If it is, you're on SuperVidel. Ignore the value of the cookie.
Ain't no space like PeP-space.

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3472
Joined: Sat Jun 30, 2012 9:33 am

Re: SuperVidel with BadMooD?

Postby dml » Thu Jan 30, 2014 10:53 am

shoggoth wrote: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
Nature
Nature
Posts: 165
Joined: Mon Aug 03, 2009 9:08 am
Location: Göteborg, Sweden
Contact:

Re: SuperVidel with BadMooD?

Postby instream » Thu Jan 30, 2014 10:55 am

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
Atari God
Atari God
Posts: 1303
Joined: Sat Sep 10, 2005 11:11 am
Location: Brisbane, Queensland, Australia
Contact:

Re: SuperVidel with BadMooD?

Postby mikro » Sun Feb 16, 2014 9:24 am

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.

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.

User avatar
shoggoth
Nature
Nature
Posts: 854
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: SuperVidel with BadMooD?

Postby shoggoth » Tue Feb 18, 2014 8:35 pm

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.


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.
Ain't no space like PeP-space.


Social Media

     

Return to “SuperVidel”

Who is online

Users browsing this forum: No registered users and 1 guest