Hard Coded limits in Doom that should be removed in jDoom

[DaniJ]

Hard Coded limits in Doom that should be removed in jDoom:

Give me a list of the hardcoded Doom limits that still exist in jDoom (that have been removed in other "limitless ports") and I will look into removing them for jDoom/jHeretic/jHexen.

EDIT: So far I''ve removed the limits on:

• activeplats (MAXPLATS)
• activeceilings (MAXCEILINGS)
• number of switches (MAXSWITCHES)

I know about the limits on the level structures, I'm looking in to fixing them atm.

What about MAXBUTTONS, MAXLINEANIMS etc etc?

[Wicked Anime Kid]

Is it possible to change the 64 grid barrier? It would greatly save some time with mapping and applying large surfaces 'n stuff

[Tolwyn]

Most definately the 64 Grid barrier.

[DaniJ]

By the 64 grid barrier I take you mean being able to align the flat used on floor ceiling as you can wall textures?

There is a greater issue with that as how would be the best way to do it? For example Zdoom does this in a very cack-handed way by using ACS. There are many things that I would like to see that are related to this (rotated/scaled textures amongst others) but it requires a lot more thought.

A new lump could specify these values or extended versions of the existed lumps that include the new data. I would like to see a standard here among the various ports.

Technically that would be a new feature not removing a hard coded limit.

[Graf_Zahl]

MAXBUTTONS and MAXLINEANIMS are in desperate need of being removed. Even back in 1995 I managed to make one level with a lot of shoot switches crash due to this limit.

I don't think that this one is that urgent but you should replace most of the P_Find* functions in p_spec with the versions from Boom. Some still contain unnecessary limitations, for example P_FindHighestFloorSurrounding can't find anything below -500 and P_FindNextHighestFloor uses a very inefficient algorithm with a table although it can be easily done without.

[Graf_Zahl]

Originally Posted by Dani J666

A new lump could specify these values or extended versions of the existed lumps that include the new data. I would like to see a standard here among the various ports.

If you are interested you may join this discussion.

http://forum.zdoom.org/viewtopic.php?t=5929

This is something that definitely has to be dealt with. Not only for better positioning of flats but also to make future improvements easier instead of having to resort to inconvenient hacks like (not only) ZDoom is forced to do far too often.

[Xerxes]

There is a limit with the bullets of rifle of the weapons of the HUD
If the distance is too big, the bullet doesn't appear and therefore nothing happens
This limit was correct in ZDoom but it would be terrific of more to have it also in jDoom (it is notably convenient for my sniper )

[DaniJ]

Originally Posted by Graf_Zahl

MAXBUTTONS and MAXLINEANIMS are in desperate need of being removed. Even back in 1995 I managed to make one level with a lot of shoot switches crash due to this limit.

Ok, I'll see about removing the limits on them, shouldn't be that difficult.

I don't think that this one is that urgent but you should replace most of the P_Find* functions in p_spec with the versions from Boom. Some still contain unnecessary limitations, for example P_FindHighestFloorSurrounding can't find anything below -500 and P_FindNextHighestFloor uses a very inefficient algorithm with a table although it can be easily done without.

I'd noticed those myself but didn't realise P_FindHighestFloorSurrounding had that restriction... I look in to converting the versions used in PrBoom.

This is something that definitely has to be dealt with. Not only for better positioning of flats but also to make future improvements easier instead of having to resort to inconvenient hacks like (not only) ZDoom is forced to do far too often.

Indeed. I'll definetly give my input.

There is a limit with the bullets of rifle of the weapons of the HUD
If the distance is too big, the bullet doesn't appear and therefore nothing happens
This limit was correct in ZDoom but it would be terrific of more to have it also in jDoom (it is notably convenient for my sniper )

I'm not sure what your getting at. Do you mean max movement speed of a THING? That when moving "too fast" the bullet (I take it you mean missile rather than a hitscan weapon?) is passing through it's target?

[Graf_Zahl]

Originally Posted by Dani J666

I'm not sure what your getting at. Do you mean max movement speed of a THING? That when moving "too fast" the bullet (I take it you mean missile rather than a hitscan weapon?) is passing through it's target?

I think he means that hitscan attacks have a limited range of 2048 map units. It can be increased but the math tends to become erratic when this is done. I have seen the weirdest effects after increasing the range.

[DaniJ]

Just finished removing the MAXSWITCHES limt, now for MAXLINEANIMS...

I noticed that even PrBoom hasn't 'bothered' to fix the MAXBUTTON limit. Is it really an issue?

I think he means that hitscan attacks have a limited range of 2048 map units. It can be increased but the math tends to become erratic when this is done. I have seen the weirdest effects after increasing the range.

Ah I see.

What kind of weird effects are we talking here?

[mrinsane]

belive me dani j the max switches is bad

[DaniJ]

Like I said, I fixed it.

After a bit of thought on the subject MAXLINEANIMS will be fixed as part of the process of adding BOOM support so I'll leave that for now.

[Graf_Zahl]

Originally Posted by Dani J666

adding BOOM support

Sounds good!

If you go for full Boom support you should consider using MBF's friction code instead of Boom's original. It is much closer to what Hexen and Heretic are doing with their low friction sectors and it is more intuitive. And with the exception of Legacy it's the code used by all other Boom compatible ports.

[DaniJ]

Well I'm not actually just gonna copy the code from Boom/MBF or anywhere else. I'll use it for reference certainly but I plan to completely intergrate it with XG so most of that code will be of little use. The existing friction code used in XG sectors is VERY similar so I'll probably stick with that.

I can't say it'll be full support though. Just the often used features (at least initialy anyway).

[mrinsane]

just a guess by is skyjake using his time on hawthorn and letting you do some doomsday codeing

[Graf_Zahl]

Originally Posted by Dani J666

Just finished removing the MAXSWITCHES limt, now for MAXLINEANIMS...

I noticed that even PrBoom hasn't 'bothered' to fix the MAXBUTTON limit. Is it really an
issue?

It heavily depends on the map. I once saw a map I was able to crash because there were more than 16 shootable switches close together. But these are truly rare. I think increasing it to 32 or 64 should be sufficient in 99.9% of all cases. Of course you could do it like ZDoom which spawns a thinker each time a switch is activated. Then you'd always be on the safe side.

Ah I see.

What kind of weird effects are we talking here?

With high hitscan ranges the risk of fixed point overflows increases. In large maps that can lead to hitscans 'hitting' something in mid-air or traces vanishing completely.

[DaniJ]

With high hitscan ranges the risk of fixed point overflows increases. In large maps that can lead to hitscans 'hitting' something in mid-air or traces vanishing completely.

Can you not simply exit the check at the _max_distance_ and then do another hitscan continuing from where you left off? Put that inside a loop and continue till something is hit every time.

just a guess by is skyjake using his time on hawthorn and letting you do some doomsday codeing

We've kinda agreed that I will focus on game related issues while Skyjake deals with the bigger picture of the Engine as a whole. He's extremely busy atm with work and his Masters but he is putting a fair amount of work in to 1.8.7. I would imagine because he knows he will be very busy for the rest of the year he is addressing the long running issues and main problems now so that he can concentrate on Real Life and so that he can dedicate what spare time he has to Hawthorn development.

[Graf_Zahl]

Originally Posted by Dani J666

Can you not simply exit the check at the _max_distance_ and then do another hitscan continuing from where you left off? Put that inside a loop and continue till something is hit every time.

As long as the calculations being done before starting the trace are ok, probably yes. But if you get incorrect data due to overflow in the aiming code you have no chance to get it right again. I haven't thought much about it though so I can easily be off with these assumptions.

[DistantJ]

Some of the sound lumps are special ones which will actually play a random sound out of two or three under the same name just with a number on the end. For example the wakeup/death sounds of all three zombie types, and imps.

Vermil has mentioned to me that these are currently hardcoded. So perhaps that's something which could be removed, and controlled externally via a DED file instead? It'd be nice for my soundpack(and whatshisname's ambience pack) if we could define a number of sound lumps that will play a random sound out of two, three or maybe more via a DED file. Just imagine how cool it'd be if not only did the monsters each have their own individual 'nearby' sounds like they do in my current soundpack, but actually played a few different sounds at random!

[xZAOx]

I know one limit. No sector-over-sector!

;-)

/flee

-Rob