well explained, thank you ❤

I was under the impression that the RE3 was just a distribution of the OpenRW engine, however R3 also included the copy-righted assets, and so they where able to re-publish it without those assets? I'm not 100% sure, and what you said here sounds legit

@@jason_m2003 RE3 contained only reverse engineered code without the assets. It required you to have original game files similarly to OpenRW. RE3 got in trouble, because even though they didn't include copyrighted assets, they reverse engineered code from the original executable which itself is copyrighted. Reverse engineering is kind of a grey legal area, so after the first DMCA takedown the creators of RE3 appealed and got the repository back online for a short period of time, but then Take Two filed a second DMCA and the project got taken down again, and this time the creators of RE3 weren't able to get it back online and the project is unavailable to this day

​@@jason_m2003 Just as I said before these are two completely different projects. RE3 contained only reverse engineered code and it didn't have any copyrighted assets. It required you to have original game data similarly to OpenRW. RE3 got in trouble, because even though it didn't have any copyrighted assets, it still contained the reverse engineered code from the original executable which itself is copyrighted. Reverse engineering is kind of a gray legal area, so after getting the project taken down the creators of RE3 managed to appeal from the first DMCA and got the repository back online for a short period of time, but then Take Two filed a second DMCA that the creators of RE3 didn't manage to appeal from and the project got taken down again. They've never managed to get the project back online, so the original repository is unavailable to this day

@@zonea4860 Oh wow, didn't know this! Thanks for sharing ZoneA

Glad it was helpful!

👀wow didn't expect you guys to notice so quick

Wakey Wakey, You are now listening to RISE !

Nice, Goodluck brother ✌️

If the EULA says you can't then you're in breach of contract by doing so. So yes, it's illegal and yes, you can get sued over it. Big time.

@@toddwasson3355 The EULA never trumps the law. Not even in the United States. And I'm pretty sure almost every EULA says you can't reverse engineer the product. Most reverse engineering lawsuits claim that one or more people involved in the project has looked at the original code. Most companies want this gray area since they use it themselves.

I do vehicle simulation too and don't bother with quaternions either. I always end up needing the matrices for something (up/right/forward vectors are useful for lots of stuff) so both end up being there. I found it easier just to ditch the quaternions rather than fumbling back and forth between the two. Quats can't be visualized in any sense at all anyway so being creative with rotations and stuff gets hard in a hurry. Back in the old days quaternions could gain you some speed which I think is why so many folks were using them. Nowadays it hardly matters. If I'm not mistaken, GPUs have hardware accelerated matrix ops anyway so they're pretty hard to beat.

@@toddwasson3355 thank you for confirming. Matrices seem better for this case, in the middle of integrating them from ground up, so my implementation is process dependent (doesn't matter if its CPU or GPU, the math is plain algebra in my case, but based on the initial efforts of Gottfried Wilhelm Leibniz) I'm integrating everything from ground up to be as reliable as the original concept. Vehicle physics is a great topic in general and I'm highly interested in all of it.

@@raveltammeleht6278 Yeah, I think quats are overrated personally. Besides, if you're doing rendering you'll have shaders that look something like this anyway: VS_GBuffer_Out VSMain(VS_GBuffer_In input) { VS_GBuffer_Out output; float4x4 vp = mul(cbCamera.view, cbCamera.projection); float4x4 mvp = mul(cbTransform.model, vp); output.pos = mul(float4(input.pos, 1.0f), mvp); } That's a simple vertex shader. The view, model and projections are all matrices (float4x4 is 4x4 matrix of floats). That mul() function is built into hlsl shader language (glsl has an equivalent too) so you'll see it everywhere. Pretty sure there's dedicated hardware for that on the GPU, so when it comes time to render your car or whatever else, you'll probably want the matrix anyway. I figure just skip the expensive converting back and forth. You could write your own shader that uses quats instead if you really wanted to I suppose, but there's not much point these days, I think. We're not compute bound nowadays. Hi performance comes much more from good caching and clever memory use than cutting out a few arithmetic ops.

Great point, yea I need to find a way to keep the Vertex & Index buffers on the GPU, and just dynamically update the model matrices and some other minor things, rather than re-computing all instructions which I'm doing now, (including getting the Geometry ptr at every frame, and drawing it with the respective model matrix). I still need to look more into it, but you're totally right I feel like that would be much more efficient and less CPU bound like it is now... Thanks again Todd for your input bro!!

@@jason_m2003 Yeah, recomputing and reuploading the vertex and index buffers every frame will be hugely expensive. That might explain why you're CPU limited. You're probably barely using the GPU at all right now. OpenGL has had vertex buffer objects (VBOs) forever so if you're not using those, I'd look into it. Probably there's the same for index buffers. At the hardware level (DirectX12 and Vulkan) there are three different types of heaps for buffers (think of it as three different buffer types, in a sense): The first is "upload" which is a buffer that gets uploaded every frame. That's shared between CPU and GPU. That's the slowest and easiest way, but it's way faster than calling glVertex3f and so on zillions of times or transforming the vertices C++ side one at a time. The second is a "default" buffer which lives entirely on the GPU. To get data into that (in DirectX12 anyway) you first create an upload buffer and a default buffer. Then you write your C++ side std::vector or whatever you have into that upload buffer, then you copy that to the default buffer. Then it lives totally on the GPU and is so stupidly fast you won't believe it, as long as you don't do it every frame. (Not relevant here, but the third type is a "readback" buffer which you can write to in a shader and get the results back on the CPU.) Here's an early test I did a couple years ago when starting out in DX12. This is 134 million triangles on an NVidia 1080. Not a typo... ukposts.info/have/v-deo/rYFhiKVooG6EwJc.html&ab_channel=ToddWasson No chunking or culling or anything at all there. Each little "point" is a triangle. That's running with vertex and index both in default buffers using a single draw call for everything. No textures or lighting or anything, just colored triangles. So yeah, in OpenGL I'd look into VBOs (and maybe IBOs if that's what they're called), then also see if there's modes you can set like upload or default. You might have to write to upload and then copy to default like DX12 or something like that, but maybe OpenGL has some mode you can set which will do it for you. Your frame rate will blast off to the moon like you can't imagine.

Don't worry it's a valid point ! There is some nuance involved here, as OpenGL is inherently stateful and requires very careful manipulation of it's context, and how artifacts like VAOs, VBOs, Texutres, etc... are handled for correct rendering, so the OpenRW project provided a good pipeline (Involving API specific steps done at specific stages) to ensure a clean and orderly Object Hierarchy and pipeline, Yes you're correct in thinking that there shall be a "Global Interface", and Yes my new design still does the good old levels of abstractions and interfaces just like everyone else, but certain design aspects, and application specific tweaks where learnt from RW !