Author Topic: 3D 3rd Person Camera -- Issue with rotating camera face using jo_3d_set_target  (Read 845 times)

ponut64

  • Full Member
  • ***
  • Posts: 175
  • Karma: +13/-0
    • View Profile
Here's a youtube video of my problem

https://youtu.be/6AnHrUpgp88

I don't want to bother you wizards too much here since I've had lots of questions before that I eventually just figured out on my own.

But on this one I really don't have any other idea of how to continue.

Using jo_3d_set_target allows me to rotate the camera's POV, but only for 180 degrees, then it appears to stop.
Which means in practical terms I can't turn the camera around to properly face the "character".

Maybe there's some tricks of translating the entire world to get it to look like it's turning around, but the math involved is too complex for me when I am already translating the world in a circle to get the camera to appear to move around the character. Now I just need to get the camera to face the character.

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Can you share some of your code?

ponut64

  • Full Member
  • ***
  • Posts: 175
  • Karma: +13/-0
    • View Profile
Yeah sure, here's everything.

http://www.mediafire.com/file/lhscs08j5lengcl/cam_testring.zip

It's a little edited but the functionality (or lack thereof) is there.
« Last Edit: February 24, 2018, 12:30:26 am by ponut64 »

ponut64

  • Full Member
  • ***
  • Posts: 175
  • Karma: +13/-0
    • View Profile
Just a bump to let everyone know that I have edited the previous post a million times and now it has something useful.

Sorry, I will do my best in the future to a) refrain from double-posting and b) be generally excellent. And thanks for reading.

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Ok, I'll look it up.
Btw, what kind of game are you trying to do?

ponut64

  • Full Member
  • ***
  • Posts: 175
  • Karma: +13/-0
    • View Profile
Probably a flight or hovercraft "obstacle course" game for now.

Just based on the math and the Saturn's hardware, most likely a flight game.

Truth be told though, once I figure out camera controls I could at least attempt various other things...
« Last Edit: February 24, 2018, 03:24:12 am by ponut64 »

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Yeah, I kind of realize that after not touching Sonic Z-Treme for a while I'm getting a bit rusty with third person view.
I'll see what I can do over the weekend.

That being said, you should avoid the look at and use the matrix instead.

Even SGL warns against the lookat function as it's not 100% reliable.
« Last Edit: February 24, 2018, 04:01:55 am by XL2 »

ponut64

  • Full Member
  • ***
  • Posts: 175
  • Karma: +13/-0
    • View Profile
Not sure I follow on real alternatives to look at, since that's what all the jo engine demos did.

But I guess that's what I have expert help for  8)
thanks.

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Sorry I didn't have enough time to fully implement a third person camera, but here you have an updated version of your demo with full 3d space control, acceleration and basic collision.
Implementing a full third person camera shouldn't be that hard, but it could take a little while and some trial and error to get it right.

Let me know if you need more help.

ponut64

  • Full Member
  • ***
  • Posts: 175
  • Karma: +13/-0
    • View Profile
That's a lot of work you've done. Thanks, XL2!

I'm going to do my best to understand this. Or at least something like it.

ponut64

  • Full Member
  • ***
  • Posts: 175
  • Karma: +13/-0
    • View Profile
So here's an update.

https://youtu.be/HuefQ6RKW_k

Update update:
http://www.mediafire.com/file/pxrj5ut22yfmzi1/RTFK.zip

source code.

If someone can figure out what's causing the VDP2 plane to flip shit, that'd be a great help.
I'll keep hacking on it in my own time.
« Last Edit: March 09, 2018, 06:45:35 am by ponut64 »

ponut64

  • Full Member
  • ***
  • Posts: 175
  • Karma: +13/-0
    • View Profile
I've much to learn about RBG0. It seems to freak out when the Z or X values are near the limits.

Edit: This one's a little refined.
http://www.mediafire.com/file/lcm2qdr2cdp8qsb/RTFK2.zip

/e more:

I think I can ignore the VDP2 plane being flippy near its extents.
I can separate its translations from the game world, and have it wrap at about 2,000 or so (a value which prevents it from getting flippy).
We'll see. I've got a lot of things to figure out as you may have guessed  :D
« Last Edit: March 09, 2018, 08:06:26 pm by ponut64 »

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
I only took a short look at your code (I didn't try to compile it), but the way you warp around the world doesn't work :
-If you say when you are > 32677, you become -32677, then the issue is that if you are in fact 32700, you will still go to -32677, which will look like it's jerking.
-You are warping the Y value, which will cause isses as the VDP2 plane will become "over" you.
-You are using stuff like : when you press right, rotation ++. The problem is that at 60 FPS it won't behave like at 30 FPS. You want to move at the same speed regardless of the framerate. Take a look at the code I gave you, use the framerate instead and multiply it with a value (slMulFX).
-You put everything in the main file. You will have issues at one point where it won't compile because you will have too much stuff in one file. I really suggest you take what I did last time an re-use that (I learned the hard way, I tried to avoid having you get in the same problems I had).
-You mix the Jo engine matrix functions with the SGL matrix functions. Be super careful : Jo Engine takes integers and multiply them by 65536.0 (toFIXED), while SGL takes in already fixed values. If you mix both, you will get issues.
-Functions like Jo_div_by_2 are OK for unsigned numbers, but not for signed numbers (it will cause issues where one direction goes faster than the other). You can either divide or, even better, multiply by 0.5 using the fixed library, like this : slMulFX(value, 32768)

ponut64

  • Full Member
  • ***
  • Posts: 175
  • Karma: +13/-0
    • View Profile
... Now that is a superb tip for keeping things in separate files. I will keep that in mind!

- As for the jerk -- Good tip, I will make note of that when it becomes a problem. If I cut the number farther from the max (32768) and then change sign, that should be fixed.

- Warping Y - Yeah, that happens. It was freaking me out and I spent a lot of time trying to fix it. But in all that time, I realized that I don't need it to be perfectly stable all throughout a FIXED value.
I can just make it reset earlier (at around 20,000 or so) and it will never get flippy. I don't need to track anything relative to the plane since it's just... there. Thanks for telling me why though, as reading some slides I did figure there was some inadvertent issues with rotation constraints on RBG planes.

- I see. Just curious, is the system timer based on frames? I'm assuming it isn't. In which case, I have evenFrame and oddFrame which I can check one or either for 15 FPS or 30 FPS operations.
I can test that with Yabause (because it goes crazy with the frames). Otherwise I can just use your framerate value.
[/e: if yabause framelimit is disabled, both methods do not work. if framelimit is enabled, both methods do work. Is my method worse? Probably.]

- Mixing jo matrix and SGL matrix: That's mostly since I was cut and pasting things from my other projects. I should probably just stick to SGL matrix functions even if its super annoying to type in toFIXED all the time, they help me understand the numbers I'm using. I've definitely had some derp debugging moments because of that.

- Excellent tip regarding that. I had already noticed that one direction was going faster than the other and I figured it was just my keyboard. As always you are a font of SGL wisdom.

Thank you! I'm quite close to some gameplay programming.
« Last Edit: March 10, 2018, 04:19:52 am by ponut64 »

XL2

  • Sr. Member
  • ****
  • Posts: 341
  • Karma: +72/-1
    • View Profile
Just be careful with the warping.
If you are, let's say, over 16384, remove 32768 instead of doing = -16384.
Because you could be at 16444, going to -16384 won't be smooth.
There are no issues with the RBG0, but if you warp under, it will become higher than you.
The framerate timer is based on the internal timer. The Saturn has v-sync, so you won't get over 60 fps on real hardware.
I don't understand your odd/even frame thing, but if it's to keep track of the framerate, it's useless.
Since one frame could take 1/60 seconds, the other one 2/60, etc. Doing ++ won't take into account the elapsed time.

 

Sitemap 1 2 3 4 5 6 7 8 9 10 
SMF spam blocked by CleanTalk