You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(39) |
Nov
(277) |
Dec
(299) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(261) |
Feb
(162) |
Mar
(70) |
Apr
(141) |
May
(55) |
Jun
(166) |
Jul
(202) |
Aug
(122) |
Sep
(368) |
Oct
(290) |
Nov
(232) |
Dec
(516) |
2010 |
Jan
(302) |
Feb
(253) |
Mar
(253) |
Apr
(184) |
May
(184) |
Jun
(82) |
Jul
(62) |
Aug
(154) |
Sep
(331) |
Oct
(450) |
Nov
(312) |
Dec
(249) |
2011 |
Jan
(252) |
Feb
(286) |
Mar
(175) |
Apr
(175) |
May
(194) |
Jun
(130) |
Jul
(211) |
Aug
(340) |
Sep
(150) |
Oct
(398) |
Nov
(572) |
Dec
(199) |
2012 |
Jan
(458) |
Feb
(378) |
Mar
(332) |
Apr
(385) |
May
(228) |
Jun
(188) |
Jul
(199) |
Aug
(336) |
Sep
(349) |
Oct
(271) |
Nov
(61) |
Dec
(155) |
2013 |
Jan
(230) |
Feb
(302) |
Mar
(350) |
Apr
(162) |
May
(118) |
Jun
(209) |
Jul
(75) |
Aug
(94) |
Sep
(32) |
Oct
(92) |
Nov
(276) |
Dec
(84) |
2014 |
Jan
(36) |
Feb
(50) |
Mar
(16) |
Apr
(32) |
May
(61) |
Jun
(233) |
Jul
(37) |
Aug
(13) |
Sep
(23) |
Oct
(38) |
Nov
(52) |
Dec
(34) |
2015 |
Jan
(9) |
Feb
(18) |
Mar
(148) |
Apr
(78) |
May
(15) |
Jun
(31) |
Jul
(60) |
Aug
(90) |
Sep
(41) |
Oct
(38) |
Nov
(177) |
Dec
(76) |
2016 |
Jan
(53) |
Feb
(41) |
Mar
(26) |
Apr
(25) |
May
(34) |
Jun
(44) |
Jul
(22) |
Aug
(1) |
Sep
(15) |
Oct
(18) |
Nov
(1) |
Dec
(16) |
2017 |
Jan
(29) |
Feb
(20) |
Mar
(5) |
Apr
(8) |
May
(6) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
(25) |
Mar
(7) |
Apr
(2) |
May
(4) |
Jun
(9) |
Jul
|
Aug
(17) |
Sep
(6) |
Oct
(8) |
Nov
(7) |
Dec
(19) |
2019 |
Jan
(2) |
Feb
(31) |
Mar
(10) |
Apr
(1) |
May
(4) |
Jun
(3) |
Jul
(13) |
Aug
(5) |
Sep
|
Oct
(4) |
Nov
(164) |
Dec
(59) |
2020 |
Jan
(16) |
Feb
(20) |
Mar
(124) |
Apr
(236) |
May
(128) |
Jun
(31) |
Jul
(54) |
Aug
(34) |
Sep
|
Oct
(6) |
Nov
(30) |
Dec
(28) |
2021 |
Jan
(18) |
Feb
(6) |
Mar
(4) |
Apr
(44) |
May
(61) |
Jun
(178) |
Jul
(49) |
Aug
(44) |
Sep
(104) |
Oct
(75) |
Nov
(56) |
Dec
(61) |
2022 |
Jan
(177) |
Feb
(111) |
Mar
(36) |
Apr
(17) |
May
(10) |
Jun
(24) |
Jul
(17) |
Aug
(81) |
Sep
(19) |
Oct
(51) |
Nov
(36) |
Dec
(20) |
2023 |
Jan
(41) |
Feb
(37) |
Mar
(37) |
Apr
(19) |
May
(15) |
Jun
(7) |
Jul
(38) |
Aug
(8) |
Sep
(12) |
Oct
(2) |
Nov
(4) |
Dec
(45) |
2024 |
Jan
(11) |
Feb
(22) |
Mar
(160) |
Apr
(30) |
May
(40) |
Jun
(6) |
Jul
(84) |
Aug
(18) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Kristóf Kály-K. <ka...@gm...> - 2010-05-02 14:49:14
|
Hello, I think Xavier is right, that it is good to have this for development, but for release it is better to have "real randomness", that is initialize the RNG with the time or whatever else non-predictable value. Kristof |
From: Kristóf Kály-K. <ka...@gm...> - 2010-05-02 14:47:01
|
Hi W-D and all, I will add the memory copy issue to my list, it is worth at least for a serious look. Kristof |
From: Kristóf Kály-K. <ka...@gm...> - 2010-05-02 14:43:32
|
Hello to everyone, I suggest to decide on simuv3 in the next meeting, in 3 weeks time we will probably also have a better idea how much work we need to achieve it and how much more CPU it needs. I will start looking into it and try to figure out what it does. Kristof |
From: <ba...@ne...> - 2010-05-02 14:39:31
|
Hi Xavier, i renamed Michigan Speedway to Manton Speedway of copyright issues. Michigan Speedway is a real track and real track name. Zitat von Bertaux Xavier <ber...@ya...>: > Eckhard, > > why have you renamed michigan to manton, Michigan was not good ? > > Cheers > Xavier > > > ------------------------------------------------------------------------------ > _______________________________________________ > Speed-dreams-devel mailing list > Spe...@li... > https://lists.sourceforge.net/lists/listinfo/speed-dreams-devel > |
From: <ba...@ne...> - 2010-05-02 14:36:52
|
Hi all, i checked in my last beauty, the reworked Michigan Speedway, now called Manton Speedway. I created/ improved a lot of new textures for it, added some more trees and fixed a lot of texture bugs (that was tricky). I updated the cmake file at the track and track category directory too. The XML is based of latest XML of the SVN and includes the weather conditions. Please Xavier could you do me the favor again and delete the old michigan directory. Thousend thanks! I hope the next version of Rabbit will work correct about deletion and renaming files. Any feedback is welcome! Cheers Eckhard. PS: This is my actual state about tracks. I have some progress about Spring but its far from being done. |
From: Bertaux X. <ber...@ya...> - 2010-05-02 14:27:06
|
Eckhard, why have you renamed michigan to manton, Michigan was not good ? Cheers Xavier |
From: Bertaux X. <ber...@ya...> - 2010-05-02 13:27:29
|
Hi Wolf-Dieter, Andrew and Kilo, I have added allondaz and charmey in yours scr/drivers. I have just renamed old name by new name and commited. Old setup for olders tracks (alpine-1 and g-track-3) have not deleted for the moment. Cheers Xavier |
From: Jean-Philippe <jpm...@fr...> - 2010-05-02 12:56:56
|
Hi, everyone. > sure, new features mean more CPU time is consumed. > > The robot code is called from the race engine. > > First the new situation is calculated (calling simuVx for all cars) and then > the robots are called to get the new driving commands. > > The calculations of the robots are independent from each other. So it should > be very easy to do it parallel. > > The calculations of the simulation regarding the single cars are not > completely independent, the issues are the possible collisions. As long as > there is no collision between cars, the calculations should be independent > too. > > AFAICS the code in the simuVx is the independent part of the simulation. So > it should be possible to do it parallel as well. > > @Mart: Do you know out of the box where the robot code is called? I wrote some first glance analysis here : http://sourceforge.net/apps/trac/speed-dreams/wiki/PreparingMultithreading Cheers, Jean-Philippe. |
From: Speed D. <no...@so...> - 2010-05-02 12:48:46
|
#123: The player car changes when editing the player name with arrow keys -----------------------------+---------------------------------------------- Reporter: pouillot | Owner: pouillot Type: defect | Status: closed Priority: minor | Milestone: 1.4.1 Component: User interface | Version: 1.4.0 Resolution: fixed | Keywords: player configuration keyboard -----------------------------+---------------------------------------------- Changes (by pouillot): * status: new => closed * resolution: => fixed Comment: Fixed in r2403. Simply changed the key bindings in the player config menu : - Change car : Up and Down arrow keys, - Change car category : PageUp and PageDown keys. Note: Key bindings are defined at the screen=menu level, not the control one, which explains. -- Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/123#comment:2> Speed Dreams <http://sourceforge.net/projects/speed-dreams> An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism. |
From: Speed D. <no...@so...> - 2010-05-02 12:37:27
|
#122: Can't use 2 (or more) keys at the same time -----------------------------+---------------------------------------------- Reporter: pouillot | Owner: pouillot Type: defect | Status: closed Priority: major | Milestone: 2.0.0 Component: User interface | Version: 2.0.0-dev Resolution: fixed | Keywords: keyboard event loop SDL -----------------------------+---------------------------------------------- Changes (by pouillot): * status: new => closed * resolution: => fixed Comment: Fixed in r2402. * Fixed relevant event loop in sdlcallbacks.cpp (use a map to store unicode of pressed keys, in order to have it available when released, and no more a single variable !). Note: Currently no support for CapsLock and NumLock keys; TODO in the future, as the expected behaviour of Shift keys is then inverted if one of these keys are pressed an odd number of times. * Renamed sdlcallbacks.cpp to guieventloop.cpp and moved sdlcallbacks.h contents to tgfclient.h, for consistency with old code * Removed separation between normal keys (a, G, Space, ...) and special keys (ex: F1, Backspace) everywhere in the code (was a legacy from GLUT) Now we can work on improving keyboard steering ;-) -- Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/122#comment:1> Speed Dreams <http://sourceforge.net/projects/speed-dreams> An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism. |
From: Mart K. <ma...@ke...> - 2010-05-02 12:04:50
|
Hello Wolf-Dieter (and others), On Sunday 02 May 2010 13:48:36 you wrote: > Hello Xavier, > > sure, new features mean more CPU time is consumed. > > The robot code is called from the race engine. > > First the new situation is calculated (calling simuVx for all cars) and > then the robots are called to get the new driving commands. > > The calculations of the robots are independent from each other. So it > should be very easy to do it parallel. > > The calculations of the simulation regarding the single cars are not > completely independent, the issues are the possible collisions. As long as > there is no collision between cars, the calculations should be independent > too. > > AFAICS the code in the simuVx is the independent part of the simulation. So > it should be possible to do it parallel as well. > > @Mart: Do you know out of the box where the robot code is called? Yes: src/libs/raceengineclient/raceengine:861 > Cheers > > Wolf-Dieter Regards, Mart |
From: Christos D. <ole...@fa...> - 2010-05-02 11:55:36
|
> > Simu is called once by the raceengineclient. Then simu has some calls which > are specific for every car (and can be multithreaded, I think). And after that > there is collision detection. I did some performance checks on Speed Dreams > some time ago, and if I remember it correctly, the collision detection takes > quite a significant amount of time (simuv2). > Of course. If there are N cars, the collision detection takes O(N^2) time. However, we use the SOLID engine for collision detection, which I _think_ is quite efficient. In the worst case, the aerodynamics also takes O(N^2) time, due to the slipstreaming. However, if cars are far away from each other this is removed. The rest of the simulation takes O(N). The most intensive part in the rest of the simulation is the translation of various vectors (forces, velocities, etc) from / to various co-ordinate systems and projections to different planes and axes. There are at least one set of transforms done for each wheel, another for each suspension link, and another for the car. It is also possible that a lot of savings could be made by replacing the exponential function with approximations; however this may depend on the hardware. |
From: W.-D. B. <wd...@wd...> - 2010-05-02 11:48:59
|
Hello Xavier, sure, new features mean more CPU time is consumed. The robot code is called from the race engine. First the new situation is calculated (calling simuVx for all cars) and then the robots are called to get the new driving commands. The calculations of the robots are independent from each other. So it should be very easy to do it parallel. The calculations of the simulation regarding the single cars are not completely independent, the issues are the possible collisions. As long as there is no collision between cars, the calculations should be independent too. AFAICS the code in the simuVx is the independent part of the simulation. So it should be possible to do it parallel as well. @Mart: Do you know out of the box where the robot code is called? Cheers Wolf-Dieter -----Ursprüngliche Nachricht----- Von: Bertaux Xavier [mailto:ber...@ya...] Gesendet: 02 May 2010 13:30 An: W.-D. Beelitz Cc: 'Jean-Philippe'; Kristóf Kály-Kullai; Andrew Sumner; Mart Kelder; speed-dreams-devel Betreff: Re: [Speed-dreams-devel] Aero.cpp - towards simuv2.1 Le 02/05/2010 12:32, W.-D. Beelitz a écrit : > Hello all, > > >> Performance issues >> > Some weeks ago I got a new PC and had the chance to compare TORCS/SD on it > with the old one. > The CPU power is not changed a lot, but the graphic card. > > With the new system I can drive a lot more opponents in a race (in a release > version). > > So I assume that optimizations of the CPU usage will not be the great step. > The real chance is using multithreading (for robots) and avoid unneeded > copying of data. > > What I found while working with the robot code is, that there is a lot of > data being copied again and again every time step. The data provided in the > interfaces for the robots is sorted by the ranking while race! > The leading driver's data is placed in the array first, followed by the next > driver and if the leading changes the cars order in the array is changed as > well. I can't imagine why this is really needed. > > Using pointers to the data should decrease the work load a lot. > > Hi Wolf-Dieter, yes and no. Pass GLUT to SDL we have loose some fps. I think that Brian work on migrate OSG (OSG is multithread for graphic but not for other code) FlightGear has migrate there is 2 years now and one CPU is used for other code than OSG. My modification for sky take more fps too (it's why, I have put activate/desactivate ssgsky) But in SD, it's module Simu take more times (take 1000 times per seconds), so I think is a good idea to put simu or robot code in multhread. So just a question : simu is called by each cars on track or called for all cars. If it's called by each car, is good idea to do simu module in multithread (with one thread create by car) if not, so do robot module in multithread. But I don't know well simu module, so I don't answered at this question. Cheers Xavier |
From: Mart K. <ma...@ke...> - 2010-05-02 11:43:36
|
Hello Xavier (and others), On Sunday 02 May 2010 13:23:09 you wrote: > Hi Wolf-Dieter, > > yes and no. Pass GLUT to SDL we have loose some fps. > I think that Brian work on migrate OSG (OSG is multithread for graphic > but not for other code) > FlightGear has migrate there is 2 years now and one CPU is used for > other code than OSG. > > My modification for sky take more fps too (it's why, I have put > activate/desactivate ssgsky) > > But in SD, it's module Simu take more times (take 1000 times per > seconds), so I think is a good idea to put simu or robot code in > multhread. So just a question : simu is called by each cars on track or > called for all cars. > If it's called by each car, is good idea to do simu module in > multithread (with one thread create by car) if not, so do robot module > in multithread. But I don't know well simu module, so I don't answered > at this question. Simu is called once by the raceengineclient. Then simu has some calls which are specific for every car (and can be multithreaded, I think). And after that there is collision detection. I did some performance checks on Speed Dreams some time ago, and if I remember it correctly, the collision detection takes quite a significant amount of time (simuv2). > Cheers > > Xavier Regards, Mart |
From: Mart K. <ma...@ke...> - 2010-05-02 11:33:40
|
Hello Wolf-Dieter (and others), On Sunday 02 May 2010 12:32:23 W.-D. Beelitz wrote: > Hello all, > > > Performance issues > > Some weeks ago I got a new PC and had the chance to compare TORCS/SD on it > with the old one. > The CPU power is not changed a lot, but the graphic card. > > With the new system I can drive a lot more opponents in a race (in a > release version). > > So I assume that optimizations of the CPU usage will not be the great step. > The real chance is using multithreading (for robots) and avoid unneeded > copying of data. > > What I found while working with the robot code is, that there is a lot of > data being copied again and again every time step. The data provided in the > interfaces for the robots is sorted by the ranking while race! > The leading driver's data is placed in the array first, followed by the > next driver and if the leading changes the cars order in the array is > changed as well. I can't imagine why this is really needed. Is this true? I thought the data is only is copyed is someone is overtaken for position, which does occur much less then every timestep. If the robots are more interested in who drives before him on the track, we might also store pointers to the car in that position (I implemented that before to make blue and yellow flags easier). But I don't think we get much performance improvement through this. > Using pointers to the data should decrease the work load a lot. > > Cheers > > Wolf-Dieter Regards, Mart |
From: Bertaux X. <ber...@ya...> - 2010-05-02 11:23:16
|
Le 02/05/2010 12:32, W.-D. Beelitz a écrit : > Hello all, > > >> Performance issues >> > Some weeks ago I got a new PC and had the chance to compare TORCS/SD on it > with the old one. > The CPU power is not changed a lot, but the graphic card. > > With the new system I can drive a lot more opponents in a race (in a release > version). > > So I assume that optimizations of the CPU usage will not be the great step. > The real chance is using multithreading (for robots) and avoid unneeded > copying of data. > > What I found while working with the robot code is, that there is a lot of > data being copied again and again every time step. The data provided in the > interfaces for the robots is sorted by the ranking while race! > The leading driver's data is placed in the array first, followed by the next > driver and if the leading changes the cars order in the array is changed as > well. I can't imagine why this is really needed. > > Using pointers to the data should decrease the work load a lot. > > Hi Wolf-Dieter, yes and no. Pass GLUT to SDL we have loose some fps. I think that Brian work on migrate OSG (OSG is multithread for graphic but not for other code) FlightGear has migrate there is 2 years now and one CPU is used for other code than OSG. My modification for sky take more fps too (it's why, I have put activate/desactivate ssgsky) But in SD, it's module Simu take more times (take 1000 times per seconds), so I think is a good idea to put simu or robot code in multhread. So just a question : simu is called by each cars on track or called for all cars. If it's called by each car, is good idea to do simu module in multithread (with one thread create by car) if not, so do robot module in multithread. But I don't know well simu module, so I don't answered at this question. Cheers Xavier |
From: Bertaux X. <ber...@ya...> - 2010-05-02 11:11:47
|
Le 02/05/2010 12:29, ba...@ne... a écrit : > Hi all, > > i checked in my next beauty: Charmey (previously g-track-3). A lot of > new textures and now fully > PNGed textures. The Track looks simliar to Allondaz (previously > Alpine-1) so i located it in the > Swiss. > > @Xavier: I used the SVN XML file but i can't find any weather > conditions there. A error ath the XML file? > So sorry but i have always to ask you to delete empty folder :( But > please could you > delete the old empty g-track-3 directory at SVN? > Hi Eckhard, Oups ! this directory have not weather in the xml (or forget in merge), so I will modified after with new track. Cheers Xavier |
From: Bertaux X. <ber...@ya...> - 2010-05-02 11:02:52
|
Le 02/05/2010 09:58, W.-D. Beelitz a écrit : > > Hello all, > > there is a serious issue with using random numbers within Speed-Dreams. > > One of the key features of TORCS/Speed-Dreams was, that you could > rerun a race and get the same results (on the same system). > > As long as all code (including the robots) did not use uninitialized > variables, this worked fine and helps a lot to find bugs, that happen > rarely. > > If we lose this key feature, we will run into trouble. > > AFAIK we use random number generators at different parts of the code. > > One of it is the skilling done within the robots and the other one is > the weather code. > > To keep the ability to rerun a race and get same results we have to > make sure, that we use always a "controlled" random number generator. > > A "Controlled" random number generator always gives the same sequence > of pseudo random numbers after it is started. > > Starting a random number generator means setting up the state of the > generator. > > In simplix/usr we have the code > Hi Wolf-Dieter, for weather, I can use that for developement, but if I do that the sequence will be always the same, so in championship if I choice Forza and if rain is found in sequence so after each launch program so rain will be after each launch. For help developement no problem for me but one day we should have a real random, I don't know if you understand. WD, Andrew and Kilo, I will change (always for developement) menu weather by race config (for all races) we should choice weather desactivate/drizzy/rain/hard/random it's good for you ? Cheers Xavier |
From: W.-D. B. <wd...@wd...> - 2010-05-02 10:32:44
|
Hello all, > Performance issues Some weeks ago I got a new PC and had the chance to compare TORCS/SD on it with the old one. The CPU power is not changed a lot, but the graphic card. With the new system I can drive a lot more opponents in a race (in a release version). So I assume that optimizations of the CPU usage will not be the great step. The real chance is using multithreading (for robots) and avoid unneeded copying of data. What I found while working with the robot code is, that there is a lot of data being copied again and again every time step. The data provided in the interfaces for the robots is sorted by the ranking while race! The leading driver's data is placed in the array first, followed by the next driver and if the leading changes the cars order in the array is changed as well. I can't imagine why this is really needed. Using pointers to the data should decrease the work load a lot. Cheers Wolf-Dieter |
From: <ba...@ne...> - 2010-05-02 10:29:36
|
Hi all, i checked in my next beauty: Charmey (previously g-track-3). A lot of new textures and now fully PNGed textures. The Track looks simliar to Allondaz (previously Alpine-1) so i located it in the Swiss. @Xavier: I used the SVN XML file but i can't find any weather conditions there. A error ath the XML file? So sorry but i have always to ask you to delete empty folder :( But please could you delete the old empty g-track-3 directory at SVN? Any feedback is welcome! Cheers Eckhard. |
From: Speed D. <no...@so...> - 2010-05-02 10:17:15
|
#123: The player car changes when editing the player name with arrow keys -------------------------------------------+-------------------------------- Reporter: pouillot | Owner: pouillot Type: defect | Status: new Priority: minor | Milestone: 1.4.1 Component: User interface | Version: 1.4.0 Keywords: player configuration keyboard | -------------------------------------------+-------------------------------- Changes (by pouillot): * milestone: 2.0.0 => 1.4.1 -- Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/123#comment:1> Speed Dreams <http://sourceforge.net/projects/speed-dreams> An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism. |
From: Speed D. <no...@so...> - 2010-05-02 10:16:57
|
#123: The player car changes when editing the player name with arrow keys -------------------------------------------+-------------------------------- Reporter: pouillot | Owner: pouillot Type: defect | Status: new Priority: minor | Milestone: 2.0.0 Component: User interface | Version: 1.4.0 Keywords: player configuration keyboard | -------------------------------------------+-------------------------------- Left and right arrows are useful when editing the player name, but they also change the chosen car ! -- Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/123> Speed Dreams <http://sourceforge.net/projects/speed-dreams> An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism. |
From: Speed D. <no...@so...> - 2010-05-02 10:14:28
|
#122: Can't use 2 (or more) keys at the same time -------------------------------------+-------------------------------------- Reporter: pouillot | Owner: pouillot Type: defect | Status: new Priority: major | Milestone: 2.0.0 Component: User interface | Version: 2.0.0-dev Keywords: keyboard event loop SDL | -------------------------------------+-------------------------------------- Generaly results in very odd behaviours ... Example: Steer and Throttle with keyboard => the throttle often locks at full power, the steering wheel often locks on one side ... -- Ticket URL: <http://sourceforge.net/apps/trac/speed-dreams/ticket/122> Speed Dreams <http://sourceforge.net/projects/speed-dreams> An Open Motorsport Simulator forked from Torcs in order to deliver a better user experience through nicer and more consistent car sets, visually improved tracks and enhanced physics realism. |
From: Jean-Philippe <jpm...@fr...> - 2010-05-02 09:45:47
|
Hi, Kristof, Wolf-Dieter and all. > 2. Simuv3 > It makes sense to change straight to v3, but I also fear it would delay > the next release. AFAIK v2 has only the "Force" bug, which can be > avoided by setups. OTOH v3 has these collision bugs and possible > performance problems. From a personal point of view it also uses > quaternions, which I never really figured out, meaning I can work only > slower on it. So I think we can consider v3 only if we are ready to > postpone 2.0. a. Delay 2.0 release : I personaly consider that avoiding the future double work on robots and cars setups (improve Simu V2 for 2.0, and then move to Simu V3 for 2.1 or 3.0) is worth postponing 2.0 from some monthes. From what I understand now, if everything works as expected (see below), I don't expect the delay to be greater than 3 or 4 monthes. Who would vote for Simu V3 in a ~4 month postponed SD 2.0 ? b. Simu V3 collision issues : I believe that we can bet that we'll find a decent solution, of else a fallback one, in following monthes. I trust our skills on the subject, and am ready to help as far as I can (like instrumenting the code to extract data for later analysis, as an ex., or any other necessary task we'd need and that would not need too much physics / math expertise). I suppose we probably should find these solutions before starting any work on cars / robots setups rework / realism ... in case the found fixes would change the engine output. c. Performance issues. I propose to work that way : 1) run profiling sessions in order to get a clear idea of how big the issues are. The final criteria could be the loss in the number of possible opponents when compared to Simu V2 (keeping the same frame rate). I can well work on this, I know how ; may be with help from Wolf-Dieter and Andrew in order to undertand the robots behaviour about the CPU 2) at that point, we can hit the wall : if the performance loss is too big, we'd have to postpone Simu V3 from 2 or 3 years (waiting for bigger CPUs). Or decide that it can be acceptable if we can lower it through some optimization (if any possible), or with the help of some multithreading. 3) Work on the "Prepare multithreading task" to see if something simple is possible (I personaly believe that we can multithread the drivers, but only them ; the simu engine and the screen update are probably far more difficult to multithread ; see here a first glance analysis : http://sourceforge.net/apps/trac/speed-dreams/wiki/PreparingMultithreading I can endorse this task, with help from Wolf-Dieter for the robot code. 4) In parallel with 3, someone else can study the Simu V3 code and see if any optimization are possible ; I suppose Kristof could be the one, with "consultancy" help from Christos ... but may be someone else could help also ... As a summary of what we have to do and in which order : A. Run 2 parallel studies on Simu V3 : 1. Try and find possible solutions for the collision issues, even fall back ones, but not degrading too much the user experience. 2. Measure the real performance loss compared to Simu V2, decide if it kills Simu V3, or else analyse possible optimizations in Simu V3 and multithreading feasability for robots. B. If enough confident with possible solutions, decide for Sim V3 BUT decide to postpone 2.0 from some monthes to save future time and pain C. Again 2 parallel tasks : 1. Implement found solutions 2. Work on cars / robots setups realism / translation code. > 1.) Simuv2.1 branch > I originally thought forking v2.1, and keep v2 only until the release. > I think it helps during development, if we can easily switch engine > (like we can now between v2 and v3), and compare new physics with a > "known good" setup for v2. Although W-Ds idea to keep v2 as a > "compatibility" TORCS engine makes some sense, however the car setups > will likely work well only with one engine. And I think we definitely do > not want to setup cars for multiple engines. OK, you are at least 3 guys that think that, if we go for adding things to Simu V2, it would be easier through a new Simu V2.1 module. So, democracy says I'm wrong if I'm against :-) > 3. Simuv2.1 changes > I start with a good news, I think we have a good chance that we will not > need translation code. After some experiments with the Tridenti I think > with a proper suspension setup cars with realistically low mu are still > driveable. However, robots will most likely need some tinkering to > adjust them to the new setups. Incompatibilities with TORCS might arise > from aero modifications or from the fix for the "Force" bug. Cheers, Jean-Philippe. |
From: W.-D. B. <wd...@wd...> - 2010-05-02 07:58:57
|
Hello all, there is a serious issue with using random numbers within Speed-Dreams. One of the key features of TORCS/Speed-Dreams was, that you could rerun a race and get the same results (on the same system). As long as all code (including the robots) did not use uninitialized variables, this worked fine and helps a lot to find bugs, that happen rarely. If we lose this key feature, we will run into trouble. AFAIK we use random number generators at different parts of the code. One of it is the skilling done within the robots and the other one is the weather code. To keep the ability to rerun a race and get same results we have to make sure, that we use always a controlled random number generator. A Controlled random number generator always gives the same sequence of pseudo random numbers after it is started. Starting a random number generator means setting up the state of the generator. In simplix/usr we have the code //========================================================================== * // Skilling: Randomness //-------------------------------------------------------------------------- * #define RANDOM_SEED 0xfded #define RANDOM_A 1664525 #define RANDOM_C 1013904223 //========================================================================== * //========================================================================== * // Skilling: Initialize Randomness //-------------------------------------------------------------------------- * void TDriver::SetRandomSeed(unsigned int Seed) { oRandomSeed = Seed ? Seed : RANDOM_SEED; return; } //========================================================================== * //========================================================================== * // Skilling: Get Randomness //-------------------------------------------------------------------------- * unsigned int TDriver::getRandom() { oRandomSeed = RANDOM_A * oRandomSeed + RANDOM_C; return (oRandomSeed >> 16); } //========================================================================== * This is all we need. After a race is started and before you use the random number generator, you have to call SetRandomSeed(0); to get the same sequence every time. In case of weather, we will not want to have it same in all situations. Normally it should change from race to race. But to keep our key feature, we should use it in a reproducible way. If you call the initialization with a random parameter (from another random number generator or the time since reboot) you will get a different sequence of random numbers. All we need to do is to keep this seed value and reuse it, if we want to analyze the race: int Seed = TimeSinceRebootInMilliSeconds; if (RerunTheRace) Seed = LastSeed; LastSeed = Seed; SetRandomSeed(Seed); (BTW: Never use this code for cryptographic purposes ;-)) Cheers Wolf-Dieter |