Hover Strike CD Vector/Wireframe Mode - video anyone?

[Clint Thompson]

I never tried this cheat when I used to own the game but does anyone have a video of the vector mode in CD version of HS? I'm mostly interested in seeing it to satisfy curiosity sake.

 

 

Vector graphics mode Hold Up + A + B + C + 3 During Gameplay

 

[Gaztee]

I never tried this cheat when I used to own the game but does anyone have a video of the vector mode in CD version of HS? I'm mostly interested in seeing it to satisfy curiosity sake.

 

 

 

Vector graphics mode

 

Hold Up + A + B + C + 3 During Gameplay

 

 

Didn't know this existed, so just tried it out. It's different for sure. If I ever get my video capture sorted out I'll stick it up somewhere.

[+save2600]

Sounds cool! Will have to give it a try later. What could have been Battlezone 2000.

 

Hopefully, with the wireframe model, you'd expect it to have a silky smooth frame rate...

[Gaztee]

Sounds cool! Will have to give it a try later. What could have been Battlezone 2000.

Hopefully, with the wireframe model, you'd expect it to have a silky smooth frame rate...

Don't go holding your breath for that silky frame rate

[Austin]

Hopefully, with the wireframe model, you'd expect it to have a silky smooth frame rate...

 

I recall trying this but don't recall the framerate being any better. Kind of a shame, haha.

[+Stephen]

Same thing here. I always heard that doing texture mapping on the Jag was terribly slow. I wonder why when turning it off, nothing sped up? There should have been a huge increase. Maybe it was for debugging and the only thing they did was not render the texture, while still doing the calculations?

[Chilly Willy]

In many games, beyond a certain point the main limit is the processing of independent entities. A great example of that are the Bethesda games - Oblivion, Fallout 3/NV, and Skyrim. Assuming you aren't trying to do graphics beyond what your PC can handle, the MAJOR slowdown is directly proportional to the number of NPCs in the loaded cells. So something like Populated Cities, which more than doubles the number of NPCs in Whiterun and other Skyrim cities, will make my PC bog down where using a high-res texture replacement and a higher res screen mode just drops the frame rate slightly.

 

For an older example, Doom is a good one. The difference between kiddy mode and nightmare is the number of bad guys. Most people found that their console/older pc slowed WAY down in nightmare mode, but it wasn't from DRAWING all the bad guys, but rather doing the bad guy "ai" logic. That was particularly the case for console ports of Doom.

[VladR]

Same thing here. I always heard that doing texture mapping on the Jag was terribly slow. I wonder why when turning it off, nothing sped up? There should have been a huge increase. Maybe it was for debugging and the only thing they did was not render the texture, while still doing the calculations?

Assuming we are talking about the difference between the Wireframe Cube(e.g. 12 lines) vs Fully-textured cube , the difference in the amount of cycles is easily 3-4 orders of magnitude (e.g. 1,000x - 10,000x more - depending on how big the cube is on screen - if the cube would be 4 pixels wide on the screen then the performance difference would be obviously negligible) and the precision/type of texturing that is being implemented.

 

If they however, did not bother to update the sync logic (across multiple frames), then the only real benefit here is that the GPU/DSP are not doing those calculations - e.g. the framerate is probably capped to avoid handling multiple corner cases. Far from impossible, but still a lot of additional work on the coder's side...

 

I believe that the best example of how expensive texturing is on Jag, would be a kind of demo that would allow you to adjust the number of visible cubes on screen and switch between various render modes (wireframe, solid, texturing). The demo would have no audio, no AI, just pure rendering.

 

Then, you could see that (following numbers are just as an example) 500 wireframe cubes give you same framerate as , say, 5 textured cubes.

 

Of course, the more cubes the scene would have, the smaller they would have to be, hence it would become skewed very soon anyway. So, it's not exactly straightforward to compare.

 

Generally, you could break down the cube rendering process into:

1. 3D Transformation of vertices

2. Face Visibility

3. Rasterization

 

If the cube is huge on screen, then first 2 steps might take 10% of the total cycles (as texturing would take quite some time), but if it is small (couple pixels), then those 2 steps would take 90% of all cycles (as there would be no texturing - just drawing the edges).

 

 

I was actually hoping to write similar kind of demo (using GPU/DSP) earlier this summer, but life took over... Maybe next year...