von2 takes longer to boot and occasionally crashes at startup

[WarpedPolygon]

All versions take longer than usual to boot to the initializing screen. This is more so with recent versions of Supermodel. More often than not it crashes the emulator on startup. It does work after a few attempts. Nothing untoward in the log file.

[dukeeeey]

Hmm yeah I will investigate

[WarpedPolygon]

I have observed with recent versions that performance has gotten worse, which is to be expected. However, I think the recent performance hit and this issue could be related. Other games also take just a second or so extra to boot compared to older versions and sometimes hitch a little on boot. When looking at task manager Supermodel is maxed out while it's booting to the initializing screen for von2 and windows running super slow when it's doing so.

I'm not an expert but thought I'd share my observations.

[dukeeeey]

I think the issue is part of the startup sequence of the program. We are rendering a whole bunch of stuff that should not be drawn. It's calling about 10k opengl calls per frame during the startup period which is very high. I am guessing this started to show up with the new culling code but I am not certain.

[WarpedPolygon]

I think the issue is part of the startup sequence of the program. We are rendering a whole bunch of stuff that should not be drawn. It's calling about 10k opengl calls per frame during the startup period which is very high. I am guessing this started to show up with the new culling code but I am not certain.

that sounds about right and would explain my observations with initial boots/startups. Would this also impact general in game performance?

[dukeeeey]

No once the games are running they should be the same speed, except the triangle renderer which might be up to 20% slower with latest commits

[WarpedPolygon]

No once the games are running they should be the same speed, except the triangle renderer which might be up to 20% slower with latest commits

Cool. I only use Quad to be honest. Thanks for getting back to me so fast. Hope I managed to help in some way. If you need me to test anything just let me know.

[gm-matthew]

This slowdown occurs because during boot the game is trying to render the same model at the camera location 512 times.

The closer a model is to the camera, the longer it takes to draw because the polygons are larger on-screen and therefore more pixels need to be filled in. Trying to render a model at the same position as the camera 512 times basically chokes the renderer.

I already have a fix for this issue, we just need to make sure it doesn't break any other games before we implement it.

[dukeeeey]

It's drawing like a textured ball. Only no textures have been uploaded yet so the the model comes out as black, ie invisible. Why it's drawing 500 times I've no idea, maybe this is some left over test code. I'm pretty sure the real hardware would be drawing this too. The difference is the real hardware has something called overload mode which means it'll just stop render after the frame time is up and present whatever it has drawn. This is something we can't emulate in opengl, or probably other 3d apis. Once a frame has started drawing there is no way to cancel it. So for us it has to take the full time.

There is one thing we can do to dramatically improve the situation without game specific apps and that is to only draw a frame when the host says to. This means that this expensive scene will only get drawn at most 2 or 3 times, instead of 20 to 30 times. Currently we draw every frame regardless as to what is being sent to the gpu, and for games like virtua fighter it'll start rendering random garbage in the loading screens. It's really one of the last big things that needs to be fixed in the emulator.

[WarpedPolygon]

Ahh I think I remember the red/orange ball, usually a sign of 'not gonna work' with older SVNr builds