Just a friendly nudge to remind you it has been over a year since the last release!
How much remains to be fixed up / polished for a new release?
"Release early, release often" - the mantra of a successful open source project
-- Charlie aka Free Gamer
well, i'm no developer, but i do know that the next release will be very much updated from the previous release.
Yep, I've been watching, another reason for this gentle prod on a new release
Hey, thanks for prodding.
I'm happy enough with the state of my scenegraph rewrite/graphics changes that I wouldn't mind putting out a release. I probably need to finish up the brake point lights first or just disable them for release, though. What do you think, NaN?
My to-do list.
easy:
- add brake caliper drawable
- load oem wheels(i'd like to move the meshes into carparts/wheel actually)
- add brake light definition to car parameters
- web: update wiki(car parameters, texture channels -> misc textures)
- web: update cars.vdrift.net
medium:
- fix tire/wheel simulation(wip)
- wheel/rim selection gui
- get bezier patch fit code ready(needs more testing, ring2007)
- arbitrary number of wheels, differential/wheel links
hard:
- rewrite car/track parser/loader(object manager, scene description, car parts)
- dynamic track objects
nice to have:
- separate drivetrain from cardynamics
- integrate dynamic daytime/sky(should be easy)
- art: rework car uv-mapping/textures(occlusion/normal map)
I could get the easy part done in a couple of days. I'd like to get the wheel simulation working. This will need more time. So I am OK to ship with the current one.
Do we want to provide the binaries/installers, or should we simply tag a certain revision as release?
You can always do one release soon(ish) and another one in a few months when a few more features are done...
i'm conflicted about the oem wheel location. it makes some logical sense to move them all into carparts/wheel
i think the main reasons to have the special case are:
1) oem branded wheels may be inappropriate for car switching.
2) each car directory is self contained right now. and it would remain so if any oem wheels were in the respective car directory. so it makes for car dependencies.
but i know how nice it is to avoid special cases in programming. and, when it comes to engines i think a shared directory would be the best way for that. mostly because, irl, there's lots of engine sharing that isn't as present with wheels. the le and a hypothetical tc7 would have basically the same engine, and swaps between cars should be very easy.
something i was thinking about on the carparts/wheel directory though. i've built one more that i haven't uploaded yet. mostly because i'm not sure how it should be named. should i maybe prefix all my work with zim_? should we have separate directories? mostly thinking about how, just recently, it has become a 15-30 minute project to add a new wheel and, as such, there could be several hundred styles in a few years time. so maybe the 5_spoke thing won't say enough.
Let's tag a release soonish and then we can get to the business of generating binaries/packages for that release.
I've just checked in an if(0) disable for the dynamic brake point lights, so I'm ready for a release. NaN, go ahead and do the svn tag for release when you're ready (format it the same as what you see for the recent releases in
http://svn.vdrift.net/repos/vdrift/tags/).
Release is r2825:
http://svn.vdrift.net/repos/vdrift/tags/...010-06-30/
I postponed brake calipers till next release. Will be updating the wiki/car sites.
@zimluura
I've been thinking about having common model/texture folders. And define cars/tracks through definition files. To be able to share as much content as possible. The allowed(selectable) textures/wheels would have to be defined in a per car options file.
I think the release should be communicated as a development snapshot to make clear that bugs might happen and bug reports are welcome.
Introduce a notion of stable and unstable releases? Something that is known to work well vs something that is the latest and greatest but possibly buggy.
NaN Wrote:I think the release should be communicated as a development snapshot to make clear that bugs might happen and bug reports are welcome.
Ah, don't worry. Every release has been like that....
should rouen be reverted and we'll disable normal mapping?