Activity for Farrer
-
Farrer modified ticket #27
no match for ‘operator!=’
-
Fixed in commit 15702ade to master. Thanks for the report Qubodup!
-
Correct value for .ttf fonts seems the median calculation.
-
Updated changelog, and reordered it.
-
Fixed support for line breaks inside a table cell.
-
Avoiding trying to fit on smaller space.
-
Removed breaklines.
-
Update changelog.
-
Optionally allowing break pages inner a table row.
-
Not needed.
-
Signal was inverted on current and total pages replace.
-
Updated changelog
-
Fixed table rendering (was with some int-truncation). Also, the fill adjust is only necessary when not using a border.
-
Bug: Some adjust to .ttf font space width calculation.
-
Using own version.
-
Centralized width calculation.
-
Updated odt dependency
-
Updated .docx dependency
-
Updaded flying-saucer version for html conversion.
-
Updated changelog.
-
Some fixes and code refactor for text rendering.
-
Fix for embeded .ttf fonts render position.
-
Create PDFFontINfo to keep track of the type of font we created.
-
avoid instanceof on PDFBLockInfo.
-
avoiding use of instance of for PDFSentence.
-
Better if InputStream.
-
Added support for loading TTF fonts instead of the default ones.
-
Updated dependencies.
-
Update to newer dependencies versions. Removed deprecated use.
-
Functions for get/set dimensions in pixels.
-
About velocity, if you remove the 0.5 multiplier at line 104 of vehicle.cpp you should get a torque that will feel similar to the original one. But remember that the car will be very unstable at high velocities. About the terrain, take a look at lines 440-466, where the triangle list is created, and at function PTerrain::createBulletStructures(), lines 473-527, where those are passed to Bullet. As you suggested on a previous message, if you'll try to fake the vehicle coordinates, you can apply at...
-
Got something playable. It feels like a lot different game than current one (for good and bad), besides some known bugs and "yet-not-ported" parts of the code. Not sure if worth continue to develop it further (or if I'll have the time for that), anyway, the fork is public in case I stop working on it, for anyone interested in continue. For known bugs I'm talking about the chassis rigid body sometimes touching the terrain, depending on the suspension definitions, which will result on adrupt collisions;...
-
I did not checked that part of the code, and just wrote things from what my 'feelings' were when playing with the original code. Probably the different soil outside the road was getting a big slow down that I associated with the penalty (which is the only visible feedback to the user of that 'harder to go'). Anyway, I did not checked that part of the code yet, and I'm not sure if I can do that without some changes to the way I defined the terrain mesh for bullet (currently, it is defining as a single...
-
This actually re-ensures me since I was wondering if I am just nod good enough with estimating such things. On the other hand your findings might not concern what seems most odd to me: The actual physical speed doesn't feel like the values given in the OSD. As far as I saw on previous Trigger code, the rendered speed value was defined by this wrong wheel speed, multiplied by 0.1f and by another constant (hud_speedo_mps_speed_mult). Indeed the speed value displayed was wrong. BTW, I had to define...
-
This actually re-ensures me since I was wondering if I am just nod good enough with estimating such things. On the other hand your findings might not concern what seems most odd to me: The actual physical speed doesn't feel like the values given in the OSD. As far as I saw on previous Trigger code, the rendered speed value was defined by this wrong wheel speed, multiplied by 0.1f and by another constant (hud_speedo_mps_speed_mult). Indeed the speed value displayed was wrong. BTW, I had to define...
-
Just to point out (as somewhat mentioned by both of you previously) the wheel rotation per second value got on current trigger engine is indeed wrong. For example, at 4th gear, it's showing a value for wheel_rps at PDriveSystemInstance::tick (where is calculated the engine output torque) of ~100 revolutions per second. If you say that the wheel radius is 0.5 meters, we got the incredible value of 314m/s or 1130 km/h for the velocity of the wheel! (if I didn't calculated it wrong) For bullet, the...
-
@Onsemeliot You didn't refer to my question concerning buildings Just after I've answered I saw that I've oversighted some points, sorry. Any kind of interaction with any 3d object is definitely possible and very easy to do. Just define bullet's shapes, rigid body and motion state for each one (I can add latter an interface to make that, receiveing either the bounding box or the model and creating those or something like that). If you have time, you should look/test some Bullet's tutorials to understand...
-
@Onsemeliot I'm not sure about the negative values. Do you mean you just ignored them at the moment or that keeping it would be unnecessarily hard to do? I mean I just ignored them. Should be easy to define the range by reading through the file, but laborious to change the indexing of vertices again, so I don't plan to to that until had everything else working. And if we would need to add 3-dimensional objects for bigger vegetation in order to get proper collisions (...) Therefore, this center block...
-
I have some questions/points: 1) There's a definition of vehicle's dimensions. On the old physics it was only used for defining the vehicle's center of mass (ie: no collision verification). But, at last for cordo car (the one I'm using to test), the dimensions are somewhat larger than the model. Should we stop using this parameter and getting the 'real-values' (from model's bounding box)? 2) The 'wheeldrive' parameter seems only cosmetic on old physics (only used for rendering on vehicle's statistics)....
-
I have some questions/points: 1) There's a definition of vehicle's dimensions. On the old physics it was only used for defining the vehicle's center of mass (ie: no collision verification). But, at last for fox car (the one I'm using to test), the dimensions are somewhat larger than the model. Should we stop using this parameter and getting the 'real-values' (from model's bounding box)? 2) The 'wheeldrive' parameter seems only cosmetic on old physics (only used for rendering on vehicle's statistics)....
-
Just to point out that you shouldn't stop your work on Trigger because of my new try/approach with bullet. Due to some things, mainly Trigger handiness being different from Bullet's one, and to the fact of lot of unused code already lies on current svn codebase (which makes things worse and too much disruptive on any change... why a rally game should have a periscope and tank, helicopter and planes implementations? In fact, I'm ignoring those.), I believe that the bullet's approach will be somewhat...
-
@Onsemeliot Sometimes I like to put my ownFLOSS projects at a side and contribute to other ones. Trigger codebase is small enough to be somewhat easy to understand (although sometimes with few code comments and with some unnecessary optimizations that obfuscate the code at first sight). It's fun to work with it anyway. @Andrei Don't worry, I just made the compile with CMake to feel more confortable compiling the code (I never used its gui, btw), and i've made it very quick and with a lot of TODOs...
-
I've started working on it. So far I have the terrain fully implemented as a bullet triangle mesh (sharing the vertices data with Trigger renderer - which led me to remove the use of old terrain's hmap to avoid duplicate resources of same data) and changed the building system to use CMake (instead of hardcoding libraries path to the current GNUMakefile... there'll be no need for you to accept that, it's just that I feel more confortable using CMake to locate the libraries than editing the current...
-
I've started working on it. So far I have the terrain fully implemented as a bullet triangle mesh (sharing the vertices data with Trigger renderer - which led me to remove the use of old terrain's hmap to avoid duplicate resources of same data) and changed the building system to use CMake (instead of hardcoding libraries path to the current GNUMakefile... there'll be no need for you to accept that, it's just that I feel more confortable using CMake to locate the libraries than editing the current...
-
Not sure about applying the patch. Better would be a definitive fix to the physics. I'll try to look deeper on the physics code. Edit: ignore, forgot that the force was, ideally, multiplied by mass when defined. Edit2: What seems to be causing the strage behaviour when losing contact with ground (and, obviously, on curves too) is the tensor-like approximation implementation. The sollution, I believe, is either reinvent the wheel and implement another rigid-body tensor to Trigger or use an existing...
-
Not sure about applying the patch. Better would be a definitive fix to the physics. I'll try to look deeper on the physics code. Edit: ignore, forgot that the force was, ideally, multiplied by mass when defined.
-
Not sure about applying the patch. Better would be a definitive fix to the physics. I'll try to look deeper on the physics code. Something seems very strange to me on the RigidBody::tick: linvel += (accum_force * mass_inv + sim.gravity) * delta; pos += linvel * delta; or maybe I'm missing something?
-
Not sure about applying the patch. Better would be a definitive fix to the physics. I'll try to look deeper on the physics code. Something seems very strange to me on the RigidBody::tick: linvel += (accum_force * mass_inv + sim.gravity) * delta; or maybe I'm missing something?
-
Updated the original patch (file: not_contacting_ground_patch_updated.diff) to current svn code, if anyone is interested on it. Also, by the suggestion of always applying the gravity to the vehicle, i've created another patch (file: fixed_gravity_patch.diff), which applyes a fixed gravity value to the vehicle every time (instead of only when it loss contact with the ground, as was the original patch). The car seems too much glued to the ground, but maybe with a change to the gravity constant (GRAVITY_FORCE...
-
If is desirable, I could also update it to the current code. But, as mentioned early, this is just a quick try to workaround the 'fly-behavior' and it seems very strange for most people who played trigger over on these years. A better approach (if there's time for it), could be using Bullet Physics vehicle or adapt Stunt Rally implemented physics to Trigger. But it will be a huge task.
-
Should not trust on file extension. Let's load ...
-
Closing any opened window.
-
No more at atexit.
-
Better (and more simple) list implementation.
-
Must close the opened dir
-
Initialing visible matrix.
-
Refactor for BTree
-
Must free align's image.
-
Some init.
-
Initializing 'changed' flag
-
Simplified lists
-
Created tag for version 1.1.1
-
defined creator string
-
Changelog
-
Fixes for nested table construction on pdf-gene...
-
Rendered a nested table also on the second colu...
-
Updated changelog
-
Updated PDFBox to 2.0.2
-
Added .docx and .odt generators to the examples.
-
Defined some needed constants.
-
Added doc note about image aspect ratio.
-
Simple (and quick made) application to get a bu...
-
Added changelog.
-
- Added functions to set both width and height ...
-
Using the full xsd.
-
Some work to .docx: table width, page size and ...
-
Some work to headers and footers for .docx repo...
-
More to .docx implementation: paragraphs, group...
-
Removed unused import.
-
Added color conversion (on-demand) to RGB hexad...
-
Dependency.
-
Must allow internal resolution.
-
Added initial implementation of .docx report ge...
-
Style for ODT texts.
-
ODT ahorizontal alignment.
-
Lot's of thing missed disclaimer.
-
Some comments revision.
-
More to the implementation of ODT generator.
-
Begining the implementation of .odt generator.
-
Defined generation formats as static final stri...
-
Removed unused import.
-
Correct values, due to page margins.
-
Added 1.1 tag.
-
Must use append mode, instead of overwrite....
-
Changes to support PDFBox 2.0.
-
After 0.12 release.
-
Added the normalmap
-
Added new mission: Tux Rock Art.
-
Added how to install the vim syntax files.
-
Spider walk_interval defined.
1 >