Raydium 3D Game Engine

About camera bug, I think we need to unify all camera function to use the same internal functions.

Again, I can't see any bug here ... Why are you centering the mouse by yourself here ? It's raydium_camera_freemove's job, you're just interfering with the function here.

hmm ... "Why are you centering the mouse by yourself here ?" ... sorry Xfennec, when you don't see bug you newer tried this ... problem is in mouse x,y distance from center, your freelook camera move cursor to the center of viewport but camera rotation isn't calculated by this mouse centering, because camera rotation is applied direct after raydium_mouse_button_pressed(1), and scene is changed too. Function raydium_camera_freemove centering mouse again, but is late, becaus scene is changed. That's all. Exist solution but this is workaround.

_________________
[HW] C2D Q6600, 4GB RAM, NV8800GTX, Vista Ultimate x64
[SW] Blide Plus, BlitzMax, Delphi, C++
[3D] Leadwerks 2.1, C4, TGE 1.5.2, Beyond Virtual

AndyFX, it starts to become very irritating. All I see is you, shouting at bugs everywhere in the forum, but I can't even understand your posts !

It's very kind from you to report bugs, no trouble with that, but, please, do report it correctly ! It's currently not the case, at least for me.

Let me demonstrate you what I mean, using this current thread as an example (but it's almost always the case with you):

You create a new thread (this one), starting with "New BUG". Then comes a bunch of code, with only 3 lines of Raydium related code. In this code, you move the mouse yourself before calling camera_freemove, which make no sense to me (and you don't explain why you do this)
But as I try keep Raydium as bug-free as I can (and it takes me a lot of time), I decide to try to reproduce the "bug".

So I created this file. It the very basic skel.c, where I added exactly your 3 lines (what else can I do, you don't explain anything about these 3 lines ?). And guess what, it works as it should be.

Then (because I'm very invested in Raydium, did I already said it ?), I tried to read your post a second time. A third one, ... and something randomly comes into my mind: Perhaps it has something to do with FREEMOVE_NORMAL and FREEMOVE_FIXED switchs ? (that would explain why your code shows a call to fixed camera, after all) and come with this second demo. And guess what ? works again.

Then comes your second post, with a new bunch of code, showing a "press" variable that comes from nowhere, and where you become a bit too much aggressive to me, and where you talk about things that your code does not even shows.

The end, 40 wasted minutes.

So, it's then very simple: when you detect a bug, create the smallest possible compilable demo that shows it, and take your time to explain the bug in a understandable way. I'm not some sort of "working for free" monkey you can shout at it to correct bugs.

Sorry, i know that my english isn't good, but i talk about bug in behaviour, not about code. Try press mouse button again and again on other place in viewport, camera CHANGE direction view after everyone mouse event. Question is WHY, when you have in code mouse centering too. From my point of view, becuase global mouse x and y variables are changed too.

_________________
[HW] C2D Q6600, 4GB RAM, NV8800GTX, Vista Ultimate x64
[SW] Blide Plus, BlitzMax, Delphi, C++
[3D] Leadwerks 2.1, C4, TGE 1.5.2, Beyond Virtual

This is another example: everyone mouse event = every mouse event ? If yes, you see, it's not a matter of correct english or not (mine's terrible too !) but a matter of taking your time to properly report things.

So let's make it the correct way: I'm currently in front of my computer screen. Which application I should launch and what I'm supposed to do, and what I'm supposed to see ?

Wow wow... Relax please
I will intermediate here.

AndyGFX has more or less problems communicating in english language, and so the "tone" of his messages is a bit "imperative/mandatory".
Reading his posts I guessed that eventually Xfennec (as you are the one-who-respond) will get angry with this.
But it's not really the meaning of him. Even this morning he told me to check its response here(to make it more "polite"), but I was busy and finally he publish it "as is"... with this result.

He is creating a car game, using Raydium, and the project is well focus. So he is finding bugs, almost-bugs and "strange behaviours" in Raydium. I have to say that he has a lot of years old (the raydium grandfather ), a lot of years coding, and he has tested a lot of free and commercial game engines. So a few raydium concepts collide with its experience and he "see" a bug.

Maybe he could have explain all this here before , but again the communication problem... Anyway he has told me all this in chat ( he writes quite better chatting) and so I have the duty of explain all this here.

The point here is that he is working with raydium, he is finding "problems" and sometims i'm not able to solve them, so I redirect him to the forum, and finally Xfennec gets angry
I have speak with him to search a better way of doing this with all people as much happy as possible. Looks like the better option right now is that I go to create a bug notification system for raydium (in my server, so Xfennec gets no extra job). But still deciding...

I'm not angry, I'm frustrated I try to do my best to provide a good support for the engine, and it's very hard to deal, at the same time, with very few free time (as all of us) and scrambled bug reports.

I must apologize to AndyFX for my previous post (6400), there was no need for being so rude with you.

Thanks a lot for this words from Vicente, and I apologize to you Xfennec, sorry for my words, i know how hard is make support, when making engine isn't as your full-time job, i must write about raydium, that is first OGL rendering engine with working physiscs on linux, mac and windows too, without problems.

Back to my problem, described above.

@Xfennec:

1) raydium_camera_freemove(RAYDIUM_CAMERA_FREEMOVE_NORMAL);
- works very well

2) raydium_camera_freemove(RAYDIUM_CAMERA_FREEMOVE_FIXED);
- work fine too

3) raydium_mouse_button_pressed(0)
- is without bugs too

- all this functions working properly, if they are used the normaly. Problem begin, when i need use freemove camera only when right mouse buton is pressed. (like in other 3d modellers or game editors).

Logicaly I'm wrote this lines:



but result was, that camera alway jump to other look direction and don't continue from last view direction (after mouse button up), because on mouse down event, is mouse position writed to global variables like raydium_mouse_x and raydium_mouse_y, then raydium freelook function calculate camera angles as delta X,Y from this global variables, and this is issue. From my point of, is better for freelook camera used separate mouse X,Y variables for store and calculate look direction as raydium_mouse_x and raydium_mouse_y, which are uset to on a lot of others raydium functions.

Note: This strange behavour is better visible, when mouse isn't hiden.

Here is modified code to fix this my problem:

_________________
[HW] C2D Q6600, 4GB RAM, NV8800GTX, Vista Ultimate x64
[SW] Blide Plus, BlitzMax, Delphi, C++
[3D] Leadwerks 2.1, C4, TGE 1.5.2, Beyond Virtual

Hello,

Now it's clear !

Camera_free_move need to be improved for sure.

Camera parameter need to be global, and can must be continous from different camera functions.

First call with RAYDIUM_CAMERA_FREEMOVE_NORMAL need to be handle specificaly.

I'll have a look at the second point this week ! Promise.

Have a nice day
Ouille.

Yep, I now understand ! And it's a very pleasant feeling

Two way to fix this:
1 - as ouille said, handle 1st call to FREEMOVE_NORMAL in a different way (but only when you "come" from another FREEMOVE camera and not another camera)
2 - provide a new function, like raydium_mouse_center(), that moves the mouse but also update raydium_mouse_* variables. It allows the user to chose his behavior (perhaps some people wants that "jumping" view) and does not break compatibility with raydium_mouse_move().

AndyFX, you can probably simplify a bit your code using "raydium_mouse_click" (instead of your "press" variable):


PS: all 3 "TAGged" lines can be replaced by "raydium_mouse_center()" candidate function.

Point 2 looks more useful

_________________
[HW] C2D Q6600, 4GB RAM, NV8800GTX, Vista Ultimate x64
[SW] Blide Plus, BlitzMax, Delphi, C++
[3D] Leadwerks 2.1, C4, TGE 1.5.2, Beyond Virtual

Hello,

I think it's a real bug:

If windows size is not even, point of veiw slide slowly as mouse seem's to be offcenter at least for some fractionnal part.

We need to add a "dead zone" of one pixel to avoid this.

It only appear after resizing the windows.

Have a nice day
Ouille

I want to unify all camera functions to use the same globals and internal functions.
So should I unify'em after or before fixing this bug?

Hello,

No problem.

Secondly perhaps we need that camera freemove is continuous with other camera place and look functions.

I.E.: Position and orientation of camera used by a camera place and look at is kept when enterring in a freemove placement.

It's a good idea to unify all of this.

Have a nice day
Ouille.
P.S.: be carrefull of indent