3D Conversion of modules (Stereoscopic) WIP

oldyz

Well-known member
This account is temporarily muted.
greetings

a bout 3 weeks back , i was finally able to play the 3D re-makes of some sega genesis hits with citra (nintendo 3DS emulator)
needless to say, playing the games with a 3D projector was a real treat.

altho the OpenBOR engine currently has no native way of displaying modules as stereo projections (by duplicating & automatically re-arranging the layers)
even if it could, beatemups have to be optimized & some tricks have to be made in order for a 3D version to look right.

so first thing first,
step 1  ---  for making a 3d module you need to double the module's vertical resolution in the video.txt file
example  - video 480x480
                ColourDepth 16bit

step2  --- any title screen , videos have to be doubled, & the menus press start & option HUDs have to be modified using script so they can only be displayed in the top portion of the game window.

step 3  --- to design a 3D level, the top portion of the screen is the master, design your level boundaries based on the panel graphic, but try & keep the order or layers in the following manner:

while running the games , the layers will look like this:


step 4  ---  3d offset
  basically the fglayer that is further has to be "shifted" a bit more to the right, the closest to the left
pictures later

step 5  --- all entities have to have a "right eye version" & they must have a "display value" that will place them one layer on top of the second "fake" panel.

"setlayer {int}

    This entity will be displayed as if it were at z position {int}, regardless of it's actual position."

the left eye or master entity has to summon & bind its right eye duplicate, the binding has to be offset so the entity appears on the bottom screen.
when designing the levels, make sure that the "fake" panel layer & any layers behind it, are always on the bottom/inferior to the "Z" value of the the "right eye" entities.
in the example picture's case, "Rentities" are displayed on top of FGlayer 11

step 6 -- a "focus" or "3d depth" script has to be implemented for correct depth perception, basically, if the master entity moves closer to the screen/front fglayer, the right eye entity "shifts" to the right, the further it is from it, it "shifts" to the left.

step 7 -- some kind of mask layers or viewport or canvas limits has to be implemented, other wise some sprites will invade the space of the "second camera" layers

step 10  --- once everything is implemented, players can enjoy the module by setting OpenBOR to the following display settings:

and set their displays or projectors to 3d mode - top bottom

Limitations:

Without an effective way of masking , or cropping the sprites to certain areas, levels are limited to scroll only to left to right.
elevator stages would be difficult to do or will require a lot of work
 
Method 2:
  Stereoscopic projection of a level using split screen & offsets using a second camera

This method is best for 2D sidescrollers, basically you make Openbor display a second "canvas" or viewport,
https://www.chronocrash.com/forum/index.php?topic=511.15

the camera will still follow player one, but it will have an offset of a few pixels to the right or left

Limitations:
beatmeups will not look good using this method, since entities have no way of adjusting their "depth focus" based on their Z position
 
method 3:

the sega Gigadrive method

this is something that requires for the engine itself to be modified.
only for Damon Caskey levels of engine knowledge

from this forum: https://gbatemp.net/threads/research-m2s-3d-gigadrive-emulator.475800/

Documentary about M2;
https://youtu.be/jc5DlOkOcU4?t=2912

The Gigadrive, interestingly enough, maps some parts of the VDP to the system's RAM.
¦ The GigaDrive supports backward compatibility with MegaDrive games (Unmodified MDROMs will run normally without modification)
·Expanded VDP register for controlling expanded functionality included
·Expanded VRAM included
·Four extra background layers included
·Z-values can be set for each extra background or raster line
·Every sprite has a Z-value setting.
·VDP and Expanded VDP registers are memory-mapped and accessible
·VRAM and Expanded VRAM are memory-mapped and accessible

Memory Map:
* $c00000 r/w VDP DATA
* $c00002 r/w VDP DATA
* $c00004 r/w VDP STATUS(read)/CTRL(write)
* $c00006 r/w VDP STATUS(read)/CTRL(write)
* $c00100-$c0012f -/w VDP REGS(write only)
* $c00130-$c0015f -/w EXT VDP REGS(write only)
* $c00200-$c0024f r/w VSRAM
* $c00300-$c0030f r/w DIPSW
* $d00000-$d0ffff r/w 64KB VRAM
* $d10000-$d1ffff r/w 64KB EXT VRAM
??Detailed I/O Map spec omitted??

This is important to work with the 3D features, as the game must use the included Extended VDP registers mapped here. Below is a complete map of these registers, which can be set from the stock ROM or from the previously mentioned ARM "patches".
$C00130 = Layers from the Stock MD to not display
- 0000 0BC0
- B = Disable the Display of Plane B (regular MD), C = Disable the Display of Plane A (regular MD)

$C00132 = Layers from the Gigadrive to display
- 0000 ABCD
- A = Plane B (duplicated) , B = Plane 3, C = Plane 2, D = Plane 1

$C00134 = Base VRAM Address of Sprite Depth Array

$C00138 - $C0013E = Unused (?)

$C00140 = Not sure how it works, but it's what sets horizontal and vertical scrolling for the plane. Standard value is $08.
$C00142 = Depth of Plane 1
$C00146 = Base VRAM Address of Plane 1 (Trees in front of Sonic are on this layer in 3D S1)
- What goes here is the base VRAM address divided by $1000.

$C00148 = Same explanation as $C00140
$C0014A = Depth of Plane 2
$C0014E = Base VRAM Address of Plane 2 (Most Level elements are on this layer in 3D S1)
- Same explanation as Plane 1's register.

$C00150 = Same explanation as $C00140
$C00152 = Depth of Plane 3
$C00156 = Base VRAM Address of Plane 3 (GHZ Totems, Flowers, and Trees behind Sonic are on this layer in 3D S1)
- Same explanation as Plane 1's register.

$C00158-$C0015C = Base VRAM Address of Plane B Depth Array
- What goes in these registers is just the base VRAM address divided by $10.

$C0015E = Base VRAM Address of Plane B Duplication
- Same explanation as Plane 1's register.

Limitations:
would limit the amount of background layers if  "copied/imitated" exactly
 
updated "method 3 " post
with documentary video link
 
Back
Top Bottom