Forums

Full Version: new TODO
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Here's what I've got on my TODO:

[background]
-add water: http://vdrift.net/forum/viewtopic.php?fo...tpost=true

[tracks]
-add tire skid marks
-displacement map for little bumps on tracks (or for bumps on rally tracks)
-fix lingering bugs with road surface
make grass/dirt slippery again
-add back fixed camera placements

[cars]
-add driver sprite or model
-headlights at night
-sun position in track file
-car selection rotation that resets light position when drawing
-improve gauges
-put gauges into the car's dash
-better tire smoke (that doesn't intrude into the car -- could just draw car over smoke if the camera view is set to inside)
--tire wear
re-code car shadows.
-downshifting protection (don't allow downshifts if revs are too high)

[sounds]
-improve sound files
-add crash sound, wind sound, engine start sound
-different sound/particles for spinning out grass/sand
-add tire/road contact sound and make it sound different for different materials (including kerb)
-made engine sound different if inside the car

[general]
search for and fix memory leaks
---add autocross support, autocross level editor
-more camera modes: left, right, front, back. also, view cycle button
-allow for a menu to end the time trial and check for a record time (and show speeds last lap)
---write coding guidelines (or at least some general philosophies)

[bugs]
---fix window resize bug in windows release
--fix crash on replay of windows version
fix/recode multiplayer

[controls]
-better keyboard control
handbrake
-remove reset..? (at least for multiplay competetive modes)
release mouse pointer in non-mouse camera modes?
-control profiles

[replay]
---add a way to embed car configuration and track into replay files
--add replay slots, improve replay menu (don't allow play directly from record, don't allow stop if not playing/recording, etc etc)
-option to see replay lap time
semi-transparent ghost replay
-auto ghost replay (start recording a replay after the starting point is passed once. Then after the car passes the starting point the second time, it can begin playing back the replay from the beginning)
-timed multiplayer mode (the only real difference would be that the cars would next to each other, and the clock would count down like in the other version. As for determining who wins, just go by the lap time for each car. For now it would be fine to have it just pre-set as a three-lap race, if that makes things simpler)

[menus]
car parts menu
-way to set weather from the menus
add a car information page to the select car screen
I've been following vdrift for quite a while now & am really impressed with the sustained effort you guys are putting into it.

I do have one question though - does vdrift have a Torcs-like API whereby 3rd party developers can write robot drivers as dynamically loaded shared libraries? If not, is there any plan to add such a feature? Over the last year I developed a robot for Torcs, but, well, vdrift is so much prettier, has greater development momentum & therefore more potential.
Nope, currently no API for that, and adding it isn't too high up on the list. TORCS really does a great job at robot racing... the intent of VDrift is to cover everything else. VDrift is open-source, though, so someone could always add in robot racing.
Also I've always thought that it would be way simpler to develop robot racers in a language like Lua which is commonly use for scripted AI in games, rather than C/C++ shared objects, since the latter are much harder to test and debug.
joevenzon Wrote:TORCS really does a great job at robot racing... the intent of VDrift is to cover everything else.

that's quite an odd statement, like saying we don't need graphics because other games/simulations cover that well already ;-)

also TORCS bad graphics and worse physics make playing it quite unsatisfactory

on a related note it think something should be done about the fact that the new track-system uses thousands of files:
the 3 new tracks are composed of over 4500 files that take over 150MB of space on my filesystem, although their *real* size is under 75MB (and compress down to 60MB). also the time to do a deployment build of vdrift increased about 5-fold because of the need to copy thousands of files.

possible solutions include using something like PhysicsFS or doing something about it in the format-level...
abs1nth Wrote:
joevenzon Wrote:TORCS really does a great job at robot racing... the intent of VDrift is to cover everything else.

that's quite an odd statement, like saying we don't need graphics because other games/simulations cover that well already ;-)
I think it would be cool to have scripted AI, but not quite like TORCS. I'd rather see it done in a higher-level language more suited for this type of scripting like Lua. However, it's not high on my list of things VDrift needs most. If someone submits a patch, of course we will certainly consider it, and if someone's really serious about working on AI scripting I could even set them up their own SVN branch where they could work on it.

abs1nth Wrote:on a related note it think something should be done about the fact that the new track-system uses thousands of files:
the 3 new tracks are composed of over 4500 files that take over 150MB of space on my filesystem, although their *real* size is under 75MB (and compress down to 60MB). also the time to do a deployment build of vdrift increased about 5-fold because of the need to copy thousands of files.
Yeah, this has become annoying, it makes SCons 0.96.1 run really slowly when running scons install (you must wait something on the order of a minute before it even begins compiling...), and with the latest SCons (0.96.91) speed is increased but this development build has its own problems...

abs1nth Wrote:possible solutions include using something like PhysicsFS or doing something about it in the format-level...
I vote format-level. All we need is to make VDrift able to handle compressed archives of model files. Sort of like WAD files in Doom or pak files in Quake. We could even use zip, or tar plus gzip, or bzip2 (er, maybe not, kinda slow). This would add another dependent library...
thelusiv Wrote:
abs1nth Wrote:
joevenzon Wrote:TORCS really does a great job at robot racing... the intent of VDrift is to cover everything else.

that's quite an odd statement, like saying we don't need graphics because other games/simulations cover that well already ;-)
I think it would be cool to have scripted AI, but not quite like TORCS. I'd rather see it done in a higher-level language more suited for this type of scripting like Lua. However, it's not high on my list of things VDrift needs most. If someone submits a patch, of course we will certainly consider it, and if someone's really serious about working on AI scripting I could even set them up their own SVN branch where they could work on it.
i'm certainly relieved to see it even on the long term road-map

an approach using something like lua seems promising...
joevenzon Wrote:
abs1nth Wrote:possible solutions include using something like PhysicsFS or doing something about it in the format-level...
I vote format-level. All we need is to make VDrift able to handle compressed archives of model files. Sort of like WAD files in Doom or pak files in Quake. We could even use zip, or tar plus gzip, or bzip2 (er, maybe not, kinda slow). This would add another dependent library...

hmm i wouldn't call that format-level, it's just a wrapper around the actual formats like what PhysicsFS does, but making less modifications necessary.

(i think format-level would be to adapt the .joe format to be able to contain an arbitrary number of named objects)

libtar is so small (and BSD licensed) it could easily be imported into the vdrift source-tree...
I disagree that robot racing is the same as graphics.

I agree that there are too many object files in the tracks. It shouldn't be hard to make a trackobject file format that contains many .joe-style objects... that gets my vote.
joevenzon Wrote:I disagree that robot racing is the same as graphics.
I wouldn't even think of it as "robot racing". In TORCS they focus on full robot racing tournaments and things like that. I don't think that'd be very useful for VDrift, but it'd be nice to have a few drivers on the road to race against.
If you're talking about having computer controlled drivers, then I think that's definitely a good feature for VDrift. If you're talking about robot racing like TORCS where players code up the AI to do purely AI vs. AI racing in tournaments and stuff, I think TORCS is probably best for that sort of thing (unless someone else wants to add that to VDrift).
I think it should be added to the TODO. Furthermore I think it would be a good idea to put the TODO on the wiki integrated into the site.
Works for me (if, again, you're talking about the first feature I mentioned).
How many who would appreciate AI interfaces?

I'm new to vdrift (just got the svn version compiling earlier today after experiencing the bouncing car problem with gcc4), and I am looking at vdrift as a candidate for testing out some learning algorithms. I've also been looking (originally) at RARS, and more recently, TORCS and Racer.

RARS is out of the picture for a whole ton of reasons, but while TORCS does have good driver interfaces for some things, the graphics are not as pretty. Also, the usage of SDL makes it easier to do some computer vision manipulations, if that's the aim of the AI implementer. It seems that about the best you can do in TORCS is read the hardware buffer, which (as I've found) can be overwritten by other applications. I was running a few AI/ComputerVision tests with TORCS and found that the data I was collecting included images from other applications. I would think that using SDL as an intermediate layer would help this problem a lot... so vdrift might be in the running for designing AI robots still...

It seems that if there were good interfaces for getting driving instructions for a vehicle, it would be easier to develop all sorts of AI drivers: whether those drivers were Lua-script-based, or neural-net drivers, or whatever.
If you or someone else wants to add those sorts of features, that's fine with me... but I wasn't planning on coding that up.
joevenzon Wrote:I agree that there are too many object files in the tracks. It shouldn't be hard to make a trackobject file format that contains many .joe-style objects... that gets my vote.

Okay, I added this today. You get to go from over 2000 object files for neurburgring to one 6 mb file. Seems to load a bit faster. The tool is called joepack and is included in SVN as a subdir of the track editor. You can pack arbitrary types of files (and folder arrangements) into a joepack file, but the game expects a pack containing all of the .joe object files for a track to be in track/objects/objects.jpk for the track to load. The track loading code is backwards compatible and will revert to the old system (lots of individual .joe files in track/objects/) if track/objects/objects.jpk does not exist.

I'll check in the changes to VDrift once SVN finishes going nuts over the fact that I've made around 4000 file deletions.
Pages: 1 2