[Zaxtor]

In the old days sector limit was 1024, lines about 8192, 4096 for sprites
If I am correct.

Now the limit is 4096 sectors, 16384 lines, 16384 sprites.

But question is how about we increase it?

Maybe double or triple limit.

TROR limit maybe making it 512 or lil more.

If is not too complicated.

Just a suggestion

[OpenMaw]

To my understanding it really isn't that simple. If it were, why not just make it infinite. No limits, don't worry about it?



I think it messes things up when you do that without making major changes elsewhere.

[Forge]

i can hear the teeth grinding now

tell zax when he does this (another thing that's been requested dozens of time):

semiroundboss, on 06 May 2012 - 06:42 PM, said:

Hi. Can someone or a group of people can port DN3D for Genesis like how the n64 one is going? My other requests are for someone (Or Someones) to port maps from the Saturn version of DN3D's UREA 51 and the Plug N Pray episode from Total Meltdown? User maps that are based off of Duke Nukem Zero Hour and Land Of The Babes would not be bad either.

then you'll consider thinking about possibly contemplating what he wants

[Hendricks266]

https://webcache.goo...refox-a#msg2255

JonoF said:

I believe Ken or possibly myself has explained somewhere in a public forum why the absolute limits to Build's sectors/walls/sprites values are 16384, but anyway... Build is limited to using a 14-bit number for the maximum number of sprites, walls, and sectors. This stems from past decisions that involve using a 'short' data type for this type of information, and having the top two bits of that 16-bit variable reserved. Fourteen bits give a maximum range of 0-16383, which is the number of sprites and walls now available in JFBuild under the V8 map format. To promote all the 16-bit values to 32-bit would obviously give near-limitless capability but it will mean the most radical and extensive modification of both engine and game that has been done to date. I can tell you right now it won't be me doing it all.

[Zaxtor]

Commando Nukem, on 25 January 2013 - 02:22 AM, said:

To my understanding it really isn't that simple. If it were, why not just make it infinite. No limits, don't worry about it?



I think it messes things up when you do that without making major changes elsewhere.

No limit can be a good idea cus.
Faster ur PC is, more it can handle to stress of massively huge, complex level and or detailed levels.


I remember my very old PC couldn't handle levels with around 800 sectors.
PC was a 4/86 or something

-------------------------


" 16-bit variable reserved. Fourteen bits give a maximum range of 0-16383"


I am not sure if I am right on this.
But what if windows has 32-64 bits?
Mine can hold 64 max I think..

0-32767 - 28bit
0-65535 - 56bit
?
I am not sure if I am right with this.
Unless u mean a diff type of bit

[Forge]

you seem to want to ignore the most important part of what's being said to you:

JonoF said:
... but it will mean the most radical and extensive modification of both engine and game that has been done to date. I can tell you right now it won't be me doing it all.

why do you think i posted what i did? you're asking for him to spend ridiculous amounts of time modifying everything - so i threw it back at you. Tx has been hounded about this shit on a constant basis, but nobody who takes the time to harass him takes the time to think about what it would take to pull it off. Somehow they're under the impression that a couple lines of code and viola! magically everything is instantly done.

[Inspector Lagomorf]

Given the utter complexity of his mapping skills, someone should just give the source code to Zax and see what he does to it.

[Zaxtor]

The thread is almost 8 years old.
Technology evolve fast.
So maybe at the time was impossible and today is lil easier to make but still very hard.

I know is radical.
Stuff like that is considered radical.



You can easily set the grid size by modifying the cfg or w/e.
But I am just wondering if we can implement to set sector volume by cfg.
I am sure it will involve radical coding in the game's engine and radical move.

I was sure adding TROR was radically hard.


I respect TerminX choice. I know is radical and complex.

[Fox]

Zaxtor sounds like Borat. Kazakhstan greatest country in the world.

[TerminX]

Regardless of the fact that such a change would require massive alterations to significant portions of the game, engine, and editor, it would also break all mods that use any of the advanced CON functions like hitscan and movesprite that return either a wall, sprite, or sector encoded in the same variable. There is also the issue that the more walls, sprites, and sectors that exist in a single map, the longer the many, many loops in the code take to complete, meaning lower performance.

Realistically, this isn't ever happening.

[Fox]

TerminX, on 25 January 2013 - 01:18 PM, said:

it would also break all mods that use any of the advanced CON functions like hitscan and movesprite that return either a wall, sprite, or sector encoded in the same variable.

Somehow I feel Eduke32 should never have used 16384 as a constant, but rather as a pre-defined gamevar.

[Radar]

I remember a map called Ritt_Balloon that was released on the 3D Realms forums way back.

http://forums.3dreal...level+train+map

Does anyone else remember this map? Does anyone by any chance still have it? All the links are dead. I mention this map because I remember having problems with launching it as EDuke32 development advanced. I was told that it was because the map actually surpassed even the extended sector/sprite/wall limits and it was a miracle it ever actually ran with EDuke32. Is this legit or is my memory just hazy?

[Inspector Lagomorf]

Fox, on 25 January 2013 - 01:29 PM, said:

Somehow I feel Eduke32 should never have used 16384 as a constant, but rather as a pre-defined gamevar.

Nobody could have foreseen that we would ever have needed more than 14 bits.

[Fox]

And we don't. But it simply doesn't sound right to have a static value.

[Zaxtor]

If it would collapse or break other mod then we should keep duke as it is.
I'd rather not have more sectors than sacrificing tons of good mods out there.

Is like choosing crushing a 20,000 karat diamond for having 20 free computers.

[Fox]

Zaxtor, on 25 January 2013 - 01:55 PM, said:

Is like choosing crushing a 20,000 karat diamond for having 20 free computers.

Seriously, that sounds exactly what Borat would have said.

[Zaxtor]

maybe.

AVGN says that.

Quote

I'd rather have a fucking buffalo take a diarrhea dump in my ear than subject them to this horrendous garbage.

[Micky C]

I think Helix said it's not too bad to change the TROR limit if anyone needs it, but as for the wall count, if anyone really needs to make a bigger map, they can always fall back on map caching although that would require a bit of extra code. However hopefully the system gets cleaned up and little bits of custom code can be made compatible with mods like dukeplus, I know Hendricks is always talking about mutators.

Also

Forge, on 25 January 2013 - 12:01 PM, said:

a couple lines of code and viola!

[Hendricks266]

Zaxtor, on 25 January 2013 - 12:31 PM, said:

The thread is almost 8 years old.
Technology evolve fast.
So maybe at the time was impossible and today is lil easier to make but still very hard.

It's not impossible, and it's not an issue of tech being prohibitive. The design is the obstacle. You could find and replace "int16_t" with "int32_t" and be some of the way there, but you then have to deal with severe performance and compatibility issues. All the current infrastructure is set up to use the 16-bit values, and there is no reasonable way to change public APIs like CON with something so radical. I suppose even that could be dealt with but it wouldn't be pretty.

Radar, on 25 January 2013 - 01:33 PM, said:

Does anyone else remember this map? Does anyone by any chance still have it? All the links are dead. I mention this map because I remember having problems with launching it as EDuke32 development advanced. I was told that it was because the map actually surpassed even the extended sector/sprite/wall limits and it was a miracle it ever actually ran with EDuke32. Is this legit or is my memory just hazy?

What software would even allow construction of maps beyond the engine limits?

[Hank]

It's prolly been asked before, but could the maps be linked like in Quake II?

[LeoD]

Radar, on 25 January 2013 - 01:33 PM, said:

I remember a map called Ritt_Balloon that was released on the 3D Realms forums way back.
Does anyone by any chance still have it?

Haven't tried it for a while, but I remember a "too many sprites spawned" issue. IIRC it isn't such a great map anyway.

Attached File(s)

•  Rittballoon.zip (256.36K)
  Number of downloads: 293

[Micky C]

Hank, on 25 January 2013 - 05:01 PM, said:

It's prolly been asked before, but could the maps be linked like in Quake II?

Yeeaahhh... you're talking about map caching right? How you can move between maps and you find them exactly how you left them? It's possible with con code and there are maps that use this in the AMC TC, and WGRealms 2's hub maps.

[Radar]

Micky C, on 25 January 2013 - 03:31 PM, said:

I think Helix said it's not too bad to change the TROR limit if anyone needs it

If so, those should have been raised to the max from the get-go.

[Micky C]

I'm sure there's some reason why he wouldn't have instantly done that. Besides, even Zaxtor barely managed to reach the limit, and he didn't have to go any higher.

[Mikko]

Never thought I'd live to see this day but I have hit the wall limit.

So, I'd like to have the wall capacity increased by, say, 300-400 walls. I'd like to see this done today but I can tolerate a delay so long as the updated wall count is available no later than tomorrow morning.

[Alan]

Not sure if trolling or srs. If srs, 16384 is the max value for a 14 bit value. So raising the limit will break your shit.

[Danukem]

Alan, on 25 March 2013 - 09:29 AM, said:

Not sure if trolling or srs.

trolling

Even if raising the wall limit were easy (which it is not) it would still be a bad idea imo because it would result in levels that were ridiculously huge and/or with horrible performance. Mappers may sometimes not like limitations, but they need them.

[Zaxtor]

Offtopic but ontopic for future updates


Well there is a thing in polymost it does.
When you make fairly big outdoor areas sprites and walls in distance vanishes, but reappear when as you get closer.
Made a test map.

Vanish starts about almost half of the whole large grid (not expanded to the highest one but expanded to 262144 long/wide). Or something

1024x1024 long line is the size of the largest grid square.

Starts when the visible sector is almost 101000 long. Even if you make multi sectors still does same.
Grid length is about 262144

Would be good to fix that incase if someone does huge valley, Huge outdoor levels, hill etc levels it wouldn't do this vanishing act.
Both sprites and sectors are effected. Except skies.

Example of what I mean
Pic 1 at the distance limit of the thing not doing it.
Pic 2 over the distance limit.

Once Trequonia is finished I might make a mod that is 100% polymost / 32bit etc.



BUT with standard 32b non polymost mapster/duke it doesn't do that.
Even if you make it tremendously long. Only in polymost-mode it vanishes.

Pic1 same length as when it starts to bug in polymost-mode, doesn't bug in non-polymost.
Pic2 almost length of the map grid. I made the shade paler or otherwise we don't see ending wall.

[Mikko]

Have you tried r_usenewshading 2? That should make everything in the distance visible. My new map would be totally ruined if I had to put up with the old terrible Polymost visibility that engulfs all distant locations in that stupid pitch black fog. I mean, where the hell is that fog supposed to come from? Might have made sense in 1996 but it sure hasn't made any sense in a long, long time.

[Zaxtor]

I don't think is a shading issues.
Is a vanishing issues.

Is black cus is (white lines)

If it would be a red elevated sector it would vanish and we would see the sky or w/e.