Solved Can OpenBOR do a vertical wall with 3D perspective?

[ipkevin]

Check this out (6:40 mark):

Notice that the players can go through the door in the middle of the stage and it's drawn with proper perspective. Even the angle of the bottom edge of the door is perfectly aligned with the ground affine layer at every step.

Is there a way to do this in OpenBOR?

I was thinking of a bunch of workarounds to sort of achieve that, but nothing works like the above. Sprite stacking (works but very primitive looking - you cannot have nice door artwork like above), scrolling-stretching (works but isn't perfectly aligned with the ground and never will be), and finally rotating a ground affine layer 90degrees and adjusting begin/endsize, but the problem is that affine layers repeat infinitely so you can't have a nice door edge where it meets the ground.

Any ideas?

 

[DCurrent]

Let me just stop you before you finish any question that begins with "Can..." or "Is it possible...". It's always yes. Always. First, you can create vertical layers in OpenBOR. This is yet again where screens come into play. That said, vertical layers are not needed at all to achieve the effect you want.

There are several techniques you can use to create perspective walls in sprite based engines. The simplest, by far the most common, and what Kaiser Knuckle does, is to place two or more sprite objects to build your wall. One drawn in front of the play field and the other behind. Then you have it play different animation frames based on X position. The technique is explained in detail here, although it's simpler in OpenBOR since you don't have the hardware constraints they had to deal with.

 

[oldyz]

@ipkevin
try & get a hold of this module:

it contains script that enables animation frames based on scrolling position that your walls might need, allowing you to make a similar trick to wat the toy story game does, @DCurrent also has mentioned that using screens is another option, but i was never able to figure it out on my own.

things might get a bit trickier if you want these type of objects to feature the effect & for them to be destructible at the same time OR for these objects to feature animations, the rocket viper scripts seem to limit the 3d walls/entities/objects effect to "textures" that can only feature one animation at a time.

on the other hand, Damon's use of screens should enable you to feature doors or animated walls/lcd tv screens that animate or light up.
(horror example: walls that bleed)

 

[ipkevin]

@DCurrent and @oldyz -- Thank you for the info and links! That method makes a lot of sense. I guess my only 'issue' with it is that it seems pretty manual in that you have to draw every frame in advance (though it's not that difficult since you could do the transform in photoshop or any paint app easily). I was hoping there was a way where you draw one image and can handle the transformation thru code. Still this is a good technique and I'm glad to have learned it. Thanks again!

BTW, @oldyz, love your legendary Night Slashers mod!

 

[oldyz]

BTW, @oldyz, love your legendary Night Slashers mod!

thanks but its NOt mine, the last version was a lot of work from a bunch of sources & it still is more than 90% bonusJZ & Data East

been working on some new monsters & original cinema displays & stuff but its getting to the point where it exceedes my skill set,
next update might be rough & ugly and more like a draft or preview product, since i can't seem to get any satisfactory results...

 

[Kratus]

@DCurrent and @oldyz -- Thank you for the info and links! That method makes a lot of sense. I guess my only 'issue' with it is that it seems pretty manual in that you have to draw every frame in advance (though it's not that difficult since you could do the transform in photoshop or any paint app easily). I was hoping there was a way where you draw one image and can handle the transformation thru code. Still this is a good technique and I'm glad to have learned it. Thanks again!

BTW, @oldyz, love your legendary Night Slashers mod!

@ipkevin

Maybe it's doable using one or two images and a script, you can use drawmethod functions like "scale" or "shiftx" to to lean or rescale a single image. You can use the openborvariant "xpos" as reference for both. I recorded two examples below, the Yamato uses drawmethod "scale" and the disco lights are using "shiftx" in a single image.

Below are the instructions from the manual.

setdrawmethod(entity, int flag, int scalex, int scaley, int flipx, int flipy, int shiftx, int alpha, int colourmap, int fillcolour, int rotate, int rotateflip, int transparencybg)

~Set drawmethod for an entity or define a global drawmethod for other script functions.
~entity must be a valid entity handle or an empty value.
~All other parameters are optional.
~flag defines whether the drawmethod is active, when set to 0, the drawmethod will not take effect.
~scalex defines how the sprite will be stretch in x direction: sizex = original_sizex * scalex / 256
~scaley defines how the sprite will be stretch in y direction: sizey = original_sizey * scaley / 256
~flipx defines whether the sprite will be flipped left/right. 0 means don't flip and 1 means flip.
~flipy defines whether the sprite will be flipped top/bottom. 0 means don't flip and 1 means flip.
~shiftx defines how the sprite leans, like lightx in gfxshadow feature, in most situations you don't need this.
~alpha defines which alpha blending effect will be used. 0 means no alpha effect. -1 means the entity(if given) will use its own alpha value.
~colourmap(entity only) defines which colourmap will be used. 0 means no colourmap. -1 means the entity(if given) will use its current colourmap.
~fillcolour is the colour used by the entire sprite. 0 means don't fill the sprites.
~rotate is the rotate angle(clockwise), the range is from 0 to 359.
~rotateflip(entity only) means whether the entity will flip its rotate direction if the facing is changed.
~transparencybg(screen only) means whether the screen will use transparency colou

 

[oldyz]

@ipkevin

Maybe it's doable using one or two images and a script, you can use drawmethod functions like "scale" or "shiftx" to to lean or rescale a single image. You can use the openborvariant "xpos" as reference for both. I recorded two examples below, the Yamato uses drawmethod "scale" and the disco lights are using "shiftx" in a single image.

View attachment 1275

Below are the instructions from the manual.

@Kratus
I made a rough experiment using drawmethod, & a version of my "entity attacks the closer you get" method, where the wall object drawmethod changes with the animation as a multi-line attack & proximity animation script pre-written using excel.

a better version of this is to combine rocket viper's version of the script with drawmethod distortions of the sprite or entity trough a modification of @bWWd 's script for real-time entity/sprite zoom (but instead of zooming it distorts the entity based on scroll position rather than Z depth), like in your examples, to create vertical planes & it also might allow for "animated walls" without resorting to screens....

 

[oldyz]

here is the zoom code from Bwwd's thread,

void main()
{
void self = getlocalvar("self");
int z = getentityproperty(self, "z");
void sp = getentityproperty(self,"speed");
int ypos = openborvariant("ypos");
int zoom = 500 + (z - 800 ) ;
int zspeed = 0.5 + (z / 250-1600/500/2/2 ) ;
drawstring(110,380,0,"SPEED_-_" + sp/100000);
drawstring(110,410,0,"ZOOM_-_" + zoom/100000);
if(zoom < 0) {zoom = 0;}
setdrawmethod(self, 1, zoom , zoom , 0, 0, 0, -1);
changeentityproperty(self, "speed", zspeed );
}

the video link is down, but basically as the entity moves closer to us, the entity grows, entity goes far away, entity shrinks.
instead, we make scroll position the "driver" & instead of zooming, a distortion or flipping effect is applied, & if im not mistaken, animation can be featured (the video had the character doing walking animation & zooming in & out simultaneously

 

[DCurrent]

I was hoping there was a way where you draw one image and can handle the transformation thru code.

You can - but by the time you work the math and get it all set up, you could have already used the sprite frame technique and moved on. I'm the biggest script advocate in this community, but even I have to draw a line at adding complexity for its own sake.

DC

 

[ipkevin]

@Kratus @oldyz - Thanks for testing it out and the examples! So I thought it through and I'm certain it's possible just applying changedrawmethod(NULL, "scalex") to a single image. I mentioned before I tried scrolling and stretching but it would never be perfectly in sync with the affine layer. That's wrong. After thinking about how they could draw the frames in the Toy Story example, I realised you could get a perfect match to the ground with a single image. Just take an image that already has angle in it, adjust its starting position so that it matches the ground affine layer's angle at that position, then adjust horizontal scrolling speed and xstretch and you will eventually get a perfect match to the affine layer from any angle. It's inevitable. It won't let you do what's being done in rocket viper obviously (you need prerendered frames for that), but the kaiser knuckle example is totally doable.

The cons of the scalex (stretch) approach is that your image will get horribly large pixels after not a lot of stretch. In contrast, the toy story animation frames solution does not have that issue, but it's much more time consuming to implement.

 

[DCurrent]

If you are bound and determined to do that @ipkevin, it's easy enough to solve the overstretch issue. All you need is a sanity check on X Pos or the stretch calculation. Either way, you just stop the stretching at a finite point. Also, you still need two sprites, not one. No amount of code can make an object draw in two Z axis positions at once, so you need a second wall sprite for the portion of wall that passes in front of the play field objects.

DC

 

[ipkevin]

@DCurrent, yup the front wall sprite is necessary for a kaiser knuckle situation, good point. Agreed on limiting the stretch, though depending on the 'depth' of the wall or door, it needs to keep stretching for quite a bit before it can stop, else it will stop transforming before the ground does, ie, it'll fall out of sync. (My use case includes walls that may extend deep into the background, not just doors like kaiser knuckle)