Racer v0.8.38 released

Ruud

RACER Developer
Racer v0.8.38 is now available at http://www.mediafire.com/file/a9z1omd6rmhzymb/racer0.8.38b.7z

Enjoy!
Ruud

Changelist:
- Look_up/look_down controls added for to make TrackIR devices possible.
That makes head tracking possible, although currently a bit crude.
- In your controller file you can add global.up_down_velocity to set up/down look velocity (default=250)
- In your controller file you can add global.up_down_look_max to set the max up/down look angle (default=45)
- Removed energy conserving diffuse/specular lighting for version 0.9.
- Auto exposure turned back on. It can cause dips in framerate on some systems (every second, a grab is mipmapped to obtain the scene brightness).
- Added shader .mipmap_bias for the global shader and optionally for separate layers.
- Added cubemap mipmapping to all reflection shaders for environment mapping.
Requires a good graphics card; otherwise, turn off envmap.generate_mipmaps (set to 0).
- Fixed keep_aspect (dials/views.ini) for multi-monitor setups.
- Setting up graphics settings and starting a race would crash.
- Added dev.collisions setting to globally turn off collision checking.
- Wireframe mode gave bad texturing for the rest of the graphics.
- Trackcam FOV clamped to zoom range indicated by the camera
- Newton solver parameters reverted in the hopes of fixing now & then hangups (10-200 seconds each, after several hours of play)
- Car camera offset seems back working; the FIXED camera type should now work correctly again.
- Shadowmapping in car camera mode focuses on the car, even if the camera from/to positions are some distance away from the car.
- Reverted back to FMod 4.30 (was v4.36) since some people had volume problems at startup.
- Differential power_ratio warnings were mistakenly given for non-LSD type diffs.
 
You both right, generally talking, we know night, shadows & lights are the weakest points in Racer, unfortunetely !

Hope will get some Shift 2 or GTR3 or whatever games right now, doing stuff with night.
I've successfully faked lights via alpha channeling (months ago), but I wouldn't recommend, because it's all FAKE.

We don't want to fake imho, we need Racer beeing more dynamical instead & avoid wasting time trying to find a technique to get our ideas real. It's just a matter beeing curious, checking others codes & trying to implement the best into Racer.
 
You have to fake everything to a certain point :D

It's just finding fakes that fit with expectations as technology develops and graphics processing power improves.

I think Racer's lights right now work ok. There will always be something better each and every year, but we can't expect Racer, Ruud, and authors to always be developing content to fit the latest trends as it makes Racer have zero content that actually lasts longer than 3 months.

I'd rather have no lights, or the lights we have now, and fixed platform to develop for, than waiting another 6 months for headlights to be made better, by which time some other graphics might look slightly dated and then re-work those to fit the latest trends.

Back in the old days of Racer, graphics stayed constant for literally years! That is why we had literally hundreds of cars and tracks to choose from and tons of users/content creators :D

Dave
 
+1.
It's all about art. That's the difference between good content and not so good. Anyway...

Tried making a replay file - all went well until the end of the audio pass, FMOD threw an error about failing to close or something:
Code:
OS-Version: 6.1.7600 () 0x100-0x1
 
0x00567D30 [racer]: (filename not available): (function-name not available)
0x00567D94 [racer]: (filename not available): (function-name not available)
0x004178A3 [racer]: (filename not available): (function-name not available)
0x10002E52 [fmodex]: (filename not available): (function-name not available)
0x10037841 [fmodex]: (filename not available): FMOD_Debug_SetMode
0x10002E52 [fmodex]: (filename not available): (function-name not available)
0x10002E52 [fmodex]: (filename not available): (function-name not available)
0x1003771B [fmodex]: (filename not available): FMOD_Debug_SetMode
0x10023229 [fmodex]: (filename not available): FMOD::System::getMemoryInfo
0x10016E48 [fmodex]: (filename not available): FMOD::DSP::release
Sun Jan 29 13:34:02 (INFO): [racer/4048] Crash detected - attempting to recover some data before displaying the crash dialog
Sun Jan 29 13:34:03 (FATAL): [racer/4048] Exception 0xC0000005, flags 0, Address 0x004161D2
(this dialog text is stored in QLOG.txt)
 
OS-Version: 6.1.7600 () 0x100-0x1
 
0x004161D2 [racer]: (filename not available): (function-name not available)
0x75429D57 [kernel32]: (filename not available): CheckForReadOnlyResource
0x005653F1 [racer]: (filename not available): (function-name not available)
0x00567D30 [racer]: (filename not available): (function-name not available)
0x00567D94 [racer]: (filename not available): (function-name not available)
0x004178A3 [racer]: (filename not available): (function-name not available)
0x10002E52 [fmodex]: (filename not available): (function-name not available)
0x10037841 [fmodex]: (filename not available): FMOD_Debug_SetMode
0x10002E52 [fmodex]: (filename not available): (function-name not available)
0x10002E52 [fmodex]: (filename not available): (function-name not available)
0x1003771B [fmodex]: (filename not available): FMOD_Debug_SetMode
0x10023229 [fmodex]: (filename not available): FMOD::System::getMemoryInfo
0x10016E48 [fmodex]: (filename not available): FMOD::DSP::release

Then I discovered that since I'm running 2560x1440 res, captured at 60fps, the file was too large. Apparently you can only write a 4gb file? Isn't there some way of splitting it once it gets to 4gb and saving the rest in a replay_001.whatever file?

Secondly, audio.
Honestly audio needs an overhaul. We need access to the FMOD audio filters and there's something just completely wrong with audio altogether. Luckily the replay audio file caught what I'm talking about:
http://picosong.com/7i8
Audio cuts out when the rpm changes rapidly. Only noticed this in the replay, not when running in realtime.

Another problem is the skid buffer, in replays skidmarks show up where they aren't yet laid down. Then a second before they're actually created they disappear and appear correctly behind the tyres. Was trying to save a video of this when the replay incident occurred.
Could not replicate it if viewed from the "view replay" option in the menu.
 
Another problem is the skid buffer, in replays skidmarks show up where they aren't yet laid down. Then a second before they're actually created they disappear and appear correctly behind the tyres. Was trying to save a video of this when the replay incident occurred.
Could not replicate it if viewed from the "view replay" option in the menu.

If I may suggest, that disappearing shouldn't occur near the car, imo, it looks weird.
Also, sometimes they are incorrectly projected somewhere (improbable locations) in my tracks...

Hm to all projecting shaders...
i.e. check your ambient_shadow when you're behind a simple opened mesh (with cull=none) like a wall, you'll see the shadow rendering on top of everything...same for all...
 
I did a replay on carlswood and all went well. Isn't it making a video that is the problem? I'll give it a try and let you all know if I have the same problems.

Just made an avi from a replay and all was well. Did get an "AVI Chunk Viewer" popoup that required X'ing off a couple of times before the video played with sound.

Making a video with Racer ver 0.0838:
Run a race.
At end of race press F2 key to run replay.
At end of replay click red dot to save the replay.
Go back to menu and select "view replay" and select the one you just saved.
At end of replay select the far right icon (looks like film).
enter fps, 24 is good, ok, select codec (you may have to try each one to find the one that works on your computer). Mpeg-4 is good.
Let the replay run twice to get sound.
Look in racer folder for replay.avi and replay.wav files, If they are not there or don't work then go back and use a different codec.
Use Windows Movie Maker to make a video with sound if the avi doen't have sound.
 
resolution.monitors is used to just put HUD stuff on one monitor, if I remember right.

You would need to set resolution.width/height to the total size you want it to cover as well (eg. width=3840, height=1024 for 3 1280x1024 monitors)

Might also want to set near_fullscreen=1 and no_border=1, so you get a fullscreen mode that doesn't try to display on a single monitor.
 
+ render_aspect=4 if i.e. 3840 x 960px

Keep in mind, always setting by a multiple of 2/4/8/16 the width/height or Racer will crash.
The HUD in views.ini have a new aspect ratio, so most older cars will probably have 'distorted' HUDs.

In fullscreen, keep your monitor order/displays to 1 - 2 - 3, from left to right.
On ATI, RMB > CCC > Display Props > Detect
Set & apply accordingly.

============================
Phenom X4 9950 BE OC 2900MHZ
OCZ Gold DDR2 4GB OC 1066MHZ
Gigabyte GA-MA78G-DS3H Rev2.0
ATI HD 4670 1024 MB
ATI HD 4670 512 MB
Corsair TX 750W
Triple Screen 19" LCD 3x DVI + 3x VGA [6 outputs]
XP SP 3
G25 & G15
 
Just had a thought, what about a shader that uses atlasing & tiling?
For example, grass, where you want tiling to occur, but would like to use multiple layers to provide variations to break u the tiling effect.
As an example, I want three different 512x512 textures to be used, at different scaling and blended together, like we do now using seperate textures & layers. i could then tell the shader to use a 1024x1024 atlas of the three 512x512 textures, but the shader only tiles 512 pixels of it, and offsets the 2nd (512,0) & 3rd (512,512)layers to the starting points for tiling in the altas texture and each layer can be scaled seperately before the blend.
Comments?
 
Just had a thought, what about a shader that uses atlasing & tiling?
For example, grass, where you want tiling to occur, but would like to use multiple layers to provide variations to break u the tiling effect.
As an example, I want three different 512x512 textures to be used, at different scaling and blended together, like we do now using seperate textures & layers. i could then tell the shader to use a 1024x1024 atlas of the three 512x512 textures, but the shader only tiles 512 pixels of it, and offsets the 2nd (512,0) & 3rd (512,512)layers to the starting points for tiling in the altas texture and each layer can be scaled seperately before the blend.
Comments?
I had a similar thought, the main problem I could come up with was where the tiling repeats - there'll be a bit of overlap into neighbouring images (especially with mipmapping) so it needs to be identical there too. On xtree atlasing the edges are transparent so it doesn't show up, here you'd need to be more careful to get the edges all similar, all variations inside the borders.

I was thinking mostly along the lines of using it to add random dirt/leaves/stains details, make the primary texture less uniform.
 
mipmapping shouldn't be an issue if you use DDS and filter each texture down isolated from the others (can do this using the nVidia tools for DDS in PS)
Only once you get under 2px x 2px mipmap in this case, will you have issues hehe :D


I think that shader seems a bit excessive though, no? Lots of blending going on etc?

Not better to just quad your terrain mesh down and then scatter an atlas of varied grass textures over it?

Hmmm

Dave
 
Not better to just quad your terrain mesh down and then scatter an atlas of varied grass textures over it?
Doing it that way has its own benefits, of course
- finer control
- headlights work right (they light up vertices, sparse meshes look funny as a result)
- other vertex colouring

On the other hand, with texture blending, you can switch seamlessly using global xz mapping for background textures and poly mapping for details, without having to explicitly make all the border textures. I was thinking one control map + 2 base textures - so eg. you put asphalt + dirt into the base textures, then the control map is an alpha switch that uses UV coordinates and switches between the two. Then later another pair of dirt+grass could have the dirt on the same global coordinates, thus being seamless with less effort. That way the base textures carry their own specular type info. Still leaves some channels in the control map, which could be used to add a bumpmap or maybe grayscale singularities (eg. draw some oil or paint on the road, using one channel to control the appearance and another the darkness)

It would be easier with per-layer scale variables though heh.
 
Hmmmm, not sure really. It all sounds good in theory, but in practice, when you are actually racing or driving or whatever, you tend not to notice how nice blends are etc etc...

I generally agree with the idea, it would be nice to have these super shaders that make seamless terrains, but I just think it's not feasible to make them nice enough generally, or fast enough, to be useful.

Right now we can use a simple blend strip on the edge of our roads for example, that wobbles in and out with polygons, textured with an array of mud/dust textures, that blends the road to the grass (underneath the wobbly textured polygons is a sharp transition edge)

Since that is the only bit we will ever really see close up from the car, unless we go adventuring just to look for faults, that seems to work ok. More so when we watch in replays or during racing, it's all blurred anyway.
Better to cost some FPS blurring details away so it's not important 95% of the time, than worry about details at the cost of a visual effect which makes them irrelevant almost all the time instead.


I think half the issue these days is we compare photomode GT5 and Forza 4 shots with Racer in realtime. We are setting silly expectations and it's just not practical to make tracks that look perfect all the time when driving around zooming in on track edges etc. Do that in GT5 and it's quite poor really, but in practice it doesn't matter as you enjoy driving on a nice looking track instead :D

Hmmmm

Dave
 
Ie:

http://thumbsnap.com/f/vyV1WS5Q

The edge there really isn't so hot, the kerb texture is higher quality, with sand bleed, and then the texture it pushes up to is much lower resolution. But in practice you'd never really spot that except in a zero blur screen grab like that, and I'd be happy with that.

We can worry too much about the details and forget the overall quality of the composition.

In my view, just using a diffuse and alpha for transparency if needed, and then a bump map with alpha for specular is plenty for most track materials. Maybe a detail texture on top for extra quality if you want.

If the environment is rich enough with details in the right places, and we have some motion blur, then the details that are wrong will be corrected by our eyes/brains anyway...

ie, an X tree at 50m away looks like a tree, thus why bother with much else for trees 50m or more away?

Kerb/track > soil/grass transitions are hardly visible except when just a few metres away at a standstill, so why bother with much more than a sharp transition, maybe with an overlay poly strip with a 'blend' to cover the seam on a 20m LOD or something?

Hmmm

Dave
 

Latest News

What's needed for simracing in 2024?

  • More games, period

  • Better graphics/visuals

  • Advanced physics and handling

  • More cars and tracks

  • AI improvements

  • AI engineering

  • Cross-platform play

  • New game Modes

  • Other, post your idea


Results are only viewable after voting.
Back
Top