PiBoSo Official Forum

GP Bikes => Bug Reports => Topic started by: yoshimura on October 02, 2014, 07:29:38 AM

Title: code error openGL
Post by: yoshimura on October 02, 2014, 07:29:38 AM
hello, I had many, error code on the slopes, collision object.thanks

(http://img4.hostingpics.net/pics/216547Capturegggg.jpg)
Title: Re: code error openGL
Post by: HornetMaX on October 02, 2014, 02:55:40 PM
It's not an openGL error, it's an ODE error.

It just happens, origin is unknown.

MaX.
Title: Re: code error openGL
Post by: yoshimura on October 02, 2014, 03:45:52 PM
It is an error code under open source Linux (mandriva)often, openGL, which causes memory leak, collision object, only piboso knows the problem.
Title: Re: code error openGL
Post by: HornetMaX on October 02, 2014, 06:32:15 PM
Actually he doesn't know the problem, otherwise it would be solved (this thing has been there a long time).

The error comes from ODE (Open Dynamics Engine), no relationship with openGL. What causes the error is not known.

Not sure why you mention Linux/mandriva ?! Again, the error comes from O.D.E. ....

MaX.
Title: Re: code error openGL
Post by: yoshimura on October 02, 2014, 07:11:37 PM
you speak in place of piboso? address I m has piboso this simulation are fantastic, good luck to you to solve this problem, which gives me great pleasure every day. ;)piboso, give me oats, to make me less stupid ;D
Title: Re: code error openGL
Post by: HornetMaX on October 02, 2014, 07:57:56 PM
Quote from: yoshimura on October 02, 2014, 07:11:37 PM
you speak in place of piboso?
On things that are known, yes. But feel free to wait for his answer.

MaX.

P.S.
On y comprends rien a ton anglais, t'as interet a poser tes questions en francais sur motonline.fr et demander a quelqu'un de te traduire si besoin.
Title: Re: code error openGL
Post by: WALKEN on October 02, 2014, 08:26:24 PM
Are you running the game in Linux? If so from source or in "wine" ?

-   http://forum.kartracing-pro.com/index.php?topic=989.15
Title: Re: code error openGL
Post by: yoshimura on October 03, 2014, 06:16:52 AM
Quote from: WALKEN on October 02, 2014, 08:26:24 PM
Are you running the game in Linux? If so from source or in "wine" ?

-   http://forum.kartracing-pro.com/index.php?topic=989.15

hello,

No,not linux,i am on windows 8.1,I look for the link ;)
Title: Re: code error openGL
Post by: matty0l215 on October 03, 2014, 08:18:15 AM
I've had this error a few times and I could successfully reproduce it on the core.exe test track (Link (http://forum.piboso.com/index.php?topic=1318.0)) by hitting any of the joins in the walls.
Title: Re: code error openGL
Post by: yoshimura on October 03, 2014, 08:45:56 AM
Quote from: matty0l215 on October 03, 2014, 08:18:15 AM
I've had this error a few times and I could successfully reproduce it on the core.exe test track (Link (http://forum.piboso.com/index.php?topic=1318.0)) by hitting any of the joins in the walls.

The problem is similar, frozen screen, problem collision object, random, very annoying.
Title: Re: code error openGL
Post by: matty0l215 on October 03, 2014, 09:11:54 AM
Quote from: yoshimura on October 03, 2014, 08:45:56 AM
The problem is similar, frozen screen, problem collision object, random, very annoying.

What track/tracks are you using?
Title: Re: code error openGL
Post by: yoshimura on October 03, 2014, 09:21:17 AM
Problem with, Monza bike v3, NC-Mugello, during replay also.
Title: Re: code error openGL
Post by: HornetMaX on October 03, 2014, 09:32:53 AM
ODE needs to normalize vectors to do his computations. Whenever he cannot do so (because the vector is ill-defined, e.g. has zero norm) he raises this exception producing the crash.

Now why a vector could be ill-defined ? No way we could now for sure. It could come from the track (wrong normal to a surface ?) or from a bug in the physics or collision detection or from god knows what.

The sure things are:


@matty: if you can reproduce it at will, maybe piboso can have a look.

MaX.
Title: Re: code error openGL
Post by: yoshimura on October 03, 2014, 10:13:39 AM
Each vector needs a code to operate correctly.....
Title: Re: code error openGL
Post by: HornetMaX on October 03, 2014, 10:18:57 AM
Quote from: yoshimura on October 03, 2014, 10:13:39 AM
Each vector needs a code to operate correctly.....

??  :o

MaX.
Title: Re: code error openGL
Post by: matty0l215 on October 03, 2014, 12:18:12 PM
Quote from: HornetMaX on October 03, 2014, 09:32:53 AM

@matty: if you can reproduce it at will, maybe piboso can have a look.

Hit any of the joins in the wall, its easier to ode core when the bike is moving (like when the bike wobbles mid lean), but saying that i don't think i've ever had just a plain core.exe offline and there were never many people online when testing so i can't remember weather i could get it to core.exe online
Title: Re: code error openGL
Post by: matty0l215 on October 03, 2014, 12:40:11 PM
Just tried it again online

Doesn't even need to be right in the corner. As long as it's near.

(http://i.imgur.com/ItQaC8l.jpg)

Not a great picture, but the corner is just out of shot on the left and this is where it crashed, I can do it on most corners, it's more difficult on shallower corners ( 90 degrees and below is easier)

Edit, its not the corners, its the join/gap between edges.
(http://i.imgur.com/dVynixT.jpg)
Again sorry for the potato picture, but look how the bikes rear wheel is off the floor and when i hit, the bike jumped as the front wheel went through the gap, the whole front wheel has gone through
Title: Re: code error openGL
Post by: Hawk on October 03, 2014, 01:44:15 PM
If it's gaps causing these core crashes(which in part I believe it is), then surely that is a problem due to the methods and modelling procedures of track authors, not GPB?
I honestly believe this is part of the problem but not a solution to the whole core crash problems. But it would help if track authors made sure the tracks were clean of any artifacts before they were released, especially with regards to ripped tracks, as it is these ripped tracks that in my opinion are the cause of a vast majority of core crashes(the positive is: they seem to be getting better as updates are released). :)

But I also believe that the work required to go through a ripped track to make sure it is clean, the author would be better using that considerable time to create the same track from scratch.

So with ripped tracks: If the tracks were made NDS and the tracks were properly cleaned up after ripping, then I think the vast majority of core.exe crashes would cease?

The only track Piboso can rely on for his testing of GPB is the default track that came with GPB, namely Victoria, as this track I'm presuming he created cleanly using his own track making rules, which I also presume he understands completely. This is why I presume he is seemingly not taking much notice or making any response to tests we make with tracks created by anyone else, or even tests made on tracks created by others as it would simply be too time consuming to have to check everything on a track to make sure that every track making rule was followed correctly on top of having to check all the 3D models of the track to make sure they were complete without any errors.
If we could trust that GPB wasn't causing the core.exe problems(which I guess we will be able to in the future?), then we could easily sort out the good tracks from the bad. But in conclusion, my opinion is that it is the ill prepared ripped tracks that are the cause of the vast majority of core.exe issues with GPB at this time.

These are just my thoughts on this subject and by no means a statement for a complete solution to this on-going problem as I also think there are other issues that are probably contributing to the core.exe crash problem too, ie: the memory leak problem which I believe Piboso is already aware of.


Hawk.
Title: Re: code error openGL
Post by: matty0l215 on October 03, 2014, 04:13:37 PM
Quote from: Hawk_UK on October 03, 2014, 01:44:15 PM
If it's gaps causing these core crashes(which in part I believe it is), then surely that is a problem due to the methods and modelling procedures of track authors, not GPB?
I honestly believe this is part of the problem but not a solution to the whole core crash problems. But it would help if track authors made sure the tracks were clean of any artifacts before they were released, especially with regards to ripped tracks, as it is these ripped tracks that in my opinion are the cause of a vast majority of core crashes(the positive is: they seem to be getting better as updates are released). :)

But I also believe that the work required to go through a ripped track to make sure it is clean, the author would be better using that considerable time to create the same track from scratch.

So with ripped tracks: If the tracks were made NDS and the tracks were properly cleaned up after ripping, then I think the vast majority of core.exe crashes would cease?

The only track Piboso can rely on for his testing of GPB is the default track that came with GPB, namely Victoria, as this track I'm presuming he created cleanly using his own track making rules, which I also presume he understands completely. This is why I presume he is seemingly not taking much notice or making any response to tests we make with tracks created by anyone else, or even tests made on tracks created by others as it would simply be too time consuming to have to check everything on a track to make sure that every track making rule was followed correctly on top of having to check all the 3D models of the track to make sure they were complete without any errors.
If we could trust that GPB wasn't causing the core.exe problems(which I guess we will be able to in the future?), then we could easily sort out the good tracks from the bad. But in conclusion, my opinion is that it is the ill prepared ripped tracks that are the cause the vast majority of core.exe issues with GPB at this time.

These are just my thoughts on this subject and by no means a statement for a complete solution to this on-going problem as I also think there are other issues that are probably contributing to the core.exe crash problem too, ie: the memory leak problem which I believe Piboso is already aware of.


Hawk.

well yes and no, it would stop the ODE cores, but it might not stop the plain core.exe

I found out yesterday that KRP tracks work in GP bikes but i had no end of ODE cores (nearly every time i left the track in some cases) so I stopped using them but does KRP suffer from cores?? and if no, what is different that stops them from hapening.
Title: Re: code error openGL
Post by: HornetMaX on October 03, 2014, 08:47:39 PM
Quote from: matty0l215 on October 03, 2014, 04:13:37 PM
well yes and no, it would stop the ODE cores, but it might not stop the plain core.exe
Exact. Personally, in the few cores I used to have, I had more crashes due to something else than due to the ODE normalization error.

Quote from: matty0l215 on October 03, 2014, 04:13:37 PM
I found out yesterday that KRP tracks work in GP bikes but i had no end of ODE cores (nearly every time i left the track in some cases) so I stopped using them but does KRP suffer from cores?? and if no, what is different that stops them from hapening.
That's interesting, very interesting. But only Piboso can have a look.

MaX.
Title: Re: code error openGL
Post by: matty0l215 on October 03, 2014, 09:38:09 PM
Quote from: HornetMaX on October 03, 2014, 08:47:39 PM
Quote from: matty0l215 on October 03, 2014, 04:13:37 PM
well yes and no, it would stop the ODE cores, but it might not stop the plain core.exe
Exact. Personally, in the few cores I used to have, I had more crashes due to something else than due to the ODE normalization error.

Quote from: matty0l215 on October 03, 2014, 04:13:37 PM
I found out yesterday that KRP tracks work in GP bikes but i had no end of ODE cores (nearly every time i left the track in some cases) so I stopped using them but does KRP suffer from cores?? and if no, what is different that stops them from hapening.
That's interesting, very interesting. But only Piboso can have a look.

MaX.

Also, if you put a GP bikes track into MX bikes, it throws a ODE Error as soon as you go to track
Title: Re: code error openGL
Post by: RBp on October 05, 2014, 09:25:15 AM
ODE is the physic engine used.
Title: Re: code error openGL
Post by: Hawk on October 05, 2014, 11:05:18 AM
Quote from: matty0l215 on October 03, 2014, 04:13:37 PM
Quote from: Hawk_UK on October 03, 2014, 01:44:15 PM
If it's gaps causing these core crashes(which in part I believe it is), then surely that is a problem due to the methods and modelling procedures of track authors, not GPB?
I honestly believe this is part of the problem but not a solution to the whole core crash problems. But it would help if track authors made sure the tracks were clean of any artifacts before they were released, especially with regards to ripped tracks, as it is these ripped tracks that in my opinion are the cause of a vast majority of core crashes(the positive is: they seem to be getting better as updates are released). :)

But I also believe that the work required to go through a ripped track to make sure it is clean, the author would be better using that considerable time to create the same track from scratch.

So with ripped tracks: If the tracks were made NDS and the tracks were properly cleaned up after ripping, then I think the vast majority of core.exe crashes would cease?

The only track Piboso can rely on for his testing of GPB is the default track that came with GPB, namely Victoria, as this track I'm presuming he created cleanly using his own track making rules, which I also presume he understands completely. This is why I presume he is seemingly not taking much notice or making any response to tests we make with tracks created by anyone else, or even tests made on tracks created by others as it would simply be too time consuming to have to check everything on a track to make sure that every track making rule was followed correctly on top of having to check all the 3D models of the track to make sure they were complete without any errors.
If we could trust that GPB wasn't causing the core.exe problems(which I guess we will be able to in the future?), then we could easily sort out the good tracks from the bad. But in conclusion, my opinion is that it is the ill prepared ripped tracks that are the cause the vast majority of core.exe issues with GPB at this time.

These are just my thoughts on this subject and by no means a statement for a complete solution to this on-going problem as I also think there are other issues that are probably contributing to the core.exe crash problem too, ie: the memory leak problem which I believe Piboso is already aware of.


Hawk.

well yes and no, it would stop the ODE cores, but it might not stop the plain core.exe

Very rare my above statements cause a ODE crash, they mainly do certainly cause core.exe crashes, of which I can reproduce at will.  ;)

The reality is that none of us know what is the root cause of these problems. We are certainly only seeing the symptoms of some issue that is causing the crashes, be they ODE or Core.exe. I presume this is why Piboso is talking about designing special debug tools to finally nail down the issue?  :)


Hawk.
Title: Re: code error openGL
Post by: matty0l215 on October 05, 2014, 02:12:39 PM
Quote from: Hawk_UK on October 05, 2014, 11:05:18 AM
Very rare my above statements cause a ODE crash, they mainly do certainly cause core.exe crashes, of which I can reproduce at will.  ;)

The reality is that none of us know what is the root cause of these problems. We are certainly only seeing the symptoms of some issue that is causing the crashes, be they ODE or Core.exe. I presume this is why Piboso is talking about designing special debug tools to finally nail down the issue?  :)


Hawk.
Why only have the dev team working on finding the cause when you could have the whole player base helping. Sounds good to me  :)
Title: Re: code error openGL
Post by: HornetMaX on October 05, 2014, 04:28:43 PM
Quote from: matty0l215 on October 05, 2014, 02:12:39 PM
Why only have the dev team working on finding the cause when you could have the whole player base helping. Sounds good to me  :)
Because some bugs, users cannot provide any help apart from reporting them.

MaX.
Title: Re: code error openGL
Post by: yoshimura on October 05, 2014, 04:37:24 PM
Quote from: HornetMaX on October 05, 2014, 04:28:43 PM
Quote from: matty0l215 on October 05, 2014, 02:12:39 PM
Why only have the dev team working on finding the cause when you could have the whole player base helping. Sounds good to me  :)
Because some bugs, users cannot provide any help apart from reporting them.

MaX.


why not include a log / file errors, to provide support for piboso?as in any program.
Title: Re: code error openGL
Post by: HornetMaX on October 05, 2014, 04:52:55 PM
Quote from: yoshimura on October 05, 2014, 04:37:24 PM
Quote from: HornetMaX on October 05, 2014, 04:28:43 PM
Quote from: matty0l215 on October 05, 2014, 02:12:39 PM
Why only have the dev team working on finding the cause when you could have the whole player base helping. Sounds good to me  :)
Because some bugs, users cannot provide any help apart from reporting them.

MaX.


why not include a log / file errors, to provide support for piboso?as in any program.

Which log file error ? The standard windows one ? That's basically useless.

If we want a meaningful log file, Pibos has to add some debug/logging code to GPB. Hence we cannot help.

MaX.
Title: Re: code error openGL
Post by: matty0l215 on October 05, 2014, 04:57:37 PM
Quote from: HornetMaX on October 05, 2014, 04:28:43 PM
Quote from: matty0l215 on October 05, 2014, 02:12:39 PM
Why only have the dev team working on finding the cause when you could have the whole player base helping. Sounds good to me  :)
Because some bugs, users cannot provide any help apart from reporting them.

MaX.
Fair enough. Don't want to start that argument again  :P