ZDoom

My HD 530 doesn't seem to have any problems keeping a consistent framerate. The only drops come from enabling postprocessing (SSAO gives the hardest hit).

If there are any specific maps I can test, I will happily do it.

MrDowntempo wrote:

Graf Zahl wrote:People may use the software renderer as a matter of preference.
But those using the software renderer because they cannot run OpenGL are hopeless cases to begin with, you'd need a computer from the beginning of the millennium, not to have GL 2.0. Anyone seriously trying to use ZDoom on such a system should stick with a version more concurrent with their hardware.

Well, there are more corner case situations. Chromebooks or small single board computers that only support GLES for instance. Also, I use qzdoom on a laptop that can run gzdoom, however the software renderer in qzdoom outperforms the hardware renderer (integrated intel graphics). I'm picking up an exta stick of ram for it though, so we'll see if that helps (sharing more ram with the igpu)

Is that a intel hd one? Last time I tested there were almost no difference between my intel hd 4000 and amd hd 8870m.
If the gopiu is the problem in your case so a dual channel system ram will help alot in games, but if I remember right it didn't help in gzdoom case...
Fun fact: With zandronum I have almost the same performance with a Celeron 430 and an amd hd 5450 vs my notebook i7 3635qm with an amd hd8870m.
But on the other case, the Celeron can't even run the rage menu with proper fps

Graf Zahl wrote:What I'd really like to see one of these days is some actual benchmarks with suitable maps from various Intel chipsets to decide if they are actually worth supporting or better left relegated to some legacy GZDoom version. I know that the Geforce 6800 in my old 2004 computer is way too slow to run anything exceeding vanilla complexity at decent frame rates.

I have an Intel HD 4600 which runs TGRDM3 decently well. I can't turn on the more advanced settings with that mapset like shadowmaps and SSAO, but without those it looks and plays very fluidly.

So throw your benchmarks at me.

It's no NVidia GTX 1080 but it gets the job done at least for what I use it for.

I have an Intel HD4000 myself. Performance is acceptable for lower detail levels, but try anything more demanding and it gets choppy.
What I'd like to see is performance in Intel GL 2 hardware.

If there's a 32bits xp build I could test it, with my intel gma950

The devbuilds are all 32-bit XP capable.

uh, it only support opengl up to 1.4

Well, if it's about GL2 hardware, only my laptop remains now. The one that only supports GL 1.6 on Windows but GL 2.1 on Linux.

If anyone is using my repository - this is a courtesy note that the master has been reset again. The reason for this change is moving forward with implementing C/S code, which puts the other projects that were in the master to the side for now. (They will be found here)

This means that you will have to execute the following commands: This will save all your code that you've been doing on the old master and pulls it to the renamed master-1.4pre branch, and does a new pull, and then also fetches the new master. Then it force-checkouts the new master on top of the old one. If you wish to continue working from the old one simply execute "git checkout master-1.4pre" - it may not be updated as frequently anymore while I work with this new project.

This is your project and your repository, so you are naturally free to use it any way you want, but by making your master branch this volatile it causes a lot of problems for anyone trying to use it as upstream.

Git allows you to name branches any way you like - by convention, master means the head development branch that other branches are merged into. By constantly redefining what the master branch is you break with this convention. The conventional way of doing these things is to have a netcode branch for long ongoing work, because a master branch should ideally always be usable as a branching point. Having to reset a master branch should really never ever happen, unless something drastic happened.

Eh, you're right. I merged everything back.

Mostly I was hoping the devbuilds would pick up the netcode, but obviously that should wait until the code has matured a bit, anyway.

Rachael wrote:If anyone is using my repository - this is a courtesy note that the master has been reset again. The reason for this change is moving forward with implementing C/S code, which puts the other projects that were in the master to the side for now. (They will be found here)

Waaa C/S? You mean Client Server? There's been so many new things going on. I'm really curious what the current ideas going forward are, because honestly it's all left me a little lost.

Like, am I correct in that it was stated a while ago that Zscript would eventually be getting map control like ACS, or am I mistaken?

Models haven't gotten normals yet, right? I recall that being one of the reasons SSAO was removed from them. And after Graf mentioned in passing a desire to eventually get them shaded, I wonder if it might fall into place sometime around then. And that probably won't be touched until Zscript has been dealt with.

I understand there's been some work put into OpenGL ES? That means mobile support, right?

Then there's the splitscreen experiments. Recall something being said that doing it right would require some serious retooling.

"Waaa C/S? You mean Client Server? There's been so many new things going on. I'm really curious what the current ideas going forward are, because honestly it's all left me a little lost."
- Yes, Client/Server.

"Like, am I correct in that it was stated a while ago that Zscript would eventually be getting map control like ACS, or am I mistaken?"
- Graf would have to speak for this. I believe that was one of the plans, if it's not in effect already.

"Models haven't gotten normals yet, right? I recall that being one of the reasons SSAO was removed from them. And after Graf mentioned in passing a desire to eventually get them shaded, I wonder if it might fall into place sometime around then. And that probably won't be touched until Zscript has been dealt with."
- Models are unchanged so far.

"I understand there's been some work put into OpenGL ES? That means mobile support, right?"
- No. You are right there has been a little work put into OpenGL ES but so far the only version supported is 3. The original developer for D-Touch is still active and doing that on the Doomworld forums.

"Then there's the splitscreen experiments. Recall something being said that doing it right would require some serious retooling."
- For now I've lost interest in the splitscreen stuff, and I don't know how far along the screen and status bar refactoring have come, but they would need to be finished for anything like this to happen. Again, Graf would have to speak to this.

Jaxxoon R wrote:Models haven't gotten normals yet, right? I recall that being one of the reasons SSAO was removed from them. And after Graf mentioned in passing a desire to eventually get them shaded, I wonder if it might fall into place sometime around then. And that probably won't be touched until Zscript has been dealt with.

For me, the lighting of models is one of GZDoom's biggest visual limitations ATM. Assuming the rock in this screenshot from Tormentor is a model, it really illustrates the issue, as does the leafless tree in the background to a lesser extent:

Spoiler:

---

Here's hoping that it will be addressed at some point. There's so much going on with *ZDoom at the moment. It's pretty exciting stuff.

Linear filtering broken =(