Help
Duke4.net
DNF #1
Duke 3D #1
As for parental lock; it's one of those things that seems redundant but then maybe some person somewhere is still using it so it's hard to say.
EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#2641 Posted 19 January 2012 - 11:22 PM
I'm not even sure dynamic remap even worked for me, but maybe other people are getting use out of it
As for parental lock; it's one of those things that seems redundant but then maybe some person somewhere is still using it so it's hard to say.
As for parental lock; it's one of those things that seems redundant but then maybe some person somewhere is still using it so it's hard to say.
- Duke Plus Developer
-
#2642 Posted 20 January 2012 - 12:56 AM
James, on 19 January 2012 - 11:22 PM, said:
As for parental lock; it's one of those things that seems redundant but then maybe some person somewhere is still using it so it's hard to say.
The reason to keep parental lock is to to emulate as much as possible about the original game, not because people actually use it.
- Duke4.net topic/3513
-
#2643 Posted 22 January 2012 - 04:29 PM
Could someone please re-enable crosshair-coloring? [eduke32.cfg : CrosshairColor = "255,174,0"]
Btw, I guess the color of a rocket's smoke trail should turn white again in some distance.
Btw, I guess the color of a rocket's smoke trail should turn white again in some distance.
Attached thumbnail(s)
- Former VP of Media Operations
-
#2644 Posted 22 January 2012 - 05:37 PM
Probably another of the many problems caused by the sprite caching thing... it doesn't look like it's re-culling the lights as the sprite moves, I'll check it out in more detail.
- Honored Donor
-
#2645 Posted 22 January 2012 - 07:41 PM
When Duke is underwater, instead of his spotlight shadow looking like Duke, it appears to be that of the enforcer shooting his chaingun when stationary, and an enforcer running when moving. Looks like the tiles are mixed up when the sector lotag is 2.
This post has been edited by Micky C: 22 January 2012 - 07:44 PM
#2646 Posted 24 January 2012 - 07:43 AM
I have send to helixhorned another email regarding OpenGL Shading (this time its issue about Shading Scaling with distance and shade parameters):
==================================
==================================
This post has been edited by Daniel: 24 January 2012 - 07:43 AM
#2647 Posted 25 January 2012 - 01:43 PM
I have a question on what would be the most efficient way to make some repeating models.
example.
Say I have a small md3. It currently has 4 different versions, using 4 different tiles and 4 different skins, yet 1 model.
Would it be better (FPS/loading time) to make 1 skin, with no more than 4Xs the area up to a max of 1024^2 (where each old skin is moved to a corner or something) then make 4 md3s (once again small like 1-20 kb) each having different UV texture coords?
ADDED:
A pic is worth a million of my words
Is 4 SMALL md3s sharing 1 skin more efficient than 1 md3 using 4 skins?
example.
Say I have a small md3. It currently has 4 different versions, using 4 different tiles and 4 different skins, yet 1 model.
Would it be better (FPS/loading time) to make 1 skin, with no more than 4Xs the area up to a max of 1024^2 (where each old skin is moved to a corner or something) then make 4 md3s (once again small like 1-20 kb) each having different UV texture coords?
ADDED:
A pic is worth a million of my words
Is 4 SMALL md3s sharing 1 skin more efficient than 1 md3 using 4 skins?
This post has been edited by Drek: 25 January 2012 - 05:48 PM
- Former VP of Media Operations
-
#2648 Posted 25 January 2012 - 05:52 PM
Is there a reason you can't just use one model on one tile that has 4 skins defined and cycle through them with palettes? Sorry if I missed something in your post that invalidates that.
- Honored Donor
-
#2649 Posted 25 January 2012 - 08:28 PM
I believe he's asking which method out of and is less computationally intensive, both in regards to framerate and loading time.
Quote
4 SMALL md3s sharing 1 skin
Quote
1 md3 using 4 skins?
- Duke Plus Developer
-
#2650 Posted 25 January 2012 - 08:45 PM
It's impossible to answer Drek's question without more information.
As for Plagman's question: I think the reason he would want the skins to be on different tiles, rather than on the same tile with different palettes, is that with different tiles you can make images for the mapster tile selector showing the different skins. That makes it easier on the mapper, but you can't do that if they are all on one tile (plus the mapper would have to remember which pals the skins are on).
As for Plagman's question: I think the reason he would want the skins to be on different tiles, rather than on the same tile with different palettes, is that with different tiles you can make images for the mapster tile selector showing the different skins. That makes it easier on the mapper, but you can't do that if they are all on one tile (plus the mapper would have to remember which pals the skins are on).
#2651 Posted 26 January 2012 - 04:30 AM
Is there an extra thread that explains more about polymer?
I guess many questeions have alraedy been asked about it in this thread, but there are too many posts in here to find answers without searching an awful long time, taking even more time when you don't understand english very well like me.
For example, what does limitate the fps?
I just looked on GPU and CPU-usage during playing and realized that GPU-usage is at 20% and CPU-usage at 50%, but in some scenes I got under 30 fps.
It would be much easier to bulid maps if I knew more about it to avoid low framerates.
I know that these questeions have been asked before and I was searching for answers, but didn't find good ones.
I also have visited the eduke32 wiki page to learn more about mapster32 and some of its new features like TROR, but I found nothing about that.
I know that Plagman and TX have better things to do than answering stupid questions, so an extra thread with more informations about Polymer would be awesum.
I guess many questeions have alraedy been asked about it in this thread, but there are too many posts in here to find answers without searching an awful long time, taking even more time when you don't understand english very well like me.
For example, what does limitate the fps?
I just looked on GPU and CPU-usage during playing and realized that GPU-usage is at 20% and CPU-usage at 50%, but in some scenes I got under 30 fps.
It would be much easier to bulid maps if I knew more about it to avoid low framerates.
I know that these questeions have been asked before and I was searching for answers, but didn't find good ones.
I also have visited the eduke32 wiki page to learn more about mapster32 and some of its new features like TROR, but I found nothing about that.
I know that Plagman and TX have better things to do than answering stupid questions, so an extra thread with more informations about Polymer would be awesum.
This post has been edited by Mia Max: 26 January 2012 - 04:30 AM
- Duke Plus Developer
-
#2652 Posted 26 January 2012 - 08:56 AM
Mia Max, on 26 January 2012 - 04:30 AM, said:
Is there an extra thread that explains more about polymer?
I guess many questeions have alraedy been asked about it in this thread, but there are too many posts in here to find answers without searching an awful long time, taking even more time when you don't understand english very well like me.
For example, what does limitate the fps?
I just looked on GPU and CPU-usage during playing and realized that GPU-usage is at 20% and CPU-usage at 50%, but in some scenes I got under 30 fps.
It would be much easier to bulid maps if I knew more about it to avoid low framerates.
I guess many questeions have alraedy been asked about it in this thread, but there are too many posts in here to find answers without searching an awful long time, taking even more time when you don't understand english very well like me.
For example, what does limitate the fps?
I just looked on GPU and CPU-usage during playing and realized that GPU-usage is at 20% and CPU-usage at 50%, but in some scenes I got under 30 fps.
It would be much easier to bulid maps if I knew more about it to avoid low framerates.
For now, the only way you can avoid low fps is by keeping your map fairly simple in construction, and also making sure that there are only a few lights (especially spotlights) which are shining on rendered surfaces at any given point in the map. It's fine to use detailed textured and models, though. I asked about Polymer optimizations a while ago in a different thread, and here is how Plagman replied. It's the most detailed information that we have about it to date, and I believe it all still applies. I underlined the part which seems most relevant to explaining the low fps.
http://forums.duke4....dpost__p__88492
Plagman, on 31 May 2011 - 09:39 PM, said:
The problem isn't that we need to brainstorm for optimization ideas, it's that I have to break everything and put it together in a different fashion. It's been known from the start; I've done it like that at first because it's always easier to get something that works right than something that works right and well. Too bad that only applies to the short term.
There are several different problems; one aspect a map is made of a lot of planes that are all drawn separately from front to back; materials are switched between each plane, and each time a red wall is crossed a "portal" is drawn to determine if the sector that follows needs to be queued for rendering or not. This constant material switching and drawing only one plane at a time isn't really efficient. The former causes a lot of state validation and thrashing, while the latter doesn't utilize the GPU in an efficient fashion. It's constantly submitting tiny pieces of work and reaping it, causing a lot of idle time waiting for the results. This also causes big maps with lots of red walls to be insanely complex to draw.
Another problem is that the multi-pass drawing approach uses a lot of fillrate as soon as a fairly big plane gets a few too many lights on it.
Things that needs to be done:
- Move the diffuse modulation from the material to the vertex attribute. That would cause the amount of different materials in a map to be all the different tiles used, instead of the more complex tile X shade.
- Move plane vertex attributes from several unique vertex buffers to a single storage or several depending on the staticness of the data.
- With a more reasonable material count and stuff sharing buffers, we can start batching planes together. To leverage that, throw planes into material buckets instead of rendering them right away. When we're done building index buffers for the buckets, submit them in one big go (one per material).
- Change the HSR walking to do a first pass before doing the actual shaded drawing. This means that in the event that occlusion queries have to be reaped, we can get the result a lot faster since we're pushing a lot less pixels using a passthrough fragment program.
- For rendering the shadow maps, we only need materials for sprite silhouettes. The rest can be batched in a single draw call after building the right index buffer, same as above. This will be a lot faster.
(Even) bigger projects:
- Defer the lighting model to shade from a fat buffer instead of inline. This eliminates two very expensive steps, light culling and multi-pass drawing.
- Instance models together.
There are several different problems; one aspect a map is made of a lot of planes that are all drawn separately from front to back; materials are switched between each plane, and each time a red wall is crossed a "portal" is drawn to determine if the sector that follows needs to be queued for rendering or not. This constant material switching and drawing only one plane at a time isn't really efficient. The former causes a lot of state validation and thrashing, while the latter doesn't utilize the GPU in an efficient fashion. It's constantly submitting tiny pieces of work and reaping it, causing a lot of idle time waiting for the results. This also causes big maps with lots of red walls to be insanely complex to draw.
Another problem is that the multi-pass drawing approach uses a lot of fillrate as soon as a fairly big plane gets a few too many lights on it.
Things that needs to be done:
- Move the diffuse modulation from the material to the vertex attribute. That would cause the amount of different materials in a map to be all the different tiles used, instead of the more complex tile X shade.
- Move plane vertex attributes from several unique vertex buffers to a single storage or several depending on the staticness of the data.
- With a more reasonable material count and stuff sharing buffers, we can start batching planes together. To leverage that, throw planes into material buckets instead of rendering them right away. When we're done building index buffers for the buckets, submit them in one big go (one per material).
- Change the HSR walking to do a first pass before doing the actual shaded drawing. This means that in the event that occlusion queries have to be reaped, we can get the result a lot faster since we're pushing a lot less pixels using a passthrough fragment program.
- For rendering the shadow maps, we only need materials for sprite silhouettes. The rest can be batched in a single draw call after building the right index buffer, same as above. This will be a lot faster.
(Even) bigger projects:
- Defer the lighting model to shade from a fat buffer instead of inline. This eliminates two very expensive steps, light culling and multi-pass drawing.
- Instance models together.
#2653 Posted 26 January 2012 - 09:41 AM
Thank you, DeeperThought.
Now I understand.
I already avoid lights.
But I didn't know that many sectors/red walls are a big problem.
So it's not that important which hardware you have as it is limited by the idel times.
In my new map I have still 30 fps in the biggest area, so other people with less good hardware should have nearly the same framerate as my CPU and GPU are at 50% and 20% ?
I just want to make sure that the map is playable for most people.
I played my old map Desertbase with Polymer and it isn't enjoyable due to 15 fps and less.
Now I understand.
I already avoid lights.
But I didn't know that many sectors/red walls are a big problem.
So it's not that important which hardware you have as it is limited by the idel times.
In my new map I have still 30 fps in the biggest area, so other people with less good hardware should have nearly the same framerate as my CPU and GPU are at 50% and 20% ?
I just want to make sure that the map is playable for most people.
I played my old map Desertbase with Polymer and it isn't enjoyable due to 15 fps and less.
- EDuke32 Developer
-
#2654 Posted 26 January 2012 - 09:46 AM
LeoD, on 22 January 2012 - 04:29 PM, said:
Could someone please re-enable crosshair-coloring? [eduke32.cfg : CrosshairColor = "255,174,0"]
Seems like a configuration reader/writer issue to me...
Daniel, on 24 January 2012 - 07:43 AM, said:
I have send to helixhorned another email regarding OpenGL Shading (this time its issue about Shading Scaling with distance and shade parameters):
I don't think that shades with large negative values are used very often, and if they are, it's to make something visible all the way...
So, such perfectionism is of little practical relevance, IMO.
#2655 Posted 26 January 2012 - 01:08 PM
Plagman, on 25 January 2012 - 05:52 PM, said:
Is there a reason you can't just use one model on one tile that has 4 skins defined and cycle through them with palettes? Sorry if I missed something in your post that invalidates that.
It's like DT said, it's easier to map with when each different version is a new tile #, also some md3s need to be assigned to unique tiles for sprite like special effects to work.
Quote
Myself,
Is 4 SMALL md3s sharing 1 skin more efficient than 1 md3 using 4 skins?
Is 4 SMALL md3s sharing 1 skin more efficient than 1 md3 using 4 skins?
I think I now know the current answer to my ?
Every tile being defined loads it own skin, no matter if it has been loaded already or not.
Therefore, it is more efficient (for now) to use 4 different small skins than 1 large skin.
Am I right? I've made assumptions based on DTs reply to Mia Maxs question about FPS and polymer.
Would using Alt Pals be any faster? Each alt pal is loaded at start up also, no?
- Weaponized Autism
-
#2656 Posted 26 January 2012 - 06:14 PM
Hendricks266, on 19 January 2012 - 04:14 PM, said:
Has anyone had success building EDuke32 with LTO=1 on MinGW32-GCC? I get these errors when linking the executable:
http://pastebin.com/7WbUqcNN
A quick grep of the source reveals that the problem symbols are used in inline asm code:
http://pastebin.com/90jjQC4D
http://pastebin.com/7WbUqcNN
A quick grep of the source reveals that the problem symbols are used in inline asm code:
http://pastebin.com/90jjQC4D
Even after r2271 I still encounter this issue.
Quote
r2271 | helixhorned | 2012-01-20 05:23:53 -0800 (Fri, 20 Jan 2012) | 4 lines
Use ATTRIBUTE((used)) for symbols used only in inline asm.
This may fix compilation for optimized builds with GCC or clang where
the compiler would otherwise decide that those symbols are unused.
Use ATTRIBUTE((used)) for symbols used only in inline asm.
This may fix compilation for optimized builds with GCC or clang where
the compiler would otherwise decide that those symbols are unused.
- Duke4.net topic/3513
-
#2657 Posted 28 January 2012 - 05:59 PM
LeoD, on 22 January 2012 - 04:29 PM, said:
Could someone please re-enable crosshair-coloring? [eduke32.cfg : CrosshairColor = "255,174,0"]
Helixhorned, on 26 January 2012 - 09:46 AM, said:
Seems like a configuration reader/writer issue to me...
Outcome of source code rape between r1624 and r1627.
- el fundador
-
#2658 Posted 28 January 2012 - 07:45 PM
It looks like nobody ever set anything up to add the crosshair color information to the new style cfg... should be pretty easy to fix.
- EDuke32 Developer
-
#2659 Posted 29 January 2012 - 12:32 PM
Attention, DON'T use r2299 to save games. I had disabled the formerly non-functional dynamicremap feature (TX re-enabled the fixed one in r2300), but that wasn't entirely without side-effects. Sorry!
edit: the real breakage comes when trying to load an r2299 save with a later build.
edit: the real breakage comes when trying to load an r2299 save with a later build.
- Duke4.net topic/3513
-
#2660 Posted 29 January 2012 - 06:00 PM
Today I somewhat restored my broken compile environment. But building the debug version fails for the backtrace DLL. Any ideas?
Attached File(s)
-
make RELEASE=0-4.5.2.log (292bytes)
Number of downloads: 536 -
make RELEASE=0-4.6.2.log (377bytes)
Number of downloads: 556
- Weaponized Autism
-
#2661 Posted 29 January 2012 - 11:14 PM
I get similar errors, but a whole lot more of them. The solution I found was to add "-lintl" to the makefile entry for ebacktrace1.dll. Only add this if you get errors.
Both Helix and synthesis don't have this problem, and we do not want to make this change upstream because we don't want any dependencies for the dll. I am at a loss.
Index: polymer/eduke32/Makefile =================================================================== --- polymer/eduke32/Makefile (revision 2290) +++ polymer/eduke32/Makefile (working copy) @@ -336,7 +336,7 @@ # RULES $(EBACKTRACEDLL): Windows/src/backtrace.c - if $(CC) -O2 -shared -Wall -Wextra -o $@ $^ -lbfd -liberty -limagehlp; then $(COMPILE_OK); else $(COMPILE_FAILED); fi + if $(CC) -O2 -shared -Wall -Wextra -o $@ $^ -lbfd -lintl -liberty -limagehlp; then $(COMPILE_OK); else $(COMPILE_FAILED); fi $(OBJ)/%.$o: $(SRC)/%.nasm $(COMPILE_STATUS)
Both Helix and synthesis don't have this problem, and we do not want to make this change upstream because we don't want any dependencies for the dll. I am at a loss.
This post has been edited by Hendricks266: 04 March 2012 - 11:35 PM
- el fundador
-
#2662 Posted 30 January 2012 - 12:50 PM
Hendricks266, on 29 January 2012 - 11:14 PM, said:
I get similar errors, but a whole lot more of them. The solution I found was to add "-lintl" to the makefile entry for ebacktrace1.dll.
Both Helix and synthesis don't have this problem, and we do not want to make this change upstream because we don't want any dependencies for the dll. I am at a loss.
Index: polymer/eduke32/Makefile =================================================================== --- polymer/eduke32/Makefile (revision 2290) +++ polymer/eduke32/Makefile (working copy) @@ -336,7 +336,7 @@ # RULES $(EBACKTRACEDLL): Windows/src/backtrace.c - if $(CC) -O2 -shared -Wall -Wextra -o $@ $^ -lbfd -liberty -limagehlp; then $(COMPILE_OK); else $(COMPILE_FAILED); fi + if $(CC) -O2 -shared -Wall -Wextra -o $@ $^ -lbfd -lintl -liberty -limagehlp; then $(COMPILE_OK); else $(COMPILE_FAILED); fi $(OBJ)/%.$o: $(SRC)/%.nasm $(COMPILE_STATUS)
Both Helix and synthesis don't have this problem, and we do not want to make this change upstream because we don't want any dependencies for the dll. I am at a loss.
Same problem here, actually.
- Duke4.net topic/3513
-
#2663 Posted 30 January 2012 - 01:11 PM
Hendricks266, on 29 January 2012 - 11:14 PM, said:
+ if $(CC) -O2 -shared -Wall -Wextra -o $@ $^ -lbfd -lintl -liberty -limagehlp; then $(COMPILE_OK); else $(COMPILE_FAILED); fi
Works. Thank you.
LeoD, on 22 January 2012 - 04:29 PM, said:
Could someone please re-enable crosshair-coloring? [eduke32.cfg : CrosshairColor = "255,174,0"]
Helixhorned, on 26 January 2012 - 09:46 AM, said:
Seems like a configuration reader/writer issue to me...
LeoD, on 28 January 2012 - 05:59 PM, said:
Outcome of source code rape between r1624 and r1627.
TX, on 28 January 2012 - 07:45 PM, said:
It looks like nobody ever set anything up to add the crosshair color information to the new style cfg... should be pretty easy to fix.
Yup. I simply reactivated the code block from line 716-741 in config.c (r2290). No idea about possible side effects, though.
This post has been edited by LeoD: 30 January 2012 - 01:13 PM
- Duke4.net topic/3513
-
#2664 Posted 04 February 2012 - 12:47 PM
Proposal:
What about adding an echo or version command/directive to the CON and DEF languages?
If these files could put out a version number it would be easy to identify outdated Mods or HRP versions when someone posts his eduke32.log.
What about adding an echo or version command/directive to the CON and DEF languages?
If these files could put out a version number it would be easy to identify outdated Mods or HRP versions when someone posts his eduke32.log.
#2666 Posted 05 February 2012 - 01:42 AM
Just saw this:
In the synthesis - this is cool but the black background displays infront of anything you put in EVENT_DISPLAYMENUREST which shouldn't be right since it makes everything you put in there darker. Is it possible to change it so that EVENT_DISPLAYMENUREST comes first and then the black background appears?
Quote
EDuke32: When in menus, always draw a black (33%) translucent background.
In the synthesis - this is cool but the black background displays infront of anything you put in EVENT_DISPLAYMENUREST which shouldn't be right since it makes everything you put in there darker. Is it possible to change it so that EVENT_DISPLAYMENUREST comes first and then the black background appears?
- EDuke32 Developer
-
#2667 Posted 06 February 2012 - 09:45 AM
DISPLAYMENUREST executes after the black background, so everything drawn there will not be faded.
But... you have e.g. the player character drawn in EVENT_DISPLAYMENU, not ~REST.
But... you have e.g. the player character drawn in EVENT_DISPLAYMENU, not ~REST.
#2668 Posted 06 February 2012 - 10:00 AM
DUHHHH sorry I forgot about that completely
EDIT: actually hold on, that stuff displays OVER the main text though doesn't it?
EDIT2: Yeah, stuff put in there overlaps the main menu text. maybe a return var or something that disables the black background for mod users?
EDIT: actually hold on, that stuff displays OVER the main text though doesn't it?
EDIT2: Yeah, stuff put in there overlaps the main menu text. maybe a return var or something that disables the black background for mod users?
This post has been edited by James: 06 February 2012 - 10:02 AM
- el fundador
-
#2670 Posted 08 February 2012 - 11:22 AM
I think you can, but I'm not 100% positive. You might be able to assign a skybox to each frame of an animated tile and have that work... if not, it's definitely something we should hack in.
