directions, polarity reverse?

[Wombat2112]

I remember either a thread or reading in the manual something about this topic but I don't recall. I have my idle and walk animation just fine was about to add first basic Ani-attack. Most games move left to right or east to west....many of my player sprites are facing opposite direction right or west in attack animations ...however with  the mod I chose already the player animation already appears to reverse react when enemy entities end up moving to the opposite side they were spawned from....  so it may be something already coded that way but I was wondering would I have to flip each frame and create an opposite direction animation pic for every animated action the player takes? I know how to flip but it seemed like there
was an easier way if and if I were starting from the ground up what the process is to make the player reverse its course . In other words my idle and walk animation moves left to right as do most 2D games normally  but I didn't know if player was going to suddenly be facing backwards stabbing opposite his enemies lol

 

[DCurrent]

I don't know where you read that, but you certainly didn't find it here or the manual. The engine handles sprite mirroring. You just worry about the entity facing.

Over all I think you need to work on abstract thinking skills before you go any further. Just from your questions it seems you are taking on screen visuals too literally.

DC

 

[oldyz]

Wombat2112

It takes some getting used to, i have experimented with Goldeneye, Doom , Quake, a little bit of Doom3 & MUGEN, after dealing with those, OpenBor is a bit odd for some of the stuff that you may want to do...

the first thing i had to learn is not to treat it like a polygon engine or think of things displayed as flat triangles with a flat cardboard cut-out type of deal, at its most basic remember that we are working with Streets of rage & some of its limitations.
to give you an idea, original Doom is not really a 3D game, it is a 2D engine pulling a fancy trick, so even that game has programming that may seem odd for a person who is used to the Goldeneye editor or modern 3d engines

the second thing is, i think its safe to say that are all Learning & finding new things to do with the engine & character making is complex....

but don't get frustrated & keep asking if you need to, sometimes the manual has undocumented things or values & also the better things that the engine can do will need scripting & that is something that has lots of uses

 

[oldyz]

Here is something that illustrates how i feel when it comes to programming with openbor at my WORST times...



firs example, - but turn it down 80 to 90%




https://www.youtube.com/watch?v=O-WjWf61KdI

second example, but dial it down 99%




https://www.youtube.com/watch?v=hB6eY73sLV0

 

[oldyz]

you too,

character directions are tricky for me too, but once again ill direct you to NS X or BORLab, the sprites that make up Chrisotper & most of the zombies look completely opposite to how they display in the game,,

sorry the stuff in red is wrong, but its possible to make the mistake of editing your sprites int he wrong direction

this goes in the leve0X.txt file, it works for enemies  don't know if it works for the palyers

spawn stower0001
flip 1
item brl
coords 240 245
at 0

so for the player you might try...

notime 1
settime 0
background data/bgs/library/p1
panel data/bgs/library/a1
frontpanel      data/bgs/library/p1
fglayer data/bgs/lv4/swc5a 4 1 0 0 0 99999999 0 2 1 1 2
order a
direction both
spawn1 100 45 0
flip 1
spawn2 80 70 0
cameratype 1

i heave seen some enmies that where made w their sprites all reversed, but this simple switch in the .txt file can flip them

 

[DCurrent]

...

Wombat2112,

First please stop quoting full posts. We have a rule against that and for good reason. Scrub quotes or or quote only what you are responding to.

I don't know what you mean by "abstract thinking" but I think you are way misunderstanding what my point was. No I remember a reference to screen mirroring in a post somewhere...

I may have misunderstood you, and if that's the case I apologize. Even so, I think you are taking some on screen bits too literally and that may limit you. This is not meant as an insult at all - I'm trying to help. Some of our long standing members here had and still have the same problem. NickyP could tell you I've said that many times. The manual is part of the problem because it was written in a very colloquial "do this and that happens" without providing any understanding as to how or why. And if you don't know something about how the engine thinks, you are immediately lost the very second you run into a problem or want to do something not explicitly documented.

General example: The engine doesn't know, and it doesn't care about "direction", color values, what a "hadouken" is, or any of that.

As for mirroring, you can certainly do that and more if you want. The secret is screens. Screens are a picture in picture capability of OpenBOR. These screens are blank slates that you can place anywhere, and put whatever you feel like into.

I have only edited and created with 3D before and with that it's very different approach. Technically I guess most games have been that way for a while. But in logic a person who is in a brand new in any concept (and I have never worked on a 2D game before) and doesn't know about screen mirroring

This is where I mention abstraction again. In engines like OpenBOR, the entity (what you'd call a model - when we say model we refer to the base model, copies loaded into gameplay are entities) and its visual component are typically separated to a greater degree than they are in a polygon engine. The entity is the functional set of values. There are also polygons involved, but they are for things like range and collision detection and are invisible to you. oldyz is partially correct about cardboard cutout thinking. The sprites are drawn almost as an afterthought.

Watch out though - thinking OpenBOR is some sort of primitive 2D engine will get you in trouble quick. The engine is absolutely 3D, and operates on a four axis playfield, plus two tracking variables for horizontal and vertical scrolling. There's no built in tracking for lateral scrolling, but the calculations are there to do it if we want to. Then those are translated back to a 2D screen for display. If that sounds familiar - it should. That's the same way polygon engines work. The only difference is we are using prerendered sprites instead of models to build the final image. Incidentally, just as most 3D engines can make limited use of sprites, OpenBOR can also draw polygons - but it will be very inefficient at it, just as polygonal engines are very poor at caching and rendering more than a few sprites.

Actually things are going really well from my perspective...

Good to hear it. Module building can be very frustrating, but it's that much more rewarding in the end.

DC

 

[oldyz]

Wombat2112
aside from all that, i can only some things that may be wrong...

1 is that your sprites are facing right to left (in your graphics editor)
from what i have seen they should be left to right (back of character to the left , front to the right
2 it could be that if you use script, some lines have the info that you need to move to another line & viceversa
3 in the character's text file , you may have animation frames mixed up somewhere... or the walk# is mislabeled

heck , maybe its not the animations at all, maybe is the input mapping.. is it in the programming or coding? the options menu?

you have to double check everything

 

[Wombat2112]

oldyz  I haven't put the animation in game yet but yes that is it exactly! The sprites are facing right instead of left not all of them just some of the attack sprites. I guess I shoul have worded things differently. I chose these because they were the character I wanted and already cut from the sprite sheet. So I thought why not flip them? Looked Okay to me in the photo editor. And then later before I knew about screen mirroring I wondered well will I have the same problem with the sprite facing right which led to my original post. 

 

[oldyz]

in that case your fix maybe drawmethod....

i can't remember the meanings of the numbers, you have to looks at the manual....

if drawmethod or any of the stuff contained within the character .txt portion of the manual does not fix it, then you will have to re-edit your sprites in the graphics editor

for example, drawmethod, can control how any frame of any animation looks like, from transparency to its scale  & some other things.

i recommend that you experiment with all values of drawmethod so you can see what it can do & keep a memory of them for later use

 

[Wombat2112]

Thanks It seems odd that someone would extract sprites facing right when some of the others are facing left? lol If I can't just reverse the images and it work I will probably just abandon this project and begin a new one. I really liked this character but I have learned to not become stuck on any one idea.