Inside3D!
     

Engine standards for mod compatibility
Goto page Previous  1, 2, 3 ... , 14, 15, 16  Next
 
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion
View previous topic :: View next topic  
Author Message
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Sun Feb 07, 2010 10:31 pm    Post subject: Reply with quote

Changed MAX_DATAGRAM to 1400, considering it a hard limit.

What about MAX_DLIGHTS for example, should that be left alone?

MAXALIASVERTS and MAXALIASTRIS, are those hard to change?

MAX_LMB_HEIGHT, how is this best handled, considering the 3dfx downsampling and whatnot?

I'm considering adding flushing unused textures to misc. features, is this a hard feature to do?

Speaking of recursive calling, I do this sometimes, it's very useful!
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Sun Feb 07, 2010 10:51 pm    Post subject: Reply with quote

32 dlights should be enough. It's not too hard to go higher, but all the same I would stick with 32 for the standard.

MAX_LBM_HEIGHT I believe comes more from modelgen than from the engine itself, although it's also used by software Quake for a skin lookup table. Either way it should be easy enough to increase, and I don't think we need be worrying about 3dfx these days. Very Happy

Max alias verts and tris are also easy enough to change, but there are implications for memory usage (also with lightmaps - bumping to 256 needs about 16 MB) which might make the standard inaccessible to lower specced machines (I'm thinking PSP rather than older PCs here). Any worthwhile increase should probably switch to dynamic allocation, meaning something of a rewrite of the loader. This is where gl_mesh.c is really evil and ugly as it just uses a whole batch of big static buffers.

More as I think of it.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Sun Feb 07, 2010 11:11 pm    Post subject: Reply with quote

I'd love for all of the memory management to be dynamic, but I have no idea how hard that might be to code, I'm guessing very hard. This is why it makes more sense to me to only increase the limits which are the most relevant and easy, which don't make a massive impact on memory usage, I really want for PSP and other handhelds and consoles to be part of this.

Could some memory management be made dynamic, while other parts left static? Are certain parts easier? Are certain parts more relevant than others to make dynamic?
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Sun Feb 07, 2010 11:39 pm    Post subject: Reply with quote

Hmmm - lightmaps can be made mostly dynamic easy enough and without upsetting the existing code too much, although putting them on the hunk would require an increase in MINIMUM_WIN_MEMORY. I've already posted code in the tutorials section for just about everything relating to alias models, but I don't know if there's going to be much in the way of uptake on it.

Generally the problem is that everything needs it's own special handling, and sometimes there are knock-on effects in unexpected places. Quake's memory management system isn't too friendly for it either. Finally it can be difficult to retro-fit into an engine that has already had significant work done on it.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Mon Feb 08, 2010 1:40 am    Post subject: Reply with quote

Team Xlink wrote:
frag.machine wrote:
This discussion about the proposed new limits brings another problem to light: the current artwork (maps, textures, alias models, etc) file formats and how they are quickly becoming the bottleneck for the natural evolution of the engines. I believe that in the event of a QSB 2.0 standard we should consider the option of new, more flexible file formats and then maybe a set of migration tools. For now I think is best to just stick to the current ones for simplicity sake.


If the QSB 2.0 standard did have new file formats would it still be compatible with the original ones? If not would all of the original Quake artwork have to be converted or would it be redone?


Ok guys, let's keep in mind all the time that QSB 1/2/n will be ALWAYS retro-compatible, and only should fallback to legacy stuff if a newer format wasn't found or is not applicable. So, let's take this hypothetical example:

QSB 1.0 = supports Quake network protocol 15 + QSB protocol 997, protocol 999 is active by default, you have to manually selected protocol 15 if want to run a vanilla server;
QSB 1.1 = supports Quake network protocol 15 + QSB protocol 999 + QSB protocol 1000, 1000 is active by default, you have to manually select any other protocol if want to run a legacy-compatible server.
(...)
QSB 10.0 = supports all previous protocols + QSB protocol 6666, blah blah blah blah...

The same rules applied to alias models file formats (WARNING - this is a fictional scenario):

QSB 1.0 = supports .mdl/.md2, always tries to load md2 first, then mdl;
QSB 1.1 = supports .mdl/.md2/.md3, loading sequence is always md3/md2/mdl
(...)
QSB 10.0 = supports .mdl/.md2/.md3/(insert a long list of obscure file formats), loading sequence is from the newest to the oldest format.

So I hope now it's clear to everyone that QSB is not about breaking what exists, but evolve the Quake engine technology so the platform can survive longer.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Urre



Joined: 05 Nov 2004
Posts: 1073
Location: Sweden

PostPosted: Mon Feb 08, 2010 8:41 am    Post subject: Reply with quote

frag.machine made it very clear, there.

I'm wondering if the increased limits should be listed in some different manner by the standard, rather than all these constants, as it might not make a lot of sense if engine devs want to do it in some other way. Instead of telling them how to do it, it should say what's expected as an end result, I think...

One idea which comes to mind is listing what maps it should be able to run. If the map passes, the engine is QSB compatible. I've already planned to make a QSB test-mod for this purpose, and simply listing limit-breaking maps can be an easy shortcut for some of the tests.

Then again, it might get a bit too abstract? What if there are no maps which break all the limits we want to raise?
_________________
Look out for Twigboy
Back to top
View user's profile Send private message Visit poster's website
Teiman



Joined: 03 Jun 2007
Posts: 309

PostPosted: Mon Feb 08, 2010 2:43 pm    Post subject: Reply with quote

Urre wrote:
I've already planned to make a QSB test-mod for this purpose, and simply listing limit-breaking maps can be an easy shortcut for some of the tests


This is a awesome idea.
Back to top
View user's profile Send private message
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Mon Feb 08, 2010 3:02 pm    Post subject: Reply with quote

Urre wrote:

I'm wondering if the increased limits should be listed in some different manner by the standard, rather than all these constants, as it might not make a lot of sense if engine devs want to do it in some other way. Instead of telling them how to do it, it should say what's expected as an end result, I think...



The list can be enhanced with a more didactic explanation for non-coders, but all constants are part of the original Quake source code, and engine devs are normally well acquainted of them. Anyway, if you have an idea for a more adequate format, let's see it.


Urre wrote:
One idea which comes to mind is listing what maps it should be able to run. If the map passes, the engine is QSB compatible. I've already planned to make a QSB test-mod for this purpose, and simply listing limit-breaking maps can be an easy shortcut for some of the tests.



Not only listing, but I think we should prepare a package containing:
a) maps specifically built to force engines to the new limits;

b) a simple test mod for QSB-specific features;

c) recorded demos that stress the network limits and any new protocol features;

d) screenshots with the expected results for things like alpha/scale/fog support (but not limited to this).

Urre wrote:
Then again, it might get a bit too abstract? What if there are no maps which break all the limits we want to raise?


Then somebody need to build them Smile
I think that's something where the map community can contribute actively: once we define the new limits, the mappers could built simple "testboxes" for the new features. One map can test more than one aspect, but I expect we'll need a bunch of them to test everything. This way we ensure all the community is committed with QSB and thus the standard becomes stronger.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Spirit



Joined: 20 Nov 2004
Posts: 476

PostPosted: Mon Feb 08, 2010 3:17 pm    Post subject: Reply with quote

I have a small testmap for fog, overbrights, fullbrights, texture support (only marginally) and func_ brush transparency. Feel free to use any of it as you like.
http://www.quaddicted.com/quake_engines/enginetest-spirit.zip

arguirRe's engine has nice limits output in developer mode. Very useful to create limit-breaking maps.
_________________
Quake Maps
Back to top
View user's profile Send private message Visit poster's website
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Mon Feb 08, 2010 5:52 pm    Post subject: Reply with quote

Spirit: yeah, I know your map, that's exactly what I am talking about, only with a more extensive coverage (for example, regarding texture loading: IMO QSB should define not only what minimal file formats should be supported - pcx, tga, bmp, etc - but also the loading sequence; then a test map should simulate the situation of having two or more textures with same name but different formats so we could check if the engine loads them in the expected order).
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
mh



Joined: 12 Jan 2008
Posts: 909

PostPosted: Mon Feb 08, 2010 6:46 pm    Post subject: Reply with quote

frag.machine wrote:
Spirit: yeah, I know your map, that's exactly what I am talking about, only with a more extensive coverage (for example, regarding texture loading: IMO QSB should define not only what minimal file formats should be supported - pcx, tga, bmp, etc - but also the loading sequence; then a test map should simulate the situation of having two or more textures with same name but different formats so we could check if the engine loads them in the expected order).

So really what we're talking about is a kind of conformance test? Sounds like a good idea to me.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines
Back to top
View user's profile Send private message Visit poster's website
frag.machine



Joined: 25 Nov 2006
Posts: 728

PostPosted: Mon Feb 08, 2010 8:48 pm    Post subject: Reply with quote

mh wrote:
frag.machine wrote:
Spirit: yeah, I know your map, that's exactly what I am talking about, only with a more extensive coverage (for example, regarding texture loading: IMO QSB should define not only what minimal file formats should be supported - pcx, tga, bmp, etc - but also the loading sequence; then a test map should simulate the situation of having two or more textures with same name but different formats so we could check if the engine loads them in the expected order).

So really what we're talking about is a kind of conformance test? Sounds like a good idea to me.


Test-driven development is always a good idea, specially in the case of many independent coders.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/
Back to top
View user's profile Send private message Visit poster's website
Spike



Joined: 05 Nov 2004
Posts: 944
Location: UK

PostPosted: Mon Feb 08, 2010 8:54 pm    Post subject: Reply with quote

test driven gives reason.
_________________
What's a signature?
Back to top
View user's profile Send private message Visit poster's website
gnounc



Joined: 06 Apr 2009
Posts: 120

PostPosted: Mon Mar 15, 2010 9:31 am    Post subject: Reply with quote

Like the acid tests for web browsers.
I love reading those, cant wait for the acid4 test.
http://en.wikipedia.org/wiki/Acid1
Back to top
View user's profile Send private message
LordHavoc



Joined: 05 Nov 2004
Posts: 243
Location: western Oregon, USA

PostPosted: Wed Mar 17, 2010 4:52 am    Post subject: Reply with quote

I made an acid test of sorts for quake map compatibility once...

http://icculus.org/twilight/darkplaces/files/entitytest.zip

Yes, it has a moving sky brush.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Inside3d Forums Forum Index -> General Discussion All times are GMT
Goto page Previous  1, 2, 3 ... , 14, 15, 16  Next
Page 15 of 16

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2004 phpBB Group