Canceled Fatal Fury Chronicles

Project is halted prior to completion and will not receive further updates.
I had them in small resolution mod, 480x272 and water image is 660x370.
I belive these effects were made by utunnels ? He made a demo with them, where you could control amplitude and wavetime in realtime by keyboard, they were not available in original BOR.
I remember when they were introduced and posted about on forums, probably lavalit or even way back.
In openbor.c  i dont see who did what, no credits.
 
bWWd,

Utunnels added the fglayers and access to changing the settings for water mode effects, but the effects were always there. You can even see them in the original BOR and in the module maker pack.

DC
 
Here's a little something I'm working on - mapping out sprite pixels in real time. The idea is to programmatically describe the visual sprite as it appears to us humans rather than a set of rectangle coordinates the computer normally sees. There are a lot of reasons you might want to do this, and I have one in particular in mind.

The first step is locating the sprite's outer borders - you can't just use the source image size because OpenBOR optimizes sprites by auto trimming them on load. Fortunately, the optimized dimensions are open to script, so it really just comes down to some math to find their on screen positions. Notice the Red and green dots - those are being generated by script and drawn to screen with the drawdot function. They represent the current left/right upper corners. From there I can start the real mapping.

Openbor_mapping.PNG


DC
 
Damon Caskey said:
Here's a little something I'm working on - mapping out sprite pixels in real time. The idea is to programmatically describe the visual sprite as it appears to us humans rather than a set of rectangle coordinates the computer normally sees. There are a lot of reasons you might want to do this, and I have one in particular in mind.

The first step is locating the sprite's outer borders - you can't just use the source image size because OpenBOR optimizes sprites by auto trimming them on load. Fortunately, the optimized dimensions are open to script, so it really just comes down to some math to find their on screen positions. Notice the Red and green dots - those are being generated by script and drawn to screen with the drawdot function. They represent the current left/right upper corners. From there I can start the real mapping.

Openbor_mapping.PNG


DC
Click to expand...

Damon Caskey

I was wondering something similar, about the collision detection.

i base this on Goldeneye & the way the geometry works there, you see, when it comes to levels , there is the geometry you see, & then there is invisible geometry called "clipping" the clipping determines the boundaries of the walls & fences & such - When you run into an invisible wall that does not allow you to fall in a crevasse or hole, its because a clipping tells you there is a wall there.
Clipping features colors, these colors tell you if a floor is metallic, or wood, or if it activates something


When it comes to sprites, i was thinking a non-visible sprites that are part of the characters that tells you exactly where the bounds of a character are & not only that, this sprite can feature colors, for example the head can be colored red & this tells openbor that this is a critical area, same as joint areas & groins

this would replace hitboxes.

ever since i watched this video:


i was thinking of Openbor "clipping" sprites instead of collision boxes
 
oldyz said:
...When it comes to sprites, i was thinking a non-visible sprites that are part of the characters that tells you exactly where the bounds of a character are & not only that, this sprite can feature colors, for example the head can be colored red & this tells openbor that this is a critical area, same as joint areas & groins
Click to expand...

oldyz,

I think you need to gain a better understanding of how these sorts of things operate. There's a reason why sprite engines work the way they do. Also, that video is completely inapplicable here - he was taking advantage of hardware collision, and you saw the hoops he had to jump through to make it work. OpenBOR is muti-platform software. We couldn't use hardware pixel collision even if any of our platforms had it (and none of them do). No engine of any kind uses software pixel collision. It's just too CPU intensive and has no real benefit over rectangles and spheres.

I was going to explain in detail the specifics, but I don't have time for all that now.

DC
 
Damon Caskey said:
I think you need to gain a better understanding of how these sorts of things operate. There's a reason why sprite engines work the way they do. Also, that video is completely inapplicable here - he was taking advantage of hardware collision, and you saw the hoops he had to jump through to make it work. OpenBOR is muti-platform software. We couldn't use hardware pixel collision even if any of our platforms had it (and none of them do). No engine of any kind uses software pixel collision. It's just too CPU intensive and has no real benefit over rectangles and spheres.

I was going to explain in detail the specifics, but I don't have time for all that now.

DC
Click to expand...

I figured that it might be intensive, it's too bad because i was thinking a similar approach would also give sprites depth -
it annoys me to see grab animations where the arm is on top of the enemy sprite instead of behind the enemy, or that some borders do not respect the  accurate depth & show characters in front instead of behind.

in nutshell this other hidden sprite set features shades, the shades represent z-depth values
example for Terry- you would see his right arm & leg be a light grey color, his torso would be gray & his left arm & would be dark grey.
this means that in some animations, his  left /leg arm will be drawn by  the engine behind the enemy sprite, the torso in front & the left/arm legs over.

The only other option i see to duplicate this is by making up characters with bound entities but that method would not fix how a curved object or the subtle overlays of a slanted edge over characters with normal perspective.

its hard to explain without pictures, but it basically would be for depth for what bump-mapping does for textures (yes, i was thinking of bump-map layers too)
 
it annoys me to see grab animations where the arm is on top of the enemy sprite instead of behind the enemy, or that some borders do not respect the  accurate depth & show characters in front instead of behind.
Click to expand...

Me too, and this is easily fixable with bound pieces. Some of my grab animations already use this. As for curvature and perfectly respecting borders - that's just limitations of the medium. I'd love to see a Soul Caliber, Tekken, or even a Dead or Alive game with no polygon clipping, but it's not going to happen for a while because that kind of calculation requires more CPU grunt than is reasonably available right now.

i was thinking of Openbor "clipping" sprites instead of collision boxes
Click to expand...

I missed this earlier. OpenBOR DOES have clipping, and it isn't hard to do. I don't want to be harsh, but come on man... there's so many things you've requested that are easily workable if you just give it a try.

DC
 
bWWd said:
thats cool, so is it image dimensions or actual sprite? Whats the plan to use this with?
Click to expand...

The dots represent the outer edges of the image as it is stored in memory post optimization. It's the first step in something I want to keep a surprise until finished, but I've done a lot more since then and it's really close. Just a day or so.

DC
 
Damon Caskey

thanks, i am trying , it just too much stuff to memorize, fact is i am saving that page you showed to the HD..

Either way , i don't know why its called "clipping" in some 3D games but the best i can tell you is that it's what gives different physical properties & boundaries to level's floors & walls in some 3D games.

here is a link to instructions on  how to set up  "clipping tiles" for a level:
http://n64vault.wdfiles.com/local--files/ge-guides%3Aclipping-guide/GEEditorV2ClippingTutorial.pdf

I just thought that if this where to be made using pixel colors/shades, it would remove some of the weird problems inherent to 2D engines,
example , the fact that characters in most games actually "merge" instead of respecting their boundaries - and they start "stacking" one over the other until they become sort of like a single thing...

i don't know if its best to make another topic regarding this next question, (related to Openbor's drawmethod/clipping link):

the thing that i would like to see expanded or know how to manipulate is this:

shift_x Integer Skew the item along its horizontal axis.

are there any pointers on how i could manipulate the 4 corners of a  sprite like handles? would effectively allow us to make deformations to the sprites in a frame by frame basis only using a single one sprite & drawmethod

In GIMP this is called handle transform
https://youtu.be/mLYbS2GT-xc

im hoping that it not CPU intensive to use drawmethod that way
 
bWWd & NickyP,

Here's the effect I was working on - real time scripted rain splatters. It's pretty subtle really, but I think adds a nice touch and helps sell the storm. The rain effect entity runs an update script that enumerates all entities on screen, and if they are a player, enemy, or npc types it performs the following:
  1. Every ten update cycles, set a variable to 0 or 1, this is used as an X shift below.
  2. Get the pointer of current sprite in use.
  3. Get the true offsets, width, and height of the sprite as engine sees them.
  4. Loop across each column of pixels starting from 0 + the X shift, then incrementing two at a time. Incrementing by two is kind of obvious - if we drew a dot on every column we'd just have a solid line. As icing on the cake, we also are halving the number of column loop cycles. Adding the X shift to our start position gives a left/right movement.
    1. Loop from top row to bottom, one pixel at a time. At every iteration we alternate a Y shift variable from 0 to 1. We do this whether or not this iteration will take any other action below, giving our up/down shift a bit of randomness.
    2. Get the color index of sprite pixel at current column and row. If is index 0, we know this is a transparent pixel, so we do nothing else and keep going.
    3. Once we find a non-transparent pixel, we translate the sprite pixel location to on screen location, adding the vertical shift. We have to account for scroll location, direction of the sprite, and some other factors here, but it's all straight forward addition and subtraction. Once we have a screen pixel location, we use the drawdot() function to draw a colored dot, and exit the vertical loop.
The end result is a series of dots drawn along the top of each on screen character, each with a random one pixel offset, simulating the effect of rain impact. The step by step makes it sound like a of of work, and it certainly was a massive pain to set up, but it's not really taxing on system resources. The entire procedure is just counting and straight forward arithmetic. No division, entities, or CPU heavy operations.


I have several other ideas I'm going to implement using this technique. Hopefully can get to them soon.

DC
 
Last edited:
this looks great, but would it be too taxing to extend this to decoration entities (or just not limit it at all)?
it would be nice to see the effect on the closer objects in your video , like those "stone" lamp-like things and the bridge

This is out just in time for a rainy level i'm working on

I have a question, for higher resolution MODS, you could replace the dots with some animation frames or sprites of you own, correct?

 
oldyz said:
this looks great, but would it be too taxing to extend this to decoration entities (or just not limit it at all)?
it would be nice to see the effect on the closer objects in your video , like those "stone" lamp-like things and the bridge
Click to expand...

Originally I had it around the lamps and the gazebo roofs too, but I just didn't like it. Made the screen way too busy, and actually less believable than confining it to the active characters.

This is out just in time for a rainy level i'm working on

I have a question, for higher resolution MODS, you could replace the dots with some animation frames or sprites of you own, correct?
Click to expand...

Sure, you'd just spawn entities instead of drawing dots, and I've already have demonstrated this in earlier video (radius distribution). Very useful for generating particle effects.

DC
 
Minor new addition (city lights), but mainly this is a stress proof test. I wanted to make sure my rain splatter could hold up with a ton of enemies on screen, so I spawned in 50 Rays. Since each Ray is affected by the rain splatter, that's anywhere from 20-40 extra sprites each, plus the calculations needed to display them. Add to that both water modes (sine wave for the lake and affine for clouds). Top it a off with tons of alpha effects in play (every single hit flash is blended), plus a full screen transparency overlay (the rain itself).

In total, there's ~1800 sprites on screen at given time. At one point it jumps over the hard code limit, causing a screen black out, but the frame rate never drops below 60. Tell me again how you can't put lots of stuff on the screen without slowdown.

I did notice the cumulative attack pause when you hit a few dozen guys at once can practically induce stop motion on the attacker. Notice Terry's Rising tackle and that at one point a Ray hitting a bunch of other Rays freezes in the air. That's intended behavior though. The engine does take hitting multiple targets with one attack into account - each target hit accrues less and less pause time, but it still adds up. If you don't like it, you can modify or eliminate the added pause with script.


DC
 
How you can modify pausetime with script? Its a feature i asked CGRemakes to introduce into openbor, based on capcom beatemups, it would be nice to have more control over it.
 
bWWd said:
How you can modify pausetime with script? Its a feature i asked CGRemakes to introduce into openbor, based on capcom beatemups, it would be nice to have more control over it.
Click to expand...

I would like to have different pause times for attacker and target someday :)
 
bWWd said:
How you can modify pausetime with script? Its a feature i asked CGRemakes to introduce into openbor, based on capcom beatemups, it would be nice to have more control over it.
Click to expand...

[
O Ilusionista said:
I would like to have different pause times for attacker and target someday :)
Click to expand...

bWWd and O Ilusionista

Sorry.. this is a little embarrassing. I was thinking of the rebuilt entity properties. All the "time" variables used to control pause, gravity, AI and so on are exposed. They're available in alpha build and my personal test build, but not in stable release. I'm sure there's a way to do it with current version, but I'd have to work it out as some kind of trick.

Note I'm only referring to pause control. All videos and other stuff I've posted is done using functionality that's older than dirt.

DC
 
Here's some 3D perspective clouds in progress. I did this once for Golden Axe Hackjob but decided X axis only clouds were more appropriate for that stage and took them out. This time around, I think the clouds coming at you will really help sell the storm.

As you can see this is just a roughing to work out positioning specifics. There's some bleed through in the water to take care of and I don't have appropriate cloud sprites yet. But the effect is up and running. I also added another layer to the temple grounds.


Before anyone asks - Yes, you can use this technique to make floors and vertical walls too. Yes, you can make a fully 3D stage, and I already have one planned.

DC
 
A randomized storm "system"  would be so cool. GTK radiant had a user created mod at one time that pulled it off nicely. I have some nice textures of storm clouds I took with my camera and some I found. I'm sure you have done it but I have found some great textures outside in nature often. When I first found OB and wanted to do something with GI Joe I spent about 8 weeks doing nothing but looking for art lol. It's great that this engine and community has not been abandoned as many do.
 
You must log in or register to reply here.
Back
Top Bottom