Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - 3D Tween Demo [GG, SMS and SMS+3D Glasses]

Reply to topic
Author Message
  • Joined: 12 Apr 2005
  • Posts: 377
  • Location: London, United Kingdom
Reply with quote
3D Tween Demo [GG, SMS and SMS+3D Glasses]
Post Posted: Wed Jan 24, 2007 10:49 am
I know Maxim's already seen this, and I've had it lurking on my hard disk for a while, so I thought I'd release it as it is.

Download (source and three binaries in the zip).

I haven't been able to test the SMS versions on a real SMS, only a Game Gear in SMS mode. I had intended on writing a multi-part demo, but only it ended up being a two-parter (and the other part was pretty dire).

Screenshot as a stereo pair.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13431
  • Location: London
Reply with quote
Post Posted: Wed Jan 24, 2007 12:30 pm
It looks like you didn't do anything to deal with the sprite limit. A quick and dirty technique that at least gets you 16 working sprites per scanline is to reverse the tile indices every other frame.

You could maybe speed things up a bit by using an OUTI block on the bit where you dump sprites to VRAM, and of course skipping the third 64 bytes would save time; but then, it seems VBlank time isn't an issue in this case.

You might be interested in the CORDIC algorithm for calculating the SIN/COS tables if you would rather avoid precomputing things, although it'll only really make a difference to the more hardcore among us... I'm sure, with your TI background, you have used well-chosen mul/div routines, probably more so than the rest of us here :)
sega_tween_3d_stereo_pair.png (5.85 KB)
Sega Tween stereo pair screenshot
sega_tween_3d_stereo_pair.png
Sega Tween.zip (43.91 KB)
Sega Tween - local mirror

  View user's profile Send private message Visit poster's website
  • Joined: 12 Apr 2005
  • Posts: 377
  • Location: London, United Kingdom
Reply with quote
Post Posted: Wed Jan 24, 2007 1:10 pm
Maxim wrote
It looks like you didn't do anything to deal with the sprite limit. A quick and dirty technique that at least gets you 16 working sprites per scanline is to reverse the tile indices every other frame.
The problem with that method is the depth-sorting; the sprites need to be in front->back order. It looks very odd when you have small blobs sitting in front of big blobs.

Quote
You could maybe speed things up a bit by using an OUTI block on the bit where you dump sprites to VRAM, and of course skipping the third 64 bytes would save time; but then, it seems VBlank time isn't an issue in this case.
I use a rather idiotic arrangement of memory, clumping all of the final point data into four byte chunks, which isn't very VRAM-friendly.

The code is really quite horrible in places (the SMS graphics loader just truncates the palette, so contains redundant palette data; nothing is compressed; excessive use of index registers; so on and so forth). I'll admit that freely!

There are probably things that could be done to make it a lot faster, but as my first venture into 3D on Z80 hardware I was happy enough to get it that fast at all.

It's a copy of a BBC Micro demo by Orlando (on the 3D Pool disk), which ran nicely on a 2 MHz 6502.

Quote
You might be interested in the CORDIC algorithm for calculating the SIN/COS tables if you would rather avoid precomputing things, although it'll only really make a difference to the more hardcore among us... I'm sure, with your TI background, you have used well-chosen mul/div routines, probably more so than the rest of us here :)
That's interesting and potentially very useful - thanks for the link!
The mul/div routines are from Z80 bits with some extra code added to handle signed operands.
  View user's profile Send private message Visit poster's website
  • Joined: 04 Nov 2004
  • Posts: 270
  • Location: Deutschland
Reply with quote
Post Posted: Wed Jan 24, 2007 1:22 pm
Looks great :)

Has anyone tried it on a SMS1, which can only display 4 sprites zoomed per scanline?
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13431
  • Location: London
Reply with quote
Post Posted: Wed Jan 24, 2007 2:32 pm
benryves wrote
The problem with that method is the depth-sorting; the sprites need to be in front->back order. It looks very odd when you have small blobs sitting in front of big blobs.

I can imagine; that turns it into the rather more intractable problem of reversing the sprite indices only for maximum-sized sets of non-overlapping sprites.

An alternative would be to render those same 64 sprites front-to-back and whenever the sprite overflow bit was set, start alternately rendering only the even or odd sprites in subsequent frames. Then you'd be in flicker hell that would be the same even on an emulator with no sprite limit... and you'd still lose the z-ordering in a lot of cases, and it'd be tough to determine when it was safe to go back to full rendering. Ah well.
  View user's profile Send private message Visit poster's website
  • Joined: 12 Apr 2005
  • Posts: 377
  • Location: London, United Kingdom
Reply with quote
Post Posted: Thu Jan 25, 2007 11:02 am
Martin wrote
Looks great :)

Has anyone tried it on a SMS1, which can only display 4 sprites zoomed per scanline?
Thanks... and whoops, I completely forgot about that. Good thing it's the one that supports the 3D glasses too.
  View user's profile Send private message Visit poster's website
  • Joined: 12 Apr 2005
  • Posts: 377
  • Location: London, United Kingdom
Reply with quote
Post Posted: Wed Jan 31, 2007 11:20 am
I added a four zoomed sprite per scanline limit for my SMS1 emulation (the VDP emulation is slightly different between SMS1 and SMS2 modes in other areas as well) to see what it looks like. Not that great, assuming that I'm emulating the behaviour correctly.

It doesn't look too awful in motion as the blobs in the foreground aren't affected.
  View user's profile Send private message Visit poster's website
  • Joined: 26 Dec 2004
  • Posts: 374
  • Location: Japan
Reply with quote
Post Posted: Fri Feb 02, 2007 6:55 am
I love 8-bit demos that use a bit of math (more than just the standard sinus-scroller...) I tried it out on my Japanese SMS, and MegaDrive with SMS converter. Here are some pics:


Click on the pics to see them enlarged.

Unfortunately, the sprite doublesize limit does make it look kinda bad on a real SMS. Further, it appears that in the top 1/4 and bottom 1/4 of the screen, sprites are never doubled horizontally. I've marked this on the 2nd to last pic. The last pic is from the MD, which doesn't have doublesize capabilities. Since there is no glitching except for sprite limitations, I actually prefer the look of regular-sized sprites.

And unfortunately, your demo doesn't work with the 3-D glasses attached to my Master System. The LCD filters are not being alternated. Be sure to check which port you are writing the alternating bits to.. I made a post here describing a quirk(?) of the Japanese SMS, (maybe some other models too?).
  View user's profile Send private message Visit poster's website
  • Joined: 12 Apr 2005
  • Posts: 377
  • Location: London, United Kingdom
Reply with quote
Post Posted: Fri Feb 02, 2007 11:14 am
ccovell wrote
I love 8-bit demos that use a bit of math (more than just the standard sinus-scroller...) I tried it out on my Japanese SMS, and MegaDrive with SMS converter. Here are some pics:

Thank you very much for testing! :-)

The source is in the Source directory, so if you want to fiddle around with it you can look in there. The easiest way to assemble is to drop Brass into the same directory, and run this on the command-line:

set extension=sms
set variation=3d
brass "sega tween.asm" tween.sms


Quote
Unfortunately, the sprite doublesize limit does make it look kinda bad on a real SMS. Further, it appears that in the top 1/4 and bottom 1/4 of the screen, sprites are never doubled horizontally. I've marked this on the 2nd to last pic. The last pic is from the MD, which doesn't have doublesize capabilities. Since there is no glitching except for sprite limitations, I actually prefer the look of regular-sized sprites.

That's strange behaviour indeed, and something I wasn't aware of. In any case, line 303 can be changed:

   ld a,Video.Reg.Mode2.Enable | Video.Reg.Mode2.VBlankInterrupt ; | Video.Reg.Mode2.ZoomSprites

Quote
And unfortunately, your demo doesn't work with the 3-D glasses attached to my Master System. The LCD filters are not being alternated. Be sure to check which port you are writing the alternating bits to.. I made a post here describing a quirk(?) of the Japanese SMS, (maybe some other models too?).

Line 775, $FFF8. Again, something I wasn't aware of; I'd assumed it was $FFF8 and the others were mirrors.

I've attached a reassembled version without the zoomed sprites that writes to $FFFB.

I can't help verify some of the glitches on hardware against different models, but would like to know more (if possible!) for emulation!
Tween.zip (4.6 KB)
Modified 3D Tween

  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!