Unfortunately that won't be easy, especially since ZDoom's getting onto the scripting branch into 2.9. All the tremendous development changes recently, IMO, mean network is punched out the window of a high rise for the time being while focusing on it just getting up and running without issues. It's been brought down to the level of assembly in preparation of doomscript.
So I say Zandronum aught to continue its goal of being the top of multiplayer zdoom handling in the mean time because it's just good at what it does in that regard. It really is.
Csonicgo wrote:I never noticed any "framerate dips" or loss of performance - I saw an increase in performance.
I love these linux users who are saying: "all works for me!!!" But I don't believe in magic like this. Plus, not all of PCs have 4 core 3.2ghz processors.
Okay, I can understand that "Works for me" isn't a satisfactory answer for you. But if you aren't going to help them help you, and instead whine and bitch about it, I'm coming close to wondering why I've continued to allow you to post here.
Major Cooke wrote:All the tremendous development changes recently, IMO, mean network is punched out the window of a high rise for the time being while focusing on it just getting up and running without issues. It's been brought down to the level of assembly in preparation of doomscript.
Fuck you too?
Geeze. I don't openly shit on all your nonsense feature submissions on public forums. You don't even seem to understand what you're complaining about which is the absurd part.
(I don't care if you feel you've been insulted, responding in kind is not the way to solve it. -ww)
Why people continue to post insultingly and non-constructively like they think it will solve their issues still boggles me. It doesn't accomplish anything - all it does is make you look like an ass.
No one is getting paid here, and no one has to take the childish posts that are being present here - they could just walk away, and then ZDoom would be stuck in its current state, forever.
The people who have invested so much of their time, and their lives, into this source port did you a pretty darned big favor.
No one is forcing you to use ZDoom. You can always go back to Doom v1.9 under DOSBox or something - if you're happier with that.
Major Cooke wrote:All the tremendous development changes recently, IMO, mean network is punched out the window of a high rise for the time being while focusing on it just getting up and running without issues. It's been brought down to the level of assembly in preparation of doomscript.
Fuck you too?
Geeze. I don't openly shit on all your nonsense feature submissions on public forums. You don't even seem to understand what you're complaining about which is the absurd part.
You completely misunderstood what I said. That wasn't an insult. What the hell! That wasn't even a complaint, it was me stating the fact that with the switch to the doomscript branch, the priorities for networking are on the back burner. Zdoom has a whole new system that's down at the assembly level, and thus there's a lot of broken features that need addressing first.
Last edited by Major Cooke on Tue Feb 09, 2016 2:37 pm, edited 1 time in total.
I entirely do understand the words "punched out the window of a high rise". Do you? Please direct me to the post where any of us has stated we dropped networking support? I've been checking it since day bloody one of the scripting merge, and lo-and-behold it still works. In no way has it been shoved into the backburner.
Major Cooke wrote:And when I say back burner I mean temporarily lowered.
In case anybody is reading this and is wondering about this, this hasn't happened. If anything it dropped in preparation of 2.8.0 in favour of dumpster diving through bug reports, however now that's over and we have the scripting branch merged things are back to normal. Well, normal-ish. As normal as you can get with a whole new VM to do determinism tests on.
It's kind of like waking up in the morning to find someone put a 10-speed bike in the living room.
Just popping in to say thanks to Randi and everyone else involved for all the updates to ZDoom. I'm especially grateful for the Linux updates and improvements, since this is my OS of choice these days. I just installed this last night and from what I can tell it does seem to perform a bit better on my Ubuntu machine than 2.7.1 was performing. Great work!
Monsterovich wrote:SDL_FULLSCREEN_DESKTOP is a crap that works 3x times slower than normal fullscreen. Feel the difference between zdoom 2.8 (SDL2.0) and zandronum 2.* (SDL.1.2) I have cl_capfps false and vsync is off.
I have a 100fps increase on doom2 map01 (250fps on SDL2) and a 20fps increase on Urban Brawl map01 (95fps on SDL2) using AMD Catalyst drivers compared to 2.7.1. Additionally I always used SDL1.2 with cl_capfps on since the frame stutter was absolutely terrible if the frame rate changed over 60fps. Outside of when another program is using hardware acceleration, SDL 2.0 is consistently as buttery smooth as Windows regardless of the frame rate, probably thanks to using OpenGL. If I use SDL_RENDER_DRIVER=software I get similar frame rates to 2.7.1, but even then it's still about 5-10fps higher.
And that doesn't even go into the fact that I couldn't use fullscreen at all before since it would utterly destroy the way I have KDE setup (triple head) and SDL 2.0 allows vsync to work at all (although I don't use it).
Your point about quad cores doesn't hold up since ZDoom doesn't utilize extra cores although I do indeed have a 2.8GHz Quad Core Nehalem.
Monsterovich wrote:I love these linux users who are saying: "all works for me!!!"
We should totally ignore the benefits everyone else is getting from SDL2 because ONE user has an issue.
I do suggest you try setting your SDL_RENDER_DRIVER environment variable to software and see if it makes a difference for you.
Spoiler: Edit: Random additional test just for fun
GZDoom 2.1 gets me 600fps and 172fps on the same scenes. Graphics card is R9 285/380 class.
It looks like the Ubuntu64 package is poorly formed. I get notices that the files in the package are not owned properly and that a script makes use of uninitialized variables.
Just a generic question, I don't know the internal workings so just answer as a simple yes or no.
Will the scripting technology eventually allow you to iterate through actors without using TIDs in ACS? One of the biggest problems with anything ACS-based for now is having to assign TIDs just to count through and iterate through a group of actors (completely undesirable if the monsters already have TIDs assigned as part of map design).
At this stage it's unrelated. No actual syntax exists for the VM yet other than the function blocks in decorate. It'll depend on if the eventual syntax is capable of handling it in a way that won't fall apart if the chain is changed mid function (for example an actor is removed or spawned mid iteration).
Google This Site]
