#25 closed enhancement (fixed)
Draw the current slot car positions on the track
Reported by: | Henrik Heimbuerger | Owned by: | Henrik Heimbuerger |
---|---|---|---|
Priority: | major | Milestone: | MS1: First release (1.0.0) |
Component: | track | Version: | pre-1.0 |
Keywords: | track view, slot car | Cc: |
Description
Draw the current positions of all the slot cars on top of the track.
This is actually much harder than it sounds, because it's difficult to determine how cars have to move across a tile and which direction they are facing at any given moment.
One possibility would be to define splines for each tile, describing the route a slot car would take. Thought also has to be given on how to make the cars move across the tiles in the correct speed.
Change History (12)
comment:1 Changed 16 years ago by
Status: | new → assigned |
---|
comment:2 Changed 16 years ago by
comment:3 Changed 16 years ago by
New commit by hheimbuerger (revision [141]):
[Partial fix for ticket #25] Fixed a bug that occasionally caused the application to crash during exit and added a simple frame counter.
The application occasionally crashed during exit. This was caused by an anonymous class (Runnable) that was asynchronously pushed onto the SWT event thread by the timer. This Runnable was sometimes executed after the widget had already disposed. It is now confirming that the widget is not yet disposed before executing its code (triggering a repaint).
Additionally, a simple frame counter was added. It normally shouldn't go above the gametick rate (currently 20/s), but it can be used to compare performance when higher gametick rates are used.
comment:4 Changed 16 years ago by
New commit by hheimbuerger (revision [143]):
[Partial fix for ticket #25] Cleaned up slot implementation and prepared returning the current direction.
The slot implementation has been cleaned up by converting the SlotPart class and its subclasses to top-level classes and by simplifying the Bezier curve point computation.
Additionally, the SlotPart classes now return a point and a direction (which currently is always 0) in preparation of proper direction calculations.
comment:6 Changed 16 years ago by
Status: | assigned → accepted |
---|
comment:7 Changed 16 years ago by
New commit by hheimbuerger (revision [148]):
[Partial fix for ticket #25] Implemented direction calculation for line and quad-bezier slot parts.
The line and quad-bezier slot parts now return the correct car direction for every requested step.
To visualize these changes, cars are no drawn as a short line instead of a point.
comment:8 Changed 16 years ago by
New commit by hheimbuerger (revision [152]):
[Partial fix for ticket #25] Fixed various issues with slots consisting of multiple slot parts.
Multiple slot parts in one tile slot are now properly supported. All quad-bezier parts now require a new attribute 'entryToExitAngle' that's similar to the one of the same name on tiles. (In fact, the sum of a tile's slot part entryToExitAngles should be the same as the tile's entryToExitAngle.) While this value could have been determined from the Bezier curves, I think the extra info will yield more reliable results.
Additionally, the Angle class has been fixed and now really only stores angles between 0 and 359.
A new tile for testing the multi-slot-part feature has been added to the tileset 'debug' and the demo_crossing track.
comment:9 Changed 16 years ago by
comment:10 Changed 16 years ago by
comment:11 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Considered finished. Please file new tickets for follow-up issues.
comment:12 Changed 16 years ago by
Component: | unspecified → track |
---|
New commit by hheimbuerger (revision [140]):
[Partial fix for ticket #25, related to ticket #19] Added support for specifying the car slots in the tile definition and added debug code for displaying the slots and moving objects around on them.
The tiles.xml now requires two slots to be specified for each tile. A slot consists of one or more parts of various types. The slot parts are used in the order specified.
So far, two different slot part types have been implemented. The element <line> can be used to define a slot part that goes straight from a point A to a point B. The element <quad-bezier> can be used to define a quadratic B?\195?\169zier curve.
The length attribute defines how many 'steps' are used to traverse a slot part and need to be modeled very accurately after the real track. It is also used to assign each position on the track a unique scalar value, thereby making locations very simple to store and modify.
Purely for demonstration purposes, the track widget currently draws the slots (in blue and yellow) and moves carets along them (in red). Determining the direction of an object on a slot has not yet been implemented.
NOTE 1: The application currently crashes when it is terminated while the track widget is still open. This is probably because the widget's dispose handler isn't invoked before the widget is disposed. I haven't found a way to fix that yet.
NOTE 2: The CPU usage is still rather high, I'm sure optimisations are possible.