Jump to content


* * * * - 3 votes

DX9 for GPL?


  • Please log in to reply
86 replies to this topic

#1 miklkit

miklkit

    airhead

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,137 posts
  • Gender:Male
  • Location:left coast, U.S.A.
  • Interests:GPL
  • Sim interest:GPL

Posted Jan 06 2010 - 02:41 PM

I bet others already know about this, but I gotta get it out there.

Has anyone heard of a game called "GTA-Vice City"?   I hadn't until 2 days ago.  Anyway, someone made a DX8 to DX9 adaptor for it.  Then someone else adapted it for another DX8 game. "Pirates of the Caribbean" (2003)  :pirateflag: That's where I found it.  It made an immediate improvement in sharpness.  It also has bloom and hdr.  Soooo.  How hard would it be to adapt it to GPL?  The adaptor has 2 dlls.  A DX8.dll and a DX9.dll.  What would it take to create a DX7.dll?  With much of the work already done this might be a quick and dirty way to improve GPL's graphics while we wait for brrr to sober up.   :lol:

#2 brr

brr

    a GPL editor

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,244 posts
  • Gender:Male
  • Sim interest:GPL

Posted Jan 06 2010 - 03:14 PM

View Postmiklkit, on Jan 6 2010, 10:41 PM, said:

I bet others already know about this, but I gotta get it out there.

Has anyone heard of a game called "GTA-Vice City"?   I hadn't until 2 days ago.  Anyway, someone made a DX8 to DX9 adaptor for it.  Then someone else adapted it for another DX8 game. "Pirates of the Caribbean" (2003)  :pirateflag: That's where I found it.  It made an immediate improvement in sharpness.  It also has bloom and hdr.  Soooo.  How hard would it be to adapt it to GPL?  The adaptor has 2 dlls.  A DX8.dll and a DX9.dll.  What would it take to create a DX7.dll?  With much of the work already done this might be a quick and dirty way to improve GPL's graphics while we wait for brrr to sober up.   :lol:

Almost sober now. Because GPL does a large part of graphics processing itself, the rasteriser interface (through which quick and dirty could be done) is very limited. Whatever effects a new rasteriser could implement are limited by the small amount of information which GPL sends to the rasteriser.

It is probably worth redoing the whole graphics rendering, since that way there are no technical limitations dating from last millennium.

#3 miklkit

miklkit

    airhead

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,137 posts
  • Gender:Male
  • Location:left coast, U.S.A.
  • Interests:GPL
  • Sim interest:GPL

Posted Jan 06 2010 - 06:17 PM

Maybe I misunderstood.  It sounds to me like it upgrades DX8 to DX9 for these games.  It works too.  Are you saying that GPL uses a system so different that it needs a complete re engineering before it can be upgraded?  Here is the readme that comes with it.


Description of ENBSeries on the web page may not be equal to version in downloaded mod
archive (installer).


ENBSeries for GTA3 v0.075

WARNING! This version requires DX8 to DX9 convertor to run (included in this archieve),
but because convertor is in debug state currently, it's strongly recommended after
long time playing reboot computer.
Effects for water and shadows not implemented in this version.
For version 0.074f: version works correctly with non-fullscreen viewports, motion blur
vectors are not limited any more, added new parameter ShadowBlurRange to control
bluriness of shadows, FadeDistance to control ambient occlusion distance, UseEnvBump
to deform reflections on cars and two additional parameters for this bump deformations.
For version 0.074e: Added new parameter UsePaletteTexture, now you can change color correction by
custom bitmap image.
For version 0.074d: Activated preset OcclusionQuality for high-end videocards. Added DepthBias parameter.
For version 0.074c: This recompilation based on version 0.074b, solve some bugs and activates
disabled previously functionality. Motion blur effect still works incorrect, but i
decide to let it be, later may be i find out what is wrong. SSAO now have several
parameters, also allow to use ambient occlusion only without indirect lightning for
better performance. SSAO now activated for AlternativeDepth=0. Some problems with
dissapearing and flickering of SSAO and soft shadows now solved. Added shadows
filtering.




//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++
//
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++
SYSTEM REQUIREMENTS:
Videocard with support of Shader Model 2.0 or better. Videocards in the list below may fit:
GeForce 6100, 6150, 6200, 6600, 6800, 7300, 7600, 7800, 7900, 8500, 8600, 8800;
Radeon 9500, 9550, 9600, 9700, 9800, 300, 600, 700, 800, 850, 1300, 1600, 1800, 1900, 1950, 2400, 2600, 2900, 3850, 3870.
I can't guarantee that mod will work on all of them by many reasons (different drivers, hardware reduced versions and just because not tested myself). ENBSeries (current version) will not run at all or will not work properly if hardware by any reason not support minimal requirements of the mod. Videocards with lower shader versions capable to work in theory, but they are too slow, no sense. Videocards of new generation (DirectX10 compatible) in common cases works much faster in this mod, than their performance equivalents in DirectX9 games.
The requirements to videomemory size are very high, depends from screen resolution and antialiasing, for example without antialiasing in a mode 1024*768 it cost 64 Mb of videomemory, and for 1280*1024 106 Mb are necessary. Operative memory and processor play an insignificant role, though all should be balanced.


GAME COMPATIBILITY:
Mod may work incorrect with some versions of the games, impossible to test it for every game patch and for already modded games. Some types of installed game modifications may conflict with ENBSeries.

INSTALLING:
Extract files from archive in to the game directory or where game execution file exist (.exe). For some games it is in the directories named system, bin, bin32. Warning, some games needs root game directory for mod even if .exe file is not there.

STARTING:
After game start the mod deactivated by default, to activate it use key combination (for GTASA shift+f12 by default).

SETUP:
After first game start with the mod, configuration file enbseries.ini will be created, use it to modify mod setting. Warning, if configuration file will be corrupted in any way, remove it and run mod again.

SETTING DESCRIPTION:

[PROXY]
EnableProxyLibrary=(0,1) load 3rd party library by the mod at game start. Helps to solve problem with multiple d3d9.dll files.
InitProxyFunctions=(0,1) connect to functions of 3rd party library.
ProxyLibrary=(filename) file name of 3rd party library.

[GLOBAL]
UseEffect=(0,1) activate mod at start. In some situations HUD or startup movies may be corrupted visually because of this parameter enabled.
AlternativeDepth=(0,1) increase performance of some effects, but not all videocards can use this mode at full precision, if you see large lines on the objects, disable this parameter.
AllowAntialias=(0,1) enables antialiasing setting from game to be used in the mod effects. (antialiasing, multisampling, fsaa, in other words).
BugFixMode=(0..5) every value fixes it's own unsopported feature or bug in driver or hardware. For drivers 169.xx and 171.xx do not set this parameter to 1. Values from 0 to 5 actually HDR texture formats: 0 (R32G32F)-high quality and middle performance, 1 (R32F)-high quality and fast, 2 (A32R32G32B32F)-high quality and very slow, 3 (R16F)-low quality and fastest, 4 (R16G16F)-low quality and fast, 5 (A16R16G16B16F)-low quality and middle performance.
SkipShaderOptimization=(0,1) disables optimization when compiling shader, may help to elliminate bugs.

[EFFECT]
EnableBloom=(0,1) enables bloom effect (bright areas blurred) with time dependent adaptation. Works only if mod activated already (by key combination).
EnableOcclusion=(0,1) enables ambient occlusions (ssao) and some other effects (mod version dependent).
EnableReflection=(0,1) reflection of vehicles.
EnableMotionblur=(0,1) blurring image in fast motion of camera. Temporary disabled.
EnableWater=(0,1) enable water effects
EnableShadow=(0,1) enable shadow effects
DepthBias=(0..1000) for scene depth rendering, offset of geometry relative camera viewpoint. For some videocards may be useful to remove flickering and hiding of ambient occlusions.

[INPUT]
KeyUseEffect=(1..255) decimal key number for mod activation/deactivation.
KeyBloom=(1..255) decimal key number for bloom activation/deactivation.
KeyOcclusion=(1..255) decimal key number for ssao activation/deactivation.
KeyReflection=(1..255) decimal key number for reflection activation/deactivation.
KeyCombination=(1..255) decimal number of additional key for combining this key with others (SHIFT by default).
KeyShadow=(1..255) decimal key number for shadow activation/deactivation.
KeyWater=(1..255) decimal key number for water activation/deactivation.

[REFLECTION]
ReflectionPower=(0..100) level of cars reflection.
ChromePower=(0..100) level of steel parts reflection. Temporary disabled.
UseCurrentFrameReflection=(0,1) when 1 use for reflection image of current frame screen, otherwise use previous frame image.
ReflectionQuality=(0..2) quality, 0 means maximal quality and slowest speed.
ReflectionSourceSpecular=(0..100) percent of using "specular" material color as reflection factor. Some car parts may be reflective with this setting.
ReflectionSourceTFactor=(0..100) percent of using "texture factor" as game environment map mix level. Some car parts may not be reflective with this parameter and on the contrary.
UseAdditiveReflection=(0,1) reflections added to screen car colors, 0 means more softly reflection.
ReflectionDepthBias=(0..1000) offset of reflection geometry relative to car and camera viewpoint. For some videocards may be useful to remove flickering and hiding of reflections.
UseLowResReflection=(0,1) use small and blurred texture as reflection, looks like matte reflection.

[BLOOM]
BloomPowerDay=(0..100) power of bloom at day time, dependent from screen brightness.
BloomFadeTime=(0..100000) time of bloom adaptation to screen brightness change, in milliseconds.
BloomConstantDay=(0..100) power of bloom at day time, independent from adaptation time between screen brightness change.
BloomQuality=(0..2) bloom effect quality, 0 means maximal quality.
BloomScreenLevelDay=(0..100) level of screen brightness in percents, that determined as day time.
BloomCurveDay=(-10..10) gamma correction of bloom at day time. negative values increases halftone brightness (smoggy look), positive values decrease halftones brightness (contrast, intensive image).
BloomPowerNight=(0..100) power of bloom at night time, dependent from screen brightness.
BloomConstantNight=(0..100) power of bloom at night time, independent from adaptation time between screen brightness change.
BloomCurveNight=(-10..10) gamma correction of bloom at night time. negative values increases halftone brightness (smoggy look), positive values decrease halftones brightness (contrast, intensive image).
BloomScreenLevelNight=(0..100) level of screen brightness in percents, that determined as night time.
BloomAdaptationScreenLevel=(0..100) level of screen brightness in percents, over which bloom deactivating. It's desirable that this parameter will be greater than BloomScreenLevelDay.
BloomAdaptationMultiplier=(0..100) percent of day time bloom brightness, that will be used when screen brightness will be greater than BloomAdaptationScreenLevel. Value 100 disable adaptation
BloomAllowOversaturation=(0,1) if 0, bloom softly applied to screen and bright areas not become too oversaturated.

[SSAO]
UseFilter=(0,1) enable noise filtering, produced by ambient occlusion effect.
OcclusionQuality=(0..2) quality of ssao, 0 means maximal quality and slow performance. In current version this is disabled, using lowest quality level.
FilterQuality=(0..2) quality of ssao noise filtering, 0 is maximal quality and slowest performance.
DarkeningLevel=(0..100) darkening level by ambient occlusion
BrighteningLevel=(0..100) edge lightening level by ambient occlusion
IlluminationLevel=(0..100) light transfering level by indirect lightning
AdditiveIlluminationLevel=(0..100) lightening of dark areas by indirect lightning
UseAmbientOcclusion=(0,1) allow darkening of nearest objects (temporary disabled)
UseIndirectLightning=(0,1) compute indirect lightning (affect performance)

[COLORCORRECTION]
DarkeningAmountDay=(-100..100) how much to dark or to bright dark screen areas at day time. Negative values makes brighter, positive darker.
ScreenLevelDay=(0..100) level of screen brightness in percents, that determined as day time.
ScreenLevelNight=(0..100) level of screen brightness in percents, that determined as night time.
DarkeningAmountNight=(-100..100) how much to dark or to bright dark screen areas at night time. Negative values makes brighter, positive darker. Positive values recommended for more natural nights.
GammaCurveDay=(-10..10) gamma correction of bloom at day time. negative values increases halftone brightness (pale image), positive values decrease halftones brightness (contrast, intensive image).
GammaCurveNight=(-10..10) gamma correction of bloom at night time. negative values increases halftone brightness (pale image), positive values decrease halftones brightness (contrast, intensive image).

[PLUGIN]
WeatherMod=(0,1) activates color correction for Weather Mod installed, choosed by it's author. Temporary disabled.

[WATER]
UseWaterDeep=(0,1) use smooth transition between different deep levels.
WaterDeepness=(0..1000) factor of water semitransparencity at difference deep levels.
WaterQuality=(0..2) quality of water effects, 0 means maximal quality.

[SHADOW]
ShadowFadeStart=(0..1000) distance, at which shadow starts to be less intensive.
ShadowFadeEnd=(0..1000) distance at which shadow dissapear completely.
ShadowAmountDay=(0..100) percent of shadows intencity in the day.
ShadowAmountNight=(0..100) percent of shadows intencity in the night.
ShadowScreenLevelDay=(0..100) level of screen brightness in percents, that determined as day time.
ShadowScreenLevelNight=(0..100) level of screen brightness in percents, that determined as night time.
ShadowQuality=(0..2) quality of shadows, 0 is maximal and slowest.
UseShadowFilter=(0,1) enable filtering of shadows
FilterQuality=(0..2) quality of shadows filtering, 0 is maximal and slowest

[ENGINE]
ForceAnisotropicFiltering=(0,1) force to use anisotropic filtering for most game textures.
MaxAnisotropy=(1..16) maximal level of anisotropy filtering, greater values makes more sharp textures at low angles.
ForceDisplayRefreshRate=(0,1) force to use user defined reflresh rate.
DisplayRefreshRateHz=(60..240) custom monitor reflresh rate. Warning, incorrect use of this parameter may corrupt you display! (or what you are using)

[MOTIonblur]
MotionblurQuality=(0..2) sampling quality, 0 means maximal quality
MotionblurVelocity=(0..100) factor of movement vector length in forward or backward
MotionblurRotation=(0..100) factor of movement to sides and rotation, recommended the same as MotionblurVelocity


Key numbers (virtual key codes) available in key_codes.txt or key_codes.htm. In current version of the mod these lists of key codes are hex values, but mod works with decimal, i can't describe now how to convert them, may be later i'll do something.

PROBLEMS SOLVING:
Q: Mod installed, but i don't see any difference.
A: After game start mod is not activated, turn it on by hotkeys (by default SHIFT F12).
Q: When activating the mod, image makes black (objects near the camera).
A: Your videocard not support antialiasing of HDR textures, disable antialiasing in the game and in display driver control panel. Also try to set AllowAntialias=0, BugFixMode=1 or 5, AlternativeDepth=0, if not helps, disable ambient occlusions EnableOcclusion=0.
Q: Computer not responding when mod activated.
A: Perhaps video drivers too old or too new, for example forceware 169.xx and higher (171.xx last tested) working incorrectly woth some HDR textures, use older drivers (162.xx, 163.xx). Also try to change BugFixMode and disable ambient occlusions EnableOcclusion=0.
Q: Car reflections sometimes hiding and flickering.
A: For some videocards you need to set ReflectionDepthBias value to something about 100, depending from hardware. This problem was found on Radeon 2xxx.
Q: From far distance interier and wheels becomes overlapped visible through car.
A: Value of ReflectionDepthBias is too high or it's not required for your videocard.
Q: I have integrated onboard videochip and mod not works.
A: Perhaps video memory size is too small for display resolution you are playing, decrease it or in bios setting increase video memory size (typically values from 16 to 128 Mb).
Q: At high resolutions and antialiasing mod not works.
A: Not enough video memory.

#4 brr

brr

    a GPL editor

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,244 posts
  • Gender:Male
  • Sim interest:GPL

Posted Jan 07 2010 - 02:27 AM

miklkit said:

Are you saying that GPL uses a system so different that it needs a complete re engineering before it can be upgraded?

Yes, if the upgrade is going to make any significant difference.

#5 Bernd Nowak

Bernd Nowak

    Denny Hulme

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,726 posts
  • Gender:Male
  • Sim interest:GPL

Posted Jan 07 2010 - 03:14 AM

miklkit,
as far as I know and Nigel and brr have tried to explain it to me the difference is that the GPL.exe is doing the calculations of all the 3D stuff and sends a more or less 'flat' picture to the graphic card. Sure some DX7 or OpenGL features are used but not to the degree todays games use the DX or OpenGL api. The GPL.exe is doing the most of the work.

This is the reason why brr talks about redoing all of the graphics stuff. I know that he has a lot of knowledge and maybe the right one to identify the code sections in GPL and substitute them but it's so much work that I'm not sure if he really feels that the amount of work is really worth to do it.

When I first had some contact with the rasterisers and talked with Nigel about it I felt like you and thought that it might be possible to really do something but over the months with Nigel, brr and ntoxcated I noticed the strict abstraction Papy used back in the days. Remember that a 3DFX card was a major 3D card and had very limited 3D function. Same for OpenGL and DX7. So Papy took all 3 and created a intersection of functions which all rasterisers supported somehow and used different rasteriser calls for the end graphic cards and did calculate the rest inside GPL.

At least this is my knowledge and guys like Nigel, brr or ntoxcated can explain it much better then me :)

#6 brr

brr

    a GPL editor

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,244 posts
  • Gender:Male
  • Sim interest:GPL

Posted Jan 07 2010 - 03:46 AM

View PostBernd Nowak, on Jan 7 2010, 11:14 AM, said:

This is the reason why brr talks about redoing all of the graphics stuff. I know that he has a lot of knowledge and maybe the right one to identify the code sections in GPL and substitute them but it's so much work that I'm not sure if he really feels that the amount of work is really worth to do it.

I decided to totally ignore the GPL graphics stuff and write everything from scratch. Its actually less work (I hope) this way, since the new code does not have to "interface" with the old. The only thing that needs to be done with GPL graphics code is to figure out how to stop it from running while the rest of the sim still runs normally :D As an additional benefit, the graphics can run at any fps regardless of GPL physics.

Quote

At least this is my knowledge and guys like Nigel, brr or ntoxcated can explain it much better then me :)

Your explanation is pretty much how I understand the situation. GPL chews things down to the level of sending 2D polygons to the rasterisers. There is not much point in writing a DirectX11 renderer to draw 2D polygons.

#7 miklkit

miklkit

    airhead

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,137 posts
  • Gender:Male
  • Location:left coast, U.S.A.
  • Interests:GPL
  • Sim interest:GPL

Posted Jan 07 2010 - 11:21 AM

Ahh.  I was confusing rasterizers with renderers.  Thank you for the clarification.  

I dl'ed that doodad.  It is a tiny little thing that adds effects to the game.  It also delivers a 10-15fps hit.  It's worthwhile in that other game, but I'm not sure it would add anything to GPL.  I would have to create another GPL to install it into to find out.

#8 Jim Pearson

Jim Pearson

    Denny Hulme

  • Supporter
  • PipPipPipPipPipPipPipPipPipPip
  • 258 posts
  • Gender:Male
  • Location:Down Under
  • Interests:Trackmaking, Bike Road Racing, Links Golf, Long Distance Walking.
  • Sim interest:GPL

Posted Jan 08 2010 - 06:14 AM

This is an interesting subject, worth investigating.

There could be some gameplay or FPS benefits, however there is one issue that affects me and other trackmakers' past and present work.

In a DX7 game like GPL all shading, except for surface vertex shading by track section, is produced manually and quite laboriously using variations in texture darkness and hue. Eg; the sides of a building may have up to three different "darkness" levels to depict a static light and shade/time of day. Add variable shading through DX9 coding to those tracks and you will probably diminish the realism/immersion in them, rather than enhance it. Two different and possibly counteractive shading methods operating at the same time you see!

Additionally, how would shading operate on rotating SRB objects like trees and many other objects in GPL?These are quite different 3do's to the static ones used in most other sims. As a personal observation, the DX9 shading on trees depicted in almost all other sims looks atrocious and usually way too dark/contrasty light side to shady side. rFactor is a case in point.

Not a criticism of the general idea, just some observations to consider.

#9 brr

brr

    a GPL editor

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,244 posts
  • Gender:Male
  • Sim interest:GPL

Posted Jan 08 2010 - 06:32 AM

I don't think it makes sense to write a DirectX11 renderer with the design goal of using exactly the same track graphics as before. The data contained in the track files is not technically speaking detailed enough to make good use of the possibilities. Things can be updated as necessary, and those who prefer the old graphics can keep using the current rasterisers.

#10 sky

sky

    ultra highres junkie & 917 addict

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,550 posts
  • Gender:Male
  • Location:the last haven for petrolheads
  • Interests:travel, music, racing, vintage cars, model cars
  • Sim interest:GPL

Posted Jan 08 2010 - 01:34 PM

please brr, do it! just reading you're thinking of doing that. awesome! any support you need i could provide.. just ask. the best simulator ever with up to par graphics and maybe sound - as you seem to have thought about that too - in another thread. incredible awesomeness ensues

#11 Rudy Dingemans

Rudy Dingemans

    Denny Hulme

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 873 posts
  • Gender:Male
  • Location:Netherlands
  • Sim interest:GPL

Posted Jan 08 2010 - 02:24 PM

I think Jim and brr are saying that while you could (laboriously) rewrite the gfx routines, the result wouldn't necessarily look better.... unless, at the very least, you'd rewrite the entire GPL track and environment as well.

Regards, Rudy
(GPLRank: -40)

#12 brr

brr

    a GPL editor

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,244 posts
  • Gender:Male
  • Sim interest:GPL

Posted Jan 08 2010 - 02:41 PM

View PostRudy Dingemans, on Jan 8 2010, 10:24 PM, said:

I think Jim and brr are saying that while you could (laboriously) rewrite the gfx routines, the result wouldn't necessarily look better.... unless, at the very least, you'd rewrite the entire GPL track and environment as well.

The track geometry can be reused but textures need to be redone, although old ones could be converted. Writing the code is not that laborious since I already have some sort of test version running. Its far from finished, but it demonstrates its possible to reimplement the graphics.

Edited by brr, Jan 08 2010 - 02:52 PM.


#13 Jim Pearson

Jim Pearson

    Denny Hulme

  • Supporter
  • PipPipPipPipPipPipPipPipPipPip
  • 258 posts
  • Gender:Male
  • Location:Down Under
  • Interests:Trackmaking, Bike Road Racing, Links Golf, Long Distance Walking.
  • Sim interest:GPL

Posted Jan 08 2010 - 05:15 PM

A lot of care goes into making DX7 graphics look good in GPL.

Its very easy to say "lets just change the graphics" but that may require a great deal of time and effort.

It certainly would be possible to rework the necessary textures in any GPL track to remove any manual shading variations, in order that DX9/10/11 shaders can do their job exclusively without conflicts. You would probably need to recompile some tracks to remove vertex shading as well.

Question is, are the original trackmakers still around to perform all that work?

Would they be prepared to do it?

You might write code to do all sorts of things in GPL, but you cant write code to selectively modify textures.

There is probably 6 months worth of solid 9 -5 work just in the shading variations of textures in my present GPL project.

Not interested at all in scrapping that and starting again to make the track look ok in DX9!

But hey, thats just me. :thumbup:

Edited by Jim Pearson, Jan 08 2010 - 05:33 PM.


#14 brr

brr

    a GPL editor

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,244 posts
  • Gender:Male
  • Sim interest:GPL

Posted Jan 09 2010 - 01:51 AM

View PostJim Pearson, on Jan 9 2010, 01:15 AM, said:

It certainly would be possible to rework the necessary textures in any GPL track to remove any manual shading variations, in order that DX9/10/11 shaders can do their job exclusively without conflicts. You would probably need to recompile some tracks to remove vertex shading as well.

Question is, are the original trackmakers still around to perform all that work?

Would they be prepared to do it?

I know that all original trackmakers are not still around nor prepared to update their tracks, but some probably are. Tracks are often updated by other people than the trackmaker, and new tracks are still being made.

From the technical point of view, this is probably much simpler than you think. I don't use the original track format at all, so no need to recompile any tracks or worry about the complex file formats.

Quote

Not interested at all in scrapping that and starting again to make the track look ok in DX9!

But hey, thats just me. :thumbup:

That's why I said "those who prefer the old graphics can keep using the current rasterisers".

#15 Jim Pearson

Jim Pearson

    Denny Hulme

  • Supporter
  • PipPipPipPipPipPipPipPipPipPip
  • 258 posts
  • Gender:Male
  • Location:Down Under
  • Interests:Trackmaking, Bike Road Racing, Links Golf, Long Distance Walking.
  • Sim interest:GPL

Posted Jan 09 2010 - 02:28 AM

ERR The issues I'm concerned about have nothing to do with "track formats" but everything to do with existing track texturingand vertex shading.

Beyond those issues though, I cant yet understand the true value of GPL in a DX9 environment. There seems to be the usual assumption that anything more modern must be better for GPL.

In EXACTLY what way?

How will a track look better, SPECIFICALLY?

What will DX9 do for Clermont Ferrand? or Targa? What happens when the care taken with lighting effects in those tracks just disapears or is corrupted by DX9 lighting?

How are shadows on objects to be treated? Will they really be an improvement, or just bugger everything up like rFactor? Even the shadows on natural objects in the upcoming rFactor2 screens are completely unnatural using the most modern DX.

Theoretically, yes pople can chose to opt in or out of newer rasturisers, but the reality is rather different. Only a very small fraction of GPL people will read these posts, but the majority will follow new , so called "enhancements", download, install then forget about them.

If DX9 rasturisers do corrupt the visual experience of many existing tracks, GPL people wont remember to switch back and forth between existing Rasturisers for selected tracks, or wont be bothered.

What they may do is just leave GPL because its suddenly looks bad, or worse than they remembered.

IMO there are some enhancements like the long tracks patch and 60fps patch that are true enhancements, despite the imperfect AI.

Other "improvements" through modernisation may be illusory and counter productive.

So, lets see some good old fashioned evidence by way of comparative AVI video, before anything purported to be "better" along these lines, is released.

#16 brr

brr

    a GPL editor

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,244 posts
  • Gender:Male
  • Sim interest:GPL

Posted Jan 09 2010 - 02:51 AM

View PostJim Pearson, on Jan 9 2010, 10:28 AM, said:

ERR The issues I'm concerned about have nothing to do with "track formats" but everything to do with existing track texturingand vertex shading.

Beyond those issues though, I cant yet understand the true value of GPL in a DX9 environment. There seems to be the usual assumption that anything more modern must be better for GPL.

In EXACTLY what way?

There is not just an empty assumption that DirectX11 renderer can make GPL graphics look better. Textures can use better colours, performance improvement probably allows higher resolution textures, its possible to do better shading by updating textures to support it, car surfaces can have reflections, material shininess can be controlled per-pixel, there could be proper shadows, better smoke/fire/rain/debris etc... These are some of the potential improvements which are not possible with current graphics.

Quote

What happens when the care taken with lighting effects in those tracks just disapears or is corrupted by DX9 lighting?

It remains to be seen, since I have not yet written a converter for existing tracks.

Quote

How are shadows on objects to be treated? Will they really be an improvement, or just bugger everything up like rFactor? Even the shadows on natural objects in the upcoming rFactor2 screens are completely unnatural using the most modern DX.

Shadows are generally a performance issue. They can be done well, but I might skip shadows if its too demanding on performance.

Quote

So, lets see some good old fashioned evidence by way of comparative AVI video, before anything purported to be "better" along these lines, is released.

Videos will be posted when I have a properly updated track section and a car model, and the renderer is developed enough to make good use of them. I will use my own judgement about release, otherwise it would not make sense for me to work on the renderer.

#17 MECH

MECH

    Double poly killer

  • Administrators
  • PipPipPipPipPipPipPipPipPipPip
  • 2,408 posts
  • Gender:Male
  • Location:Here ->
  • Interests:My Girlfriend
  • Sim interest:GPL

Posted Jan 09 2010 - 05:10 AM

Will a rewrite of this DX code improve the current lack of GPL to handle heavy poly cars?

Most of the new mods of cars with covered wheels (GT67, GT64, Canam 71 & 66) are rather heavy polywise.
V2 rasterizers are a big improvement but having 19 cars on the grid still needs a fast cpu with lots of base memory.  :hmm:

I know we can reduce some of the memory usage using 3do's that have been stripped from back view poly's.
But up to this point it still requires a cpu of current standards which more or less reduces the number of people that can drive the mod in it's full glory.

I have a Pentium 4 3GHz with 1GB ram and more or less can drive the current mods (this is without having improved total loading memory of the carset) although adding more base memory probably would improve the fps.

#18 brr

brr

    a GPL editor

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,244 posts
  • Gender:Male
  • Sim interest:GPL

Posted Jan 09 2010 - 05:24 AM

View PostMECH, on Jan 9 2010, 01:10 PM, said:

Will a rewrite of this DX code improve the current lack of GPL to handle heavy poly cars?

Most of the new mods of cars with covered wheels (GT67, GT64, Canam 71 & 66) are rather heavy polywise.
V2 rasterizers are a big improvement but having 19 cars on the grid still needs a fast cpu with lots of base memory.  :hmm:

I know we can reduce some of the memory usage using 3do's that have been stripped from back view poly's.
But up to this point it still requires a cpu of current standards which more or less reduces the number of people that can drive the mod in it's full glory.

I have a Pentium 4 3GHz with 1GB ram and more or less can drive the current mods (this is without having improved total loading memory of the carset) although adding more base memory probably would improve the fps.

As with everything else, I am writing the renderer based on unmodded gpl.exe so have no idea what it would take to adapt it to mods. But it will shift certain per-vertex computations from CPU to GPU, which makes these computations more efficient.

#19 miklkit

miklkit

    airhead

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,137 posts
  • Gender:Male
  • Location:left coast, U.S.A.
  • Interests:GPL
  • Sim interest:GPL

Posted Jan 09 2010 - 02:02 PM

I tried the little gizmo, and it probably didn't work in GPL.  Oh well.  

When I play a "modern" game I turn off all the bloom and hdr stuff.  It makes the bright stuff too bright and the dark stuff too dark.  Methinks Targa Florio in DX11 with all that turned on would look garish with no subtlety at all to the colors.  But with it all turned off it would look about the same.  That is based on my experiences with GPL tracks in DX9 games.  Try Jops Siffert in GPL and then P&G.  They can look similar, except for the horizon.

The main advantage to DX11 that I have been hearing is that it is more efficient than previous versions.  For GPL, this sounds like more bang for your buck.  Or a higher poly count with less system drag.  I have tried out games that are supposedly only for 64bit systems and top end equipment that don't push my rig as hard as GPL does.  This means that full body cars would be in the reach of most everyone.  Would this also mean that it would be much easier to build full body cars?   I seem to recall the modders talking about how much easier it would be to create cars in a different environment.

#20 brr

brr

    a GPL editor

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,244 posts
  • Gender:Male
  • Sim interest:GPL

Posted Jan 09 2010 - 02:12 PM

View Postmiklkit, on Jan 9 2010, 10:02 PM, said:

Would this also mean that it would be much easier to build full body cars?   I seem to recall the modders talking about how much easier it would be to create cars in a different environment.

Though I don't yet know much about 3do file format, it seems that its unnecessarily complicated for just rendering graphics. Maybe the difficulty of building cars is converting them to 3do. I would use a simpler file format which would probably be easy conversion target.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Sim Racing Links