GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I am almost certain that I have read a long time ago that the "skew textures" feature was possible, but I am talking about a post from 2018, maybe it is not so easy to add that feature natively to GZDoom so they have simply left it in the forgetfulness.
I admit that I would also like an option like that, as well as rotating textures on walls, but unfortunately if you want to do something like that you have to skew or rotate the textures by a program like Photoshop or GIMP.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Is there a way to optimize GZDB so my brand-new Nvidia GPU can finally display 3D mode without any lag ?
By testing it right now I feel it's as laggy as my previous 8 years old computer and its integrated graphic card. I know my maps are resources-demanding but I should feel a hupe gap between those two, shouldn't I ?
Every time I move the camera direction, I experience a tiny "twitch" which is really annoying, as if my computer was too slow to render things properly... Any advices ?
By testing it right now I feel it's as laggy as my previous 8 years old computer and its integrated graphic card. I know my maps are resources-demanding but I should feel a hupe gap between those two, shouldn't I ?
Every time I move the camera direction, I experience a tiny "twitch" which is really annoying, as if my computer was too slow to render things properly... Any advices ?
- axredneck
- Posts: 354
- Joined: Mon Dec 11, 2017 2:09 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): Arch
- Graphics Processor: nVidia with Vulkan support
- Location: Russia
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Hide bottom panelSandro wrote:Any advices ?
- Kappes Buur
-
- Posts: 4120
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
A smooth movement in the 3D View Mode depends greatly onSandro wrote:Is there a way to optimize GZDB so my brand-new Nvidia GPU can finally display 3D mode without any lag ?
1. the size of the map
2. how many actors are visible
3. the viewdistance set in F5
With my old GTX660, movement is, in a fairly large map with a diagonal of ca 24000, quite smooth with viewdistance set to 9000. But going over a map size of ca 30000 and a fair number of 3D floors, movement is noticeably jerky.
However, boris made some optimizations in GZDBBF to that code in the editor, plus the viewdistance can now be set up to 64000.
Give that a try and see how it will work for you.R3088 | 4b86f545 | biwa | 19.10.2019, 16:52
--------------------------------------------------------------------------------
- Increased max view distance from 9000 to 64000 map units. Step size increased
from 200 to 500 map units
@ Improved performance of VisualBlockMap.GetFrustumRange so that high view
distances is actually usable. This does not do anything to the rendering speed,
so that's still slow
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Is there a way in GZDB to ask a texture to be scaled to fit a line's length but do so by tiling as often as needed to fill the line and only scale to take account of the remainder?
Hmmm... that probably doesn't make sense.
OK, if I have a line that's 258 long and a texture that's 128 wide, without scaling the texture will repeat so that it is used twice, but there will be two stray pixels of texture left over at the end. What I'm asking is, is there a way to make the two instances of the texture behave as if they were 258 wide instead of 256?
Equally, it could go the other way. If the line was 254 long, the normally 256 wide double instance would scale down to behave as if it was 254 as well.
At the moment, all I can find is the ctrl-alt-a combination that stretches a texture to the length of the line (so in my first example, a single instance of the 128 texture would be stretched to 258 wide - looking very stretched) or to try to fit it manually myself. The ctrl-alt-a function is very useful, but sometimes I need what I'm describing instead.
So, does this exist as a feature?
If not, is it something that would be easy to add?
Hmmm... that probably doesn't make sense.
OK, if I have a line that's 258 long and a texture that's 128 wide, without scaling the texture will repeat so that it is used twice, but there will be two stray pixels of texture left over at the end. What I'm asking is, is there a way to make the two instances of the texture behave as if they were 258 wide instead of 256?
Equally, it could go the other way. If the line was 254 long, the normally 256 wide double instance would scale down to behave as if it was 254 as well.
At the moment, all I can find is the ctrl-alt-a combination that stretches a texture to the length of the line (so in my first example, a single instance of the 128 texture would be stretched to 258 wide - looking very stretched) or to try to fit it manually myself. The ctrl-alt-a function is very useful, but sometimes I need what I'm describing instead.
So, does this exist as a feature?
If not, is it something that would be easy to add?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Isn't that exactly what the "Texture Repeating" options in the "Fit Texture" dialog do?
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Well that description certainly sounds like it would do what I'm asking about. I'll have to check when I get home from work. Don't know why I didn't spot it. I was looking and didn't see anything but, apparently, there it was - right in front of me.
Thanks once again.
[edit]
And, yes, that's exactly what I was looking for - and it's even more flexible than I hoped. I don't know how many times I've had that dialogue open but I simply hadn't realised what that bit of it was doing. I guess every time that I tried it, it was in a situation where the effects weren't obvious.
Brilliant stuff.
[/edit]
Thanks once again.
[edit]
And, yes, that's exactly what I was looking for - and it's even more flexible than I hoped. I don't know how many times I've had that dialogue open but I simply hadn't realised what that bit of it was doing. I guess every time that I tried it, it was in a situation where the effects weren't obvious.
Brilliant stuff.
[/edit]
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
This code gives me an "ZSCRIPT error in "test\zscript\misc.txt", line 92. Expected comma or ;, got <Token.Semicolon (;)>."
Code: Select all
class Stuff : Actor // at the file, this is line 97
{
Default
{
Mass 9999999999; //commenting this line solves the bug
}
}
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
That number is too big to fit into a signed 32 bit int. GZDoom doesn't parse that number correctly, either. See https://zdoom.org/wiki/Actor_properties#Mass if you need to give it a large mass.
This could obviously handled better by GZDB-BF, the question is how. I see two options:
This could obviously handled better by GZDB-BF, the question is how. I see two options:
- Still abort parsing, but report a sensible error message
- Do not abort parsing, report a warning, and set the value to the min/max value of the data type. But I'm not sure if that has any downsides, as this would apply to any parsed number
- Curunir
- Posts: 1040
- Joined: Sun Nov 02, 2003 11:24 am
- Graphics Processor: ATI/AMD with Vulkan/Metal Support
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I tried running GZDB BF on a PC that is not my usual one and it won't start.
Win 10 64 bit, i3 CPU with an Intel HD 630 integrated GPU, I already have up-to-date DX and .NET.
Is that the GPU choking things up?
Edit: Figured it out - it NEEDS SlimDX Runtime. Had to grab it from a Google Code archive.
Win 10 64 bit, i3 CPU with an Intel HD 630 integrated GPU, I already have up-to-date DX and .NET.
Is that the GPU choking things up?
Edit: Figured it out - it NEEDS SlimDX Runtime. Had to grab it from a Google Code archive.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
GzDoom doesn't give any warnings and I never noticed anything unusual with the actor in-game. I think GZDB and GzDoom may handle large ints differentlyboris wrote:That number is too big to fit into a signed 32 bit int. GZDoom doesn't parse that number correctly, either. See https://zdoom.org/wiki/Actor_properties#Mass if you need to give it a large mass.
This could obviously handled better by GZDB-BF, the question is how. I see two options:
- Still abort parsing, but report a sensible error message
- Do not abort parsing, report a warning, and set the value to the min/max value of the data type. But I'm not sure if that has any downsides, as this would apply to any parsed number
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Yes, GZDoom doesn't print any warning, but it you print your mass to console you'll see that it's a completely different value.Pedro vc wrote:GzDoom doesn't give any warnings and I never noticed anything unusual with the actor in-game. I think GZDB and GzDoom may handle large ints differently
Anyway, I commited the change that clamps the values and print a warning.
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
I see, thanksboris wrote:Yes, GZDoom doesn't print any warning, but it you print your mass to console you'll see that it's a completely different value.Pedro vc wrote:GzDoom doesn't give any warnings and I never noticed anything unusual with the actor in-game. I think GZDB and GzDoom may handle large ints differently
Anyway, I commited the change that clamps the values and print a warning.
- Kappes Buur
-
- Posts: 4120
- Joined: Thu Jul 17, 2003 12:19 am
- Graphics Processor: nVidia (Legacy GZDoom)
- Location: British Columbia, Canada
- Contact:
Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB
Xmas came early
thank you boris
season's greetings to all
thank you boris
season's greetings to all