Show Posts
151
Project announcement / Re: Sonic Z-Treme
« on: April 22, 2018, 10:01:28 pm »
That's possible in some way, the question is, who is gonna make it?
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
152
Project announcement / Re: Sonic Z-Treme
« on: April 21, 2018, 02:24:34 pm »
Thanks for posting that here.
I always did have the idea of using VDP2 layers for fade-in / fade-out (obviously, what else would you use).
I'm curious though, are those RBG or NBG layers?
I always did have the idea of using VDP2 layers for fade-in / fade-out (obviously, what else would you use).
I'm curious though, are those RBG or NBG layers?
153
Project announcement / Re: Sonic Z-Treme
« on: April 05, 2018, 08:47:07 pm »
Burning Rangers does clearly play multiple CD Audio tracks at once, and I am not sure how it does that.
Maybe I am being fooled, and what they are doing is reading & playing one word at a time, so the voice data stream only consumes as much as the biggest word. Who knows. It's "Redbook Audio" quality, that /e is completely wrong and I am glad there are more educated people in here.
Maybe I am being fooled, and what they are doing is reading & playing one word at a time, so the voice data stream only consumes as much as the biggest word. Who knows. It's "Redbook Audio" quality, that /e is completely wrong and I am glad there are more educated people in here.
154
General Jo Engine Help / Re: SAT / Separating Axis Theorem math: y no werk
« on: April 02, 2018, 03:55:46 am »
So here's my conclusion to this thread
http://www.mediafire.com/file/do4493rxrmyqk59/bounder_share.c
Instead of full SAT, or a complete RBB, this just calculates the normals of the RBB and uses a dot product comparison between a point projected onto those axis and the dot product of the axis normal vectors themselves. It appears to produce correct results. Technically this is still working on the separating axis theorem, but is much simplified.
The conclusion: separating axis theorem is a working concept, but too complicated in my case.
If someone does need it for jo engine, a sample is in this thread, that is at least somewhat functional. However my warning is that sample includes many mis-labeled axis and so the physics object rotates a different way from the actual object. On top of being very sloppy.
/e: The more I snoop this stuff, the more errors I find... Heh ...
/e: I really must update this thread *one more time*. You see my previous math had so many problems since I had solved for an XYZ system. Well as you know SGL does not seem consistent in any of its axis systems; mesh rotations are in a ZYX system. There is no easy way to "translate" XYZ to ZYX, so I had to fix that. It was actually pretty easy, having spent way too much time on the trig for XYZ. So here is an updated file. It's a single file but the .h files that go with it are included in text (as im sure you can figure out). I hope no one wasted time on any of the code I have shared.
http://www.mediafire.com/file/nbxpemvrh4c1f78/bounder_final.c
http://www.mediafire.com/file/do4493rxrmyqk59/bounder_share.c
Instead of full SAT, or a complete RBB, this just calculates the normals of the RBB and uses a dot product comparison between a point projected onto those axis and the dot product of the axis normal vectors themselves. It appears to produce correct results. Technically this is still working on the separating axis theorem, but is much simplified.
The conclusion: separating axis theorem is a working concept, but too complicated in my case.
If someone does need it for jo engine, a sample is in this thread, that is at least somewhat functional. However my warning is that sample includes many mis-labeled axis and so the physics object rotates a different way from the actual object. On top of being very sloppy.
/e: The more I snoop this stuff, the more errors I find... Heh ...
/e: I really must update this thread *one more time*. You see my previous math had so many problems since I had solved for an XYZ system. Well as you know SGL does not seem consistent in any of its axis systems; mesh rotations are in a ZYX system. There is no easy way to "translate" XYZ to ZYX, so I had to fix that. It was actually pretty easy, having spent way too much time on the trig for XYZ. So here is an updated file. It's a single file but the .h files that go with it are included in text (as im sure you can figure out). I hope no one wasted time on any of the code I have shared.
http://www.mediafire.com/file/nbxpemvrh4c1f78/bounder_final.c
155
Welcome. it is nice that there are new folks like me & you coming in these days.
Recommended learning & viewing is the "samples" folder of the jo engine download.
Re-write those demos "main.c" file in your own way, step by step, and when done see if it works.
That's how I started. In effect you get something that is step-by-step.
To get anywhere with Jo, you need to dig into the code, but I am sure you know that.
Recommended learning & viewing is the "samples" folder of the jo engine download.
Re-write those demos "main.c" file in your own way, step by step, and when done see if it works.
That's how I started. In effect you get something that is step-by-step.
To get anywhere with Jo, you need to dig into the code, but I am sure you know that.
156
General Jo Engine Help / Re: SAT / Separating Axis Theorem math: y no werk
« on: March 30, 2018, 08:31:33 pm »
I am very thankful you are so willing to help.
If when I chop this down to its barest calculations (that I can fathom) and it still may not perform correctly, and I can't think of another way to do it, I'll be sure to ask.
If when I chop this down to its barest calculations (that I can fathom) and it still may not perform correctly, and I can't think of another way to do it, I'll be sure to ask.
157
General Jo Engine Help / Re: SAT / Separating Axis Theorem math: y no werk
« on: March 30, 2018, 02:08:26 am »
Well, I would like to update this thread with a working version of the code.
At least mostly working. There are rounding errors, making some angles of the box not detect but that can be solved! and it actually doesn't crash.
http://www.mediafire.com/file/q782jq8campl0ru/bounder_good.c
As pointed out by XL2, is this good? efficient? Nope. but its a proof of concept for the separating axis theorem, at least.
At least mostly working. There are rounding errors, making some angles of the box not detect but that can be solved! and it actually doesn't crash.
http://www.mediafire.com/file/q782jq8campl0ru/bounder_good.c
As pointed out by XL2, is this good? efficient? Nope. but its a proof of concept for the separating axis theorem, at least.
158
General Jo Engine Help / Re: SAT / Separating Axis Theorem math: y no werk
« on: March 28, 2018, 09:14:49 pm »
I am focused on using an arbitrary RBB (rotated bounding box). Not related to the mesh, just calculated. That's in the code, it works just the values are not being changed, but I did not know how to test a point against any 8 points making a rectangle that is rotated in any way.
I don't see how an amalgamation of AABB can achieve precisely what an RBB does.
I know what I am doing is very complicated, probably way more complicated than it needs to be, but I was hoping that I could at least get a non-zero result out of jo_vectorf structs.
Per-quad collision detection is not desired, as that should be in theory more complicated than what I want to do assuming I understood how to simplify what I want to do.
I can't fathom a way to compare a point against 8 other points that make segments that are not axis-aligned... the way I figured that could be done was project all the points on the X, Y, and Z axis vectors of the box, these projections make axis-aligned segments to that particular box (that is rotated), and if the point compared against the box overlaps with the segments then it collides (found by comparing the segments of "player" to "segment max" plus "player" to "segment min" is equal to "segment max" to "segment min".
Obviously the computationally intensive act of projecting what would end up being 16 points to 6 other vectors would be something that would be triggered by an AABB "physics proximity box" to make it faster.
I am not trying to compare if the "player" collides with the "ring". The core idea is if I can compare if the "player" or any given object is in any other given rotated rectangle area.. I'm sure you know that, but I don't see how an amalgamation of AABB can achieve that precisely.
So yes, I am trying to build a space rocket. Working comes first, simplification later. The core issue is why can I not change the value of a jo_vectorf struct. I do not specifically need these structs, as I could just make another function for inner product that does not need said struct, but I'd like to figure out why. and like i said, its probably something more basic about C programming than anything, as I am a newbie.
thanks for reading & replying
I don't see how an amalgamation of AABB can achieve precisely what an RBB does.
I know what I am doing is very complicated, probably way more complicated than it needs to be, but I was hoping that I could at least get a non-zero result out of jo_vectorf structs.
Per-quad collision detection is not desired, as that should be in theory more complicated than what I want to do assuming I understood how to simplify what I want to do.
I can't fathom a way to compare a point against 8 other points that make segments that are not axis-aligned... the way I figured that could be done was project all the points on the X, Y, and Z axis vectors of the box, these projections make axis-aligned segments to that particular box (that is rotated), and if the point compared against the box overlaps with the segments then it collides (found by comparing the segments of "player" to "segment max" plus "player" to "segment min" is equal to "segment max" to "segment min".
Obviously the computationally intensive act of projecting what would end up being 16 points to 6 other vectors would be something that would be triggered by an AABB "physics proximity box" to make it faster.
I am not trying to compare if the "player" collides with the "ring". The core idea is if I can compare if the "player" or any given object is in any other given rotated rectangle area.. I'm sure you know that, but I don't see how an amalgamation of AABB can achieve that precisely.
So yes, I am trying to build a space rocket. Working comes first, simplification later. The core issue is why can I not change the value of a jo_vectorf struct. I do not specifically need these structs, as I could just make another function for inner product that does not need said struct, but I'd like to figure out why. and like i said, its probably something more basic about C programming than anything, as I am a newbie.
thanks for reading & replying
159
General Jo Engine Help / SAT / Separating Axis Theorem math: y no werk
« on: March 28, 2018, 02:27:00 am »
I have made 2 versions (well... I broke one as it is saved too late past the conversion process to the other) of some 3D collison/zone detection math using RBB [rotated bounding box] based on the separating axis theorem.
One version uses entirely FIXED data types. It generates non-zero numbers, but there are overflows due to numbers being squared (600 squared, for instance, is beyond the range of FIXED data).
One version (that can compile) I made to combat the overflows is programmed using jo_vectorf and Sint32 values and should make the final conclusion more likely/less buggy (removal of decimal points in end comparison). But there is a problem... all the numbers are zero, and I don't know why. All of the math up to slInnerProduct (replaced with jo_vectorf_dot) and JO_SQUARE (being the overflow area) worked previously, now it doesn't work at all. At some point I had that same math working with jo_vectorf and Sint32 data, but jo_vectorf_dot would not operate since this was a situation in which the vectors were not stored as pointers (and instead "stack variables" or you know, missing the * in jo_vectorf *vector_here_is_pointer_with_star ).
And the other factoid, if I remove the initialization from jo_vectorf structs, it crashes.
Here is the jo_vectorf (float/int) code that I am trying to use:
http://www.mediafire.com/file/q9xmx8cd06c2666/bounder.c
Here, for comparison, is the (broken) more-SGL-reliant code:
http://www.mediafire.com/file/kwbr3kb5xa01u3c/bounder_broke.c
Thank you for reading.
The answer is probably simple. Maybe I am trying to typecast something wrong or am using jo_float2fixed and/or toFIXED improperly.
and here's the entire project
http://www.mediafire.com/file/nypbx88obigj3x7/RTFK.zip
/e: thread has a conclusion
http://www.mediafire.com/file/do4493rxrmyqk59/bounder_share.c
One version uses entirely FIXED data types. It generates non-zero numbers, but there are overflows due to numbers being squared (600 squared, for instance, is beyond the range of FIXED data).
One version (that can compile) I made to combat the overflows is programmed using jo_vectorf and Sint32 values and should make the final conclusion more likely/less buggy (removal of decimal points in end comparison). But there is a problem... all the numbers are zero, and I don't know why. All of the math up to slInnerProduct (replaced with jo_vectorf_dot) and JO_SQUARE (being the overflow area) worked previously, now it doesn't work at all. At some point I had that same math working with jo_vectorf and Sint32 data, but jo_vectorf_dot would not operate since this was a situation in which the vectors were not stored as pointers (and instead "stack variables" or you know, missing the * in jo_vectorf *vector_here_is_pointer_with_star ).
And the other factoid, if I remove the initialization from jo_vectorf structs, it crashes.
Here is the jo_vectorf (float/int) code that I am trying to use:
http://www.mediafire.com/file/q9xmx8cd06c2666/bounder.c
Here, for comparison, is the (broken) more-SGL-reliant code:
http://www.mediafire.com/file/kwbr3kb5xa01u3c/bounder_broke.c
Thank you for reading.
The answer is probably simple. Maybe I am trying to typecast something wrong or am using jo_float2fixed and/or toFIXED improperly.
and here's the entire project
http://www.mediafire.com/file/nypbx88obigj3x7/RTFK.zip
/e: thread has a conclusion
http://www.mediafire.com/file/do4493rxrmyqk59/bounder_share.c
160
General Jo Engine Help / Re: Warning: There is a Windows 10 update that breaks the compiler
« on: March 25, 2018, 10:24:23 pm »
Update: I have confirmed that Windows 10 Update KB4088776 breaks the compiler for me.
I had to re-enable the update service to play Sea of Thieves, which had this Microsoft-supported malware re-injected into my PC.
So I had to uninstall it again. Hopefully it doesn't re-install itself.
I'm going to edit the main post with the update number.
I had to re-enable the update service to play Sea of Thieves, which had this Microsoft-supported malware re-injected into my PC.
So I had to uninstall it again. Hopefully it doesn't re-install itself.
I'm going to edit the main post with the update number.
161
General Jo Engine Help / Re: Warning: There is a Windows 10 update that breaks the compiler
« on: March 16, 2018, 11:05:37 am »That's strange, I will check. Do you have the name of the update (KB...) ?
I don't remember it, but guessing by the date, it is KB4088776.
162
General Jo Engine Help / Re: Warning: There is a Windows 10 update that breaks the compiler
« on: March 16, 2018, 04:02:41 am »Did you try to reboot again instead?
I did, two times. Uninstalling the updates is what fixed it.
With Windows, who else knows what I have installed that could have caused the error in conjunction with the update.
163
General Jo Engine Help / Warning: There is a Windows 10 update that breaks the compiler
« on: March 16, 2018, 02:16:28 am »
An update on March 15th had broken my jo engine compiler. I forget the error but it was about a "failed to allocate" summat.
So if you suddenly get this, 1) disable the update service and then 2) uninstall all updates you can that were installed after Mar 13.
/e: I have found it is specifically Windows 10 "Security" Update KB4088776.
So if you suddenly get this, 1) disable the update service and then 2) uninstall all updates you can that were installed after Mar 13.
/e: I have found it is specifically Windows 10 "Security" Update KB4088776.
164
General Jo Engine Help / Re: Couple beginner questions on rotation around origin and model conversion
« on: March 11, 2018, 10:18:03 am »
Give this a "shot".
http://www.mediafire.com/file/bwh5cacsflrz3m2/VSedit.zip
All I did was throw in a different mesh .. that doesn't render properly.
But that's not the point.
The point is, I tried this on real hardware (a US saturn), and it worked properly.
Incidentally I also used this to confirm the 352x240 mode worked, which it do.
My guess is you are working with a quads limit of some kind... but I'm not really experienced enough to draw a conclusion on that. Something in your mesh isn't right.
http://www.mediafire.com/file/bwh5cacsflrz3m2/VSedit.zip
All I did was throw in a different mesh .. that doesn't render properly.
But that's not the point.
The point is, I tried this on real hardware (a US saturn), and it worked properly.
Incidentally I also used this to confirm the 352x240 mode worked, which it do.
My guess is you are working with a quads limit of some kind... but I'm not really experienced enough to draw a conclusion on that. Something in your mesh isn't right.
165
General Jo Engine Help / Re: 3D 3rd Person Camera -- Issue with rotating camera face using jo_3d_set_target
« on: March 10, 2018, 03:56:50 am »
... 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.
- 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.
SMF spam blocked by CleanTalk