bayaraa / d2gl

Diablo 2 LoD Glide/DDraw to OpenGL Wrapper
GNU General Public License v3.0
187 stars 30 forks source link

Limitations and crashes #144

Closed DoctorGoat closed 8 months ago

DoctorGoat commented 9 months ago

So I'm playing a fork of Eastern Sun that can get... hectic.

With thaison's work, we have the COF/sprite cache/celdata buffers expanded. However, if I am a complete idiot about what I have equipped with runewords/unique charms, I can still cause crashes. I've got parts of D2Client I need to look into for the actual crashes now.

Bumping the texdata array and command buffer last night in command_buffer.h (after a crash specifically pointed to them) helped. I was pretty tired and didn't have the energy to test each separately, but I figured I'd ask for more help from someone who knew vastly more of the rendering system.

Here's one of the three current problems. The framerate absolutely nosedives when there's a big crowd being hit with too much, and then goes into hyper-fast motion when the FPS issue resolves itself.

https://cdn.discordapp.com/attachments/1192337912591831070/1211131678886469692/D2Loader_v1.10b14_Build_On_Oct_29_2003_2024-02-24_21-01-47.mp4?ex=65ed1545&is=65daa045&hm=65a0185c74806855513ce28a88fd924246adb360edd939140dcf95536ab0c61f&

bayaraa commented 9 months ago

Probably too much texture update or vertex data. Or maybe game itself bottleneck. If there is too much command for gpu, you should try ddraw mode. It runs everything on cpu and only final upscaled image drawn to screen by gpu. Also you should try with new motion prediction mod (d2fps).

DoctorGoat commented 8 months ago

I'm pretty sure it's due to the game handling memory in a very stiff way over in D2Client. By increasing the number of buffers the game can theoretically handle and increasing the command buffer of the d2gl source, they draw and don't crash for that reason.