Ryu in OpenBOR

msmalik681

OpenBOR Developer
Staff member
Just for fun I wanted to see what Ryu would look like in OpenBOR so I made a video to show anyone else who was interested.

 
The color looks fantastic. Animation is horrible, but that's somewhat understandable for a prototype effort.

I'm sure capturing and importing the rest of his frames would take a lot of work, but if you decide to do a complete version it would be worth the effort imo.

DC

 
Damon Caskey
Yeah as I cut the size of him down thought I should cut down the frames plus if I decided to use full frames it would take more time and effort then I have lol.  If I decide to rip more of ryu he may end up looking different as after years of paint shop pro I have decided to switch to gimp.

danno
I recently purchased street fighter 5 on steam so I decided to take in game screenshots and remove the background in paint but like 5 frames took me a whole day. So in the end I decided to hack into street fighter 5 and edit the training stage to a plain colour that made ripping ryu a much MUCH  simpler process.

here are the stages I made: http://modderbase.com/showthread.php?tid=1206
 
Great, i would rip his frames in large quantities, walk at least 30 frames ( i had 24 for heman walking)
It would look good with 3d models, cutting down frames on 3d modeled sprites deesnt look good, donkey kong on snes had many frames and those were 3d models.
Rip all the frames game displays, then you can delete some if needed.
with palapply batch mode it shouldnt take too long to rip and place sprites in game.Its mostly walk and idle that need best looking frames and most smoothness cause theyre displayed most often
 
I´  m working on an update for the game and one of my plans is to join a CVS version of Ryu  for the character roster.
 
Very nice msmalik681 ! I'm kind of surprised this hasn't been done yet. Marvel vs Capcom 3, Tatsunoko vs Capcom, Dragon Ball Fighterz,  and other 2.5D fighters have plenty to "rip" from. I imagine the supers would be difficult to capture due the dynamic camera angles, though.
 
Tell the truth i am suprised too this all started with me searching for sf5 ryu in mugen but only finding sf4 rips
 
excellent work,

now all he needs are some pseudo 3D stages & decorations & i'm trying to work on that too,

you will need this, at least, to rip & propperly make footage of a 3D level
https://forum.beyond3d.com/threads/rip-models-maps-from-any-3d-game.36529/
NickyP
ripping the 3d models could help with the dynamic camera angle issues


or you can hack ryu to be transparent or invisible  and scroll the stage while capturing the footage of the stages you want.

in order to make it change angles along with your walking you will need to make the stage frame captures the same # as the total length of the stage minus 480
(every pixel is a frame)

& use entities to trigger the animation

the caveat is that if your game has 8 stages the game will probably end up being around 2GB

 
oldyz said:
...the caveat is that if your game has 8 stages the game will probably end up being around 2GB

You don't really have to do this. It's true you can approximate a 3D stage by capturing every viewpoint, preloading it as an image and displaying it back in conjunction with scroll position. This is the quick and dirty method. You can see it in Rocket Viper (Second stage, London area) and it looks pretty good. But it has a couple of drawbacks:

  • Those preloaded images do add up. You can mitigate this tough, just by unloading them when you aren't using them. There's no reason to have stage 8's images loaded when you're on stage 4. So no worries about needing 2GB of RAM. It's true the module download size will get pretty big though. Rocket Viper keeps things reasonable by just making the 3D stages really short, so there aren't that many images in the first place.
  • On its own, the depth is entirely fake. There are no layers, just one flat pseudo 3D background. This severely limits interactivity. No matter how far into or out of the background, everything is just plastered over it.
  • Scrolling is limited to one axis only (it's theoretically possible to have X and Y scrolling together, but not even close to feasible).
  • You are limited to 256 colors. You can get full RGB, but that requires some tedious image work where you break the image into three layers of R, G, and B, and then overlay them.

The better way is to leverage OpenBORs limitless number of fglayers and affine capabilities. It's best to capture the stage in blocks and then lay these out with fglayers and affine transforms as needed. You can use as many as you need to reproduce the original stage to near perfection.

Take at look at my stage 1 in Golden Axe to see what I mean. Obviously I'm not really reproducing a captured 3D stage, but the principal is the same. The field behind play area is an affine transform, and so is the sky. Trees, rocks, etc. are all fglayers, so I can (and will) allow moving objects to move in and around them. The play area itself is NOT pseudo 3D, but that's just a design choice I made. Nothing at all stops you from making the entire stage a perfect 3D work.

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

The disadvantage is it requires more front end planning, but in the long run will cost you a lot less time, is MUCH less resource intensive, and will produce a better looking, more interactive experience. Lastly, OpenBOR layers support 24bit .png, so this method also means no color loss if you so choose.

To take it even further, check out the techniques used to build 3D objects Toy Story. OpenBOR can use these too, but without the limitations they had to worry about.

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

DC
 
wow some nice stuff. I personally hate making stages and all this extra work looks nice and does give the game a more professional feel to it.
 
Damon Caskey : This is a very cool youtube Channel and that's a good surprise that you quote Game Hut :).
Speaking with oldyz, there 2 cool videos that shows how can the background can react to the player position and makes pseudo 3D effects vertically:
and horizontally:
That worths to try to make the same with Openbor :).
 
Damon Caskey  & kimono

so far when it comes to RAM there seems to be no problem from what i have experimented.

the only problem i see is the total size of the module, right now with all the "puzzle" piezes put together, im looking at a 4gb module, total size.

I wonder how the heck did Rare compress all those "video" frames in just less than 300 MB

1GB of data is for just 2 stages alone in my experiments.

Sure as heck i will try some tricks, like mode 7 for floors in places, maybe even for "walls", but some objects & layers of background will have to be made using "video"

& other tricks can include the re-use of frames like those towers

as for interaction, when you have control of the rendered background you can select in which layers you display the pieces, some of those pieces can be part of the panel & they can even scroll at different "Z" speeds

try to imagine how would you split this render
https://www.youtube.com/watch?v=4Rkzi3FahN0

And what things will you have in the play area both as platform & dinamically animated...

Obviously some those video layers will merge at some point  (beyond the play area usually) like mountains or clouds & those can be best represented with flat sprites, but objects near the play area look best in pseudo 3D, like Glaciou's temples, or his ship in KI 2

https://www.youtube.com/watch?v=6OMh0Z7Ji8I
 
oldyz said:

oldyz, I'd like to see what you are using for one of your images. 1GB is an incredible amount of memory for a single stage - I find it really hard to believe you've properly optimized your image assets. Even if you are using 24bit .png files and running 480*272 screen res, that's 392K per image. You'd need 21,000 of those just to make one GB.

Something is WAY off here. Why don't you post some of your material and let us have a look.

DC
 
Damon Caskey said:
oldyz said:

oldyz, I'd like to see what you are using for one of your images. 1GB is an incredible amount of memory for a single stage - I find it really hard to believe you've properly optimized your image assets. Even if you are using 24bit .png files and running 480*272 screen res, that's 392K per image. You'd need 21,000 of those just to make one GB.

Something is WAY off here. Why don't you post some of your material and let us have a look.

DC

I am aware, i am stuck at a point where i cant make the process work the way i want it to.

the images i'm using are indeed not optimized, i'm pretty sure they can be brought down to size... another factor is figuring out the pace of the  frames , this could lead to another reduction.
i will re-name the old thread i made & post the level demo there and a brief tutorial, with a better suited background instead of the old Popeye footage i have been using... and in some points i will add the preferred elements with on-game explanation of what they need to be, instead of what they are.
 
Back
Top Bottom