Re: Polygon rendering speed

Mike,

Always a huge help as usual. The data arrive in a compressed format (which
surprisingly takes only an instant to decompress and read in -- less than a
hundredth of a second). Essentially I know the azimuth (a decimal value
between 0 and 360 degrees, the "width" of the pixels along that azimuth, and
the value at each of the 400 bins along that azimuth. Values of 0 are
ignored (as this is the color of the final transparency).

The problem is that the polygon coordinates have to be calculated for every
frame uniquely as the azimuth values and width can change subtlely due to
the hardware of the radar (tough to stop that gargantuan thing on a dime!).

Evan


"Mike D Sutton" <EDais@xxxxxxxx> wrote in message
news:OWeYyEhMGHA.536@xxxxxxxxxxxxxxxxxxxxxxx
<snip>
I guess my question is maybe I'm going about this the wrong way? I mean,
I'm
by no means interested in video game development, but how can these games
achieve 60 or 70 FPS rates with not only intense polygon rendering, but
all
the other bells and whistles associated with them (lighting, texturing,
etc..). Do the APIs I'm using utilize the graphics hardware in any way?
Does
it even matter?

I want to provide a very low overhead, yet totally optimized program. I'm
not sure what, if anything I'd gain from DirectX or other options
(especially with the learning curve also involved). I think I've done all
I
can, but 0.5-0.8 seconds to do nothing more than render a slew of 2D
4-sided
polygons seems quite a bit excessive to me (especially considering that
it's
a 3 GHz CPU and many of the program's users will have machines that are
far
far less powerful).

You could perform the polar coordinates mapping in a pixel shader in
DirectX which would be a lot faster than the
software only approach, this of course assumes that your user base has the
hardware available.
Do you have an example of the input data to produce the radar image in
your previous example? I'm guessing its a
370*400 buffer, and if this can be mapped easily to texture coordinates
as-is then you could use an even simpler DirectX
solution which wouldn't even require your to write any pixel shader code.
This would still give you _high_ performance
(since you only need to shift a new texture over to the card each 'frame')
and the learning curve would be fairly
minimal.
Let me know,

Mike


- Microsoft Visual Basic MVP -
E-Mail: EDais@xxxxxxxx
WWW: Http://EDais.mvps.org/




.

Relevant Pages

  • Re: Thoughts on remakes/compilations
    ... Like Soul Calibur, TTT originally ran on Namco System 12 ... pixelization and a low polygon count. ... made it higher res and texture filtered. ... but nobody's tauting them as the best looking game on the DC. ...
    (rec.games.video.sega)
  • Re: PS3 GPU is outdated
    ... In fact when the PS2 was announced with its 66 million ... This time though the PS3 uses PC graphics technology and can only be ... what exactly do you think a "polygon" ... I mean, most computer hardware is ...
    (comp.sys.ibm.pc.hardware.video)
  • Re: Integrating directshow video playback in a directx9 game engin
    ... software buffer to the texture as the formats are the same so I would ... system memory, but works purely on the hardware, saving a software lock/stall. ... advantage it offers unless you are using the DXVA and mixing features. ... engine works the video system is likely to work too with a small overhead. ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: Linux network layer
    ... Noone is forced to use X11. ... you were able to communicate with CGA/VGA/SVGA cards directly. ... Someone must have exchanged my hardware ... ... Use OpenGL instead of DirectX. ...
    (comp.sys.ibm.pc.demos)
  • Re: Cant get program to work on non-SDK computer.
    ... http://www.thezbuffer.com - News and information for Managed DirectX ... VertexBuffer vertexBuffer = null; ... Texture texture = null; ... public void OnCreateVertexBuffer ...
    (microsoft.public.win32.programmer.directx.managed)