Re: GP3 Something wrong.

This is to simulate the movement of the car and the forces that are being exerted upon the driver. If you've ever driven a racing car, it is far from smooth and steady =) Cheers, ...Colin Jasper Conwright <[email hidden]> wrote in message news:4yYf5.470$[email hidden]... > Hi There > > I have just tryed GP3, but I think I have a problem. All other games Ihave > played the images on screen are sharp and steady, but with this game I geta

Quoted text (7 lines)

> wobbly picture. For example the cockpit sides seem to shake and move, and > the grass and walls seem to stretch sometimes. Is there a problem with my > graphics card (Voodoo 3 2000) or machine. If not why does it do this. > > JC > >

Yee of little faith =) Victor Chan <[email hidden]> wrote in message news:vTZf5.18635$[email hidden]... > Hah, he is referring to 3D artifacts like banding, aliasing, and"swimming" effects. > Without FSAA, this is what you get. You do get this artifacts in F1 2000too or, even > GPL under Glide. >

Hah, he is referring to 3D artifacts like banding, aliasing, and "swimming" effects. Without FSAA, this is what you get. You do get this artifacts in F1 2000 too or, even GPL under Glide.

Quoted text (20 lines)

> This is to simulate the movement of the car and the forces that are being > exerted upon the driver. > If you've ever driven a racing car, it is far from smooth and steady =) > Cheers, > ...Colin > > Hi There > > I have just tryed GP3, but I think I have a problem. All other games I > have > > played the images on screen are sharp and steady, but with this game I get > a > > wobbly picture. For example the***pit sides seem to shake and move, and > > the grass and walls seem to stretch sometimes. Is there a problem with my > > graphics card (Voodoo 3 2000) or machine. If not why does it do this. > > JC

Yee of little faith =)

Hi There I have just tryed GP3, but I think I have a problem. All other games I have played the images on screen are sharp and steady, but with this game I get a wobbly picture. For example the cockpit sides seem to shake and move, and the grass and walls seem to stretch sometimes. Is there a problem with my graphics card (Voodoo 3 2000) or machine. If not why does it do this. JC

Hah, he is referring to 3D artifacts like banding, aliasing, and "swimming" effects. Without FSAA, this is what you get. You do get this artifacts in F1 2000 too or, even GPL under Glide. "Colin" <[email hidden]> wrote in message news:8lpkm1$f16$[email hidden]...

Quoted text (23 lines)

> This is to simulate the movement of the car and the forces that are being > exerted upon the driver. > If you've ever driven a racing car, it is far from smooth and steady =) > Cheers, > ...Colin > > Jasper Conwright <[email hidden]> wrote in message > news:4yYf5.470$[email hidden]... > > Hi There > > > > I have just tryed GP3, but I think I have a problem. All other games I > have > > played the images on screen are sharp and steady, but with this game I get > a > > wobbly picture. For example the cockpit sides seem to shake and move, and > > the grass and walls seem to stretch sometimes. Is there a problem with my > > graphics card (Voodoo 3 2000) or machine. If not why does it do this. > > > > JC > > > > > >

Actually I don't think he is refering to those things. Various different parts of the 3d cockpit actually move in relation to each other, and they would still move with FSAA. Banding, aliasing and swimming are mainly texturing problems and don't effect the position of polygons. It could be a deliberate effect to simluate the vibration of the car (optimistic view) or it could be a lack of accuracy in the transformation code (realistic view), possibly because GC is still using integer maths. Victor Chan" <[email hidden]> wrote in message news:vTZf5.18635$[email hidden]... > Hah, he is referring to 3D artifacts like banding, aliasing, and"swimming" effects. > Without FSAA, this is what you get. You do get this artifacts in F1 2000too or, even > GPL under Glide.

On Thu, 27 Jul 2000 11:33:34 -0400, "Colin" <[email hidden]> thus spoke: >This is to simulate the movement of the car and the forces that are being >exerted upon the driver. >If you've ever driven a racing car, it is far from smooth and steady =) >Cheers,Yes, but when you are in a car you are moving *with* the car. Why can't some game developers grasp this concept? Your head will naturally compensate for this movement, not so when looking at a computer screen. Jane's did the same thing with their virtual cockpit in Longbow2 and where anal enough not to include an option to turn it off. Needless to say I never use the virtual cockpit in that game because of it. GP3 is not that bad at all in this area, but it still should have been made optional. But then that would have taken more time and money which of couse is a not cool with certain game publishers. -- Nos

On Fri, 28 Jul 2000 02:27:18 GMT, "Simon Brown" <[email hidden]> wrote: >Seem obvious that GP3 wasn't deigned with 3d cards in mind. I don't know >who did the 3d card support, whether it was Crammond or Microprose, but they >didn't do much of a job. Instead they pulled quite a lot of tricks with pseudo 3D. Did you notice that the wheels are completely made up of sprites? Except your own when you're using any of the car cameras, but they have those blocky reflections instead. Jan

On Thu, 27 Jul 2000 17:36:20 GMT, "Simon Brown" <[email hidden]> wrote: >It could be a deliberate effect to simluate the vibration of the car >(optimistic view) or it could be a lack of accuracy in the transformation >code (realistic view), possibly because GC is still using integer maths. I thinks it's just poor implementation of the 3D support. It seems like the game doesn't properly use perspective correction, that why the textures happen to "swim" or get otherwise distorted when the view point changes. And in the virtual cockpit it changes all the time, hence the textures are jiggling around constantly. Then there are the problems with the Z-buffer ... quite obvious that they implemented the 3D support only because they "had to", not with the intention of taking advantage of it. That's IMO, of course. :-) Blaze

Are you sure? I thought those are 3D effects for simulating a car traveling at 200 mph. :-) "Jan Loebzien" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (19 lines)

> On Thu, 27 Jul 2000 17:36:20 GMT, "Simon Brown" > <[email hidden]> wrote: > > >It could be a deliberate effect to simluate the vibration of the car > >(optimistic view) or it could be a lack of accuracy in the transformation > >code (realistic view), possibly because GC is still using integer maths. > > I thinks it's just poor implementation of the 3D support. > It seems like the game doesn't properly use perspective correction, > that why the textures happen to "swim" or get otherwise distorted > when the view point changes. And in the virtual cockpit it changes > all the time, hence the textures are jiggling around constantly. > Then there are the problems with the Z-buffer ... quite obvious that > they implemented the 3D support only because they "had to", not > with the intention of taking advantage of it. > > That's IMO, of course. :-) > > Blaze

I think the main problem with the z-buffer is that there isn't one! :) Also, i've also noticed that perspective correction is turned off on a lot of textures like you say. This is just bizarre. Modern 3D cards can do perspective-correct texture mapping on every polyon and z or w buffering with a very small performance penalty, like 10%. Also these features are both in just about ever game that's been released for the last two years. Seem obvious that GP3 wasn't deigned with 3d cards in mind. I don't know who did the 3d card support, whether it was Crammond or Microprose, but they didn't do much of a job. "Jan Loebzien" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (19 lines)

> On Thu, 27 Jul 2000 17:36:20 GMT, "Simon Brown" > <[email hidden]> wrote: > > >It could be a deliberate effect to simluate the vibration of the car > >(optimistic view) or it could be a lack of accuracy in the transformation > >code (realistic view), possibly because GC is still using integer maths. > > I thinks it's just poor implementation of the 3D support. > It seems like the game doesn't properly use perspective correction, > that why the textures happen to "swim" or get otherwise distorted > when the view point changes. And in the virtual cockpit it changes > all the time, hence the textures are jiggling around constantly. > Then there are the problems with the Z-buffer ... quite obvious that > they implemented the 3D support only because they "had to", not > with the intention of taking advantage of it. > > That's IMO, of course. :-) > > Blaze

On Fri, 28 Jul 2000 02:27:18 GMT, "Simon Brown" <[email hidden]> wrote: >I think the main problem with the z-buffer is that there isn't one! :) And to think these things today are for free! :(

Quoted text (9 lines)

>Also, i've also noticed that perspective correction is turned off on a lot >of textures like you say. This is just bizarre. Modern 3D cards can do >perspective-correct texture mapping on every polyon and z or w buffering >with a very small performance penalty, like 10%. > Also these features are >both in just about ever game that's been released for the last two years. >Seem obvious that GP3 wasn't deigned with 3d cards in mind. I don't know >who did the 3d card support, whether it was Crammond or Microprose, but they >didn't do much of a job.

The 'About' thingy shows just 4 people, amongst which 1 did the hardware 3D programming. I REALLY don't know why Crammond bothered to do the software 3D programming bit. It is NOT rewarding, since NO-ONE would want to use that anymore. Besides, D3D will emulate it for him if no h/w is detected. Why bother these days. Silly.

Quoted text (22 lines)

>"Jan Loebzien" <[email hidden]> wrote in message >news:[email hidden]... >> On Thu, 27 Jul 2000 17:36:20 GMT, "Simon Brown" >> <[email hidden]> wrote: >> >> >It could be a deliberate effect to simluate the vibration of the car >> >(optimistic view) or it could be a lack of accuracy in the transformation >> >code (realistic view), possibly because GC is still using integer maths. >> >> I thinks it's just poor implementation of the 3D support. >> It seems like the game doesn't properly use perspective correction, >> that why the textures happen to "swim" or get otherwise distorted >> when the view point changes. And in the virtual cockpit it changes >> all the time, hence the textures are jiggling around constantly. >> Then there are the problems with the Z-buffer ... quite obvious that >> they implemented the 3D support only because they "had to", not >> with the intention of taking advantage of it. >> >> That's IMO, of course. :-) >> >> Blaze >

Ruud van Gaal, GPL Rank +53.53 MarketGraph / MachTech: http://www.marketgraph.nl Art: http://www.marketgraph.nl/gallery

On Thu, 27 Jul 2000 16:29:18 +0100, "Jasper Conwright" <[email hidden]> wrote:

Quoted text (10 lines)

>Hi There > >I have just tryed GP3, but I think I have a problem. All other games I have >played the images on screen are sharp and steady, but with this game I get a >wobbly picture. For example the cockpit sides seem to shake and move, and >the grass and walls seem to stretch sometimes. Is there a problem with my >graphics card (Voodoo 3 2000) or machine. If not why does it do this. > >JC >

I have a Diamond Viper V770 with the latest drivers,and no it's not your car...in fact I think it is the Insane Dev Team were nervous as they did this...hehe

> > It could be a deliberate effect to simluate the vibration of the car > (optimistic view) or it could be a lack of accuracy in thetransformation > code (realistic view), possibly because GC is still using integermaths. > I'm not alone!! I have a STRONG suspision that we we are seeing is thr result of GC having his head in the sand for 5 years and STILL using integer maths for his graphics engine. Now this made sense 5 years ago but floating point maths is now way faster than pure integer. I doubt GC is even using vector code optimised for PIII,Athalon etc. Which, by the way, is a piece of cake to achieve. I hope for sanity that Microprose re-write the graphics engine from the ground up. The use of integer values (which would have to converted to pass to DX7 anyway!!) could result in the shifting textures/objects and the wierd joins between the textures :( Sent via Deja.com http://www.deja.com/ Before you buy.

I think it's GC all over! The Z-buffer could well only be a low-res - hence the crap depth problems. I think he has never heard if mip-maps either! The gravel and crowd textures shimmer horribly Geoff needs a hardware enima to get him going... In article <ac6g5.3196$[email hidden]>, "Simon Brown" <[email hidden]> wrote: > I think the main problem with the z-buffer is that there isn't one! :) > Also, i've also noticed that perspective correction is turned off ona lot > of textures like you say. This is just bizarre. Modern 3D cards cando > perspective-correct texture mapping on every polyon and z or wbuffering > with a very small performance penalty, like 10%. Also these featuresare > both in just about ever game that's been released for the last twoyears. > Seem obvious that GP3 wasn't deigned with 3d cards in mind. I don'tknow > who did the 3d card support, whether it was Crammond or Microprose,but they > didn't do much of a job. > Sent via Deja.com http://www.deja.com/ Before you buy.

I'm all in favour of optimisation but when it comes to port to modern 3d\hardware the end results don't do the game justice. I'm sure that GP3 performance is suffering with hardware 3D because the software engine is over-optimised. COnverting all those int to floating point texture co-ords, polygon co-ord and depth values is taking it's toll on GP3's realism, looks and speed. IMO :) In article <[email hidden]>, [email hidden] wrote: > As a programmer (C, C++, 68k assembler) in my RL day job I can't > disagree with you more, reason follows: > > 'optimising' compilers do not optimise in the same way that writing > 'pure' machine code does, Most optimise to compensate for the severe > 'overhead' and redundancy that modern API's add to code, which meanthat > they are optimised 'relative' to how they would be if thisoptimisation > didn't occur, however these routines do not IN ANY WAY compare towhat a

Quoted text (16 lines)

> coder can do with code written from scratch. > > oh, and BTW, to the ppl deriding GC's use of Integer math, Yes FPU's > have improved, but are STILL a long way from acheiving the performance > needed, > IIRC Quake II was entirely Integer calc based too. > > Alan > > Richard G Clegg wrote: > > > > rrevved <[email hidden]> wrote: > > : On Sun, 30 Jul 2000 22:07:16 GMT, [email hidden] wrote: > > > > :>I doubt GC is even using vector code > > :>optimised for PIII,Athalon etc. Which, by the way, is a piece of

cake > > :>to achieve. > > > > : In assembler language? Thats what he uses. > > > > Surely not - in this day and age it's not even efficient.Optimising > > compilers are better than hand optimised assembly language anyway.I > > don't believe GC is using assembler now. For GP2 it wouldn't makeMUCH

Quoted text (8 lines)

> > sense. For GP1 it's maybe just about a reasonable decision. > > > > -- > > Richard G. Clegg Only the mind is waving > > Networks and Non-Linear Dynamics Group > > Dept. of Mathematics, Uni. of York > > UPDATED WWW: http://manor.york.ac.uk/ >

Sent via Deja.com http://www.deja.com/ Before you buy.

rrevved <[email hidden]> wrote: : On Sun, 30 Jul 2000 22:07:16 GMT, [email hidden] wrote: :>I doubt GC is even using vector code :>optimised for PIII,Athalon etc. Which, by the way, is a piece of cake :>to achieve. : In assembler language? Thats what he uses. Surely not - in this day and age it's not even efficient. Optimising compilers are better than hand optimised assembly language anyway. I don't believe GC is using assembler now. For GP2 it wouldn't make MUCH sense. For GP1 it's maybe just about a reasonable decision. -- Richard G. Clegg Only the mind is waving Networks and Non-Linear Dynamics Group Dept. of Mathematics, Uni. of York UPDATED WWW: http://manor.york.ac.uk/

As a programmer (C, C++, 68k assembler) in my RL day job I can't disagree with you more, reason follows: 'optimising' compilers do not optimise in the same way that writing 'pure' machine code does, Most optimise to compensate for the severe 'overhead' and redundancy that modern API's add to code, which mean that they are optimised 'relative' to how they would be if this optimisation didn't occur, however these routines do not IN ANY WAY compare to what a coder can do with code written from scratch. oh, and BTW, to the ppl deriding GC's use of Integer math, Yes FPU's have improved, but are STILL a long way from acheiving the performance needed, IIRC Quake II was entirely Integer calc based too. Alan Richard G Clegg wrote:

Quoted text (20 lines)

> > rrevved <[email hidden]> wrote: > : On Sun, 30 Jul 2000 22:07:16 GMT, [email hidden] wrote: > > :>I doubt GC is even using vector code > :>optimised for PIII,Athalon etc. Which, by the way, is a piece of cake > :>to achieve. > > : In assembler language? Thats what he uses. > > Surely not - in this day and age it's not even efficient. Optimising > compilers are better than hand optimised assembly language anyway. I > don't believe GC is using assembler now. For GP2 it wouldn't make MUCH > sense. For GP1 it's maybe just about a reasonable decision. > > -- > Richard G. Clegg Only the mind is waving > Networks and Non-Linear Dynamics Group > Dept. of Mathematics, Uni. of York > UPDATED WWW: http://manor.york.ac.uk/

Alan <[email hidden]> wrote: : As a programmer (C, C++, 68k assembler) in my RL day job I can't : disagree with you more, reason follows: : 'optimising' compilers do not optimise in the same way that writing : 'pure' machine code does, Most optimise to compensate for the severe : 'overhead' and redundancy that modern API's add to code, which mean that : they are optimised 'relative' to how they would be if this optimisation : didn't occur, however these routines do not IN ANY WAY compare to what a : coder can do with code written from scratch. Have you ever heard the saying "premature optimisation is the root of all evil" - most coders I know including assembly language programmers accept that a well optimised C program is faster than a well optimised assembler program simply coz the C compiler will kno when to unroll a loop and similar. A lot of people waste a lot of time coding assembler under the mistaken belief it is more efficient. It can be - for some things. In the general case, however, a well written C program will almost always be faster. The stuff about APIs is totally irrelevant - leads me to think you're a windows programmer. : oh, and BTW, to the ppl deriding GC's use of Integer math, Yes FPU's : have improved, but are STILL a long way from acheiving the performance : needed, : IIRC Quake II was entirely Integer calc based too. Integer math is faster if you can get away with it - but notby much. It's dumb to go out of your way to limit all float ops - but reduce them to a minimum sure. -- Richard G. Clegg Only the mind is waving Networks and Non-Linear Dynamics Group Dept. of Mathematics, Uni. of York UPDATED WWW: http://manor.york.ac.uk/

On Sun, 30 Jul 2000 22:10:46 GMT, [email hidden] wrote:

Quoted text (9 lines)

>I think it's GC all over! > >The Z-buffer could well only be a low-res - hence the crap depth >problems. > >I think he has never heard if mip-maps either! The gravel and crowd >textures shimmer horribly > >Geoff needs a hardware enima to get him going...

According to the credits, GC was doing the software graphics (he must have had some spare time or something to do such an unnecessary thing), and the hw gfx were done by a 2nd programmer. Who should've first programmed some SGI's to see how it's done.

Quoted text (23 lines)

>In article <ac6g5.3196$[email hidden]>, > "Simon Brown" <[email hidden]> wrote: >> I think the main problem with the z-buffer is that there isn't one! :) >> Also, i've also noticed that perspective correction is turned off on >a lot >> of textures like you say. This is just bizarre. Modern 3D cards can >do >> perspective-correct texture mapping on every polyon and z or w >buffering >> with a very small performance penalty, like 10%. Also these features >are >> both in just about ever game that's been released for the last two >years. >> Seem obvious that GP3 wasn't deigned with 3d cards in mind. I don't >know >> who did the 3d card support, whether it was Crammond or Microprose, >but they >> didn't do much of a job. >> > > >Sent via Deja.com http://www.deja.com/ >Before you buy.

Ruud van Gaal, GPL Rank +53.53 MarketGraph / MachTech: http://www.marketgraph.nl Art: http://www.marketgraph.nl/gallery

Richard G Clegg wrote:

Quoted text (7 lines)

> > Have you ever heard the saying "premature optimisation is the root > of all evil" - most coders I know including assembly language > programmers accept that a well optimised C program is faster than a well > optimised assembler program simply coz the C compiler will kno when to > unroll a loop and similar.

Heh. Yeah, but i'm sure that I can find a thousand and one posts on usenet saying the counter :) (this argument is as divided as the current gp3 vs. gpl) > however, a well written C > program will almost always be faster. Sorry, have to agree to disgree here. > The stuff about APIs is totally irrelevant - leads me to think you're > a windows programmer. Hehe, nope, *nix console C++ and oracle/sql programmer these days. Used the API term because wasn't sure what platform your/your friends experience was in, could have easily said shared library but went for the lowest common denominator ;) > Integer math is faster if you can get away with it - but notby much. Not by much is still faster IMHO (but ONLY when done right) Alan.

Alan <[email hidden]> wrote: : Richard G Clegg wrote: :> Have you ever heard the saying "premature optimisation is the root :> of all evil" - most coders I know including assembly language :> programmers accept that a well optimised C program is faster than a well :> optimised assembler program simply coz the C compiler will kno when to :> unroll a loop and similar. : Heh. Yeah, but i'm sure that I can find a thousand and one posts on : usenet saying the counter :) (this argument is as divided as the current : gp3 vs. gpl) (Grin) Now c'mon the GP3 vs GPL argument isn't that divided. The GP3 vs punch in the face argument is divided. :> however, a well written C :> program will almost always be faster. : Sorry, have to agree to disgree here. I agree. :> The stuff about APIs is totally irrelevant - leads me to think you're :> a windows programmer. : Hehe, nope, *nix console C++ and oracle/sql programmer these days. Used : the API term because wasn't sure what platform your/your friends : experience was in, could have easily said shared library but went for : the lowest common denominator ;) In which case I apologise for the unwarranted abuse. Richard. -- Richard G. Clegg Only the mind is waving Networks and Non-Linear Dynamics Group Dept. of Mathematics, Uni. of York UPDATED WWW: http://manor.york.ac.uk/