TIHan

Does anyone have any suggestions that can make Zandronum's coop experience better? I've been working on a few branches that will address bandwidth and lag compensation. We are also working on a few sync issues. Is there anything gameplay related that could be improved?

The main topic is still trying to be derailed.

The tool should probably be re-written in WPF.

Ah very nice! I like the implementation of interpolation/extrapolation. Very cool.

You know what. You are right. Obviously mis-used the term "derogatory". It looks like as far as optimizations go, according to Graf - you really can't do anything to the render to make it faster. Hmm, I was hopeful for the potential performance in the render; it is too bad.

Then we have two types of people: people who think software is trash and should be rid of it; and people who love software and think it should be more focused in development compared to a hardware render. Heh, I might be in the minority with the "software is trash" bit; maybe I should put it in a way that means "Hey, we should keep software; but, let's focus more development on OpenGL since it has more performance potential than the software render does."

Looks like more offensive language against me, again. And I shouldn't say anything about rendering because I don't know how to program in it? Please. While I can agree with you it is somewhat fun to play DOOM in software at 320x200; but, for more people outside this community to even use these ports, I bet you that would want OpenGL at high resolutions vs. your software. :)

Hahaha. What are you talking about? Also, mind your offensive language please.

Software rendering is old? Developers over the past decade use hardware rendering because it's faster and more maintainable? Hello? I will end this conversation from my end. :) No sense in trying to argue with you; as you will just keep just posting derogatory remarks against me. Cool! :D

esselfortium, perhaps I might be assuming, but why not assume? It's 2012; not 1995. If you want more support in software rendering, then I can't stop anyone from doing it or users here wanting to use it. All I'm trying to do here is make a point that with more time and effort, a lot of those issues that we experience in OpenGL can be solved; therefore, truly surpassing that of software. Which even now, in most cases OpenGL does when compared to software. I may not know anything about rendering; but I'm damn well sure OpenGL can pull more horsepower than software. Perhaps some form of dynamic occlusion culling could solve a few issues.

I did some testing in PrBoom for sunder, the software render seemed to handle map10 much better at lower resolutions, compared to GL with lower res. As far as SpaceDM, I roughly got the same framerate between renders using (G)ZDoom. I still say get rid of software; and pour more effort in optimizing the hardware render.

In that case, the Doom engine is just a bad match for development. I would like to see a good example where the software render excels over the hardware render in performance on particular maps. Should be interesting. While, not a great example as its not vanilla, but does have complex architecture. Sunder Map10 OpenGL Software Edit: I saw your point in the thread. But, it's simply put that if you don't have, I mean nowadays an in-expensive video card; then your CPU will be best at rendering something like Doom compared to a hardware render. Now, I would say there is always room for optimization, and I would be more optimistic towards OpenGL than software. I could see if a lot of devs could came together to find a way to optimize the hardware render rather than work on the software render, we might actually have something.

So I guess we need a new term for OpenGL "pixelated". Perhaps just "pixelated OpenGL" would do fine. Yes we can see these differences between the two, which Maes noted, "'glass brick' pillars appear slanted in the 1st screenshot; lack of distance-lighting discoloration on the pinkies; major differences in the way distance/sector lighting works". All of which, OpenGL is seriously superior too in every way. Actually I take that back, there was a engine modification a bit back where someone made the software render true color - pretty cool and a great exercise. But the main point of the beginning of this thread, is optimization of the software render, which was pointed out it wouldn't make much difference across multiple CPUs. OpenGL, according to these screenshots almost gives you a 250-300% performance boost, comparing to a potential max of 20% for a multicore software render; oh, and OpenGL looks great with (potentially) a more maintainable code base render. Now, while this performance boost percentage will fluctuate in a lot of maps; but even with these screenshots gives us a good indication that OpenGL is far more optimized than any software render could be. :) Actually, some good multicore optimization should in the AI.

Then ignorance will forever be you. :)

OpenGL Software

Another question, why would you want Doom to even have that "pure" software look? Nostalgia? It looks like garbage.

If you want optimization, you should consider just rendering OpenGL or DirectX. The software render is worthless and really should not even be worked on.

I assume the problem with it not requiring source distribution is due to someone taking the source, calling it his own port, and being able to close the source on it correct? I agree, there is already enough trouble with its licensing anyway. However, if an additional license can solve the source distribution problem and not be a hassle in applying it; then go for it. But, it may be more complicated than we think. In that case, just release it as BSD.

The only reason to use some type of DBMS is for the scalability. JSON would totally work fine, if we do not want an actual database and it is stored locally. The only question would be performance later on, but I don't know what the performance difference would like against say 10,000 objects in JSON compared to a NoSQL 10,000 objects. Btw, NoSQL is meant to be simpler than SQL. And in case you are wondering, http://www.mongodb.org/ . But anywho, good luck with the task though! :)

This seems like way too much work for something quite simple.

CSV is a format you definitely do not want to have data be stored and accessed for the purposes of what is trying to be done here. CSV as far as I know is commonly used to hold queried data and be opened in Excel. While keeping separate files may speed up things up, it will not be manageable. If you have 100 WADs, then that means you need 100 of these files. A SQL database could handle what we are doing, but IMO a NoSQL DB could be a better solution. http://ravendb.net/ RavenDB - "Raven stores schema-less JSON documents, allow you to define indexes using Linq queries and focus on low latency and high performance." Again, I haven't used a NoSQL DB, but I know what they are used for, and I do think it would work great in this situation. This doesn't mean SQL would be bad. Well, it doesn't stop the player from using cheats or changing the settings on the fly. Unless it's online, then we have a problem. I don't know if we are worried about sourceports using this at the moment; this could be implemented in a launcher instead. Also, having a database online isn't a bad idea. However, my only argument not to use an actual online database is what if a user wants to add his own WAD settings? Well, he isn't the DBA so he can't really do anything about it can he?

facepalm Well, I guess I should have heard about then. But I didn't until now. =/

I haven't used a NoSQL database before. At work I don't even think we have used it, but it does come up every now and then. There is some real use in NoSQL, and that it is non-relational. If you have data that isn't related, then it works extremely well. If you do have relational data, yea SQL all the way. :D I haven't heard of Firebird, I'll have to check it out.

^ If you want to use a database that is hosted on a server, I would really look into NoSQL for this sort of thing. A SQL database is way too much overhead for something as simple as this. Now, I'm trying to figure out if you should have settings for each map concerned with the WAD. Though this would allow functionality for each map, but it would also give us inconsistencies. A quick and bad example would be CChest.wad, map29 requires that wall running is enabled in order to complete the map. Well, if that flag is only enabled for that map, you can say there is inconsistency in movement between all the maps and map29, so enable the flag across the entire WAD. I'm not saying this is the way to go, but it is something to think about. Personally, I would rather have a per map setting.

Thinking about it, a NoSQL solution could work with this as there isn't any relationships involved. I haven't touched on NoSQL before, but I'm aware of their existence. Here are a few that are pretty popular in the NoSQL scene. http://ravendb.net/ http://couchdb.apache.org/ http://www.mongodb.org/