Help
Duke4.net
DNF #1
Duke 3D #1
Hendricks266, on 02 May 2016 - 05:26 PM, said:
We should enable it for 64-bit builds since all x86_64 processors support SSE2.
Makes sense to me.
PolymerNG - Xbox One and Windows 10
#122 Posted 02 May 2016 - 07:39 PM
This progress video is the same code as the previous video, but with Clear the Coast running at least 35-40fps. I'm not exactly sure since the debugger is crashing on me at the moment, and I don't have the debug text functions working yet.
PolymerNG on the Xbox One is now running at the same frame rate or better then regular Polymer does on my intel i7 with a Nvidia 970 PC.
PolymerNG on the Xbox One is now running at the same frame rate or better then regular Polymer does on my intel i7 with a Nvidia 970 PC.
This post has been edited by icecoldduke: 02 May 2016 - 07:46 PM
#124 Posted 03 May 2016 - 03:01 AM
Its all looking really good, I will have to build it on my xbone this afternoon and check it out.
When will we be getting model support?
I know its probably low priority, but the sooner it gets some basic model support, the sooner I can start putting some new things together
When will we be getting model support?
I know its probably low priority, but the sooner it gets some basic model support, the sooner I can start putting some new things together
#126 Posted 03 May 2016 - 03:34 AM
Spiker, on 02 May 2016 - 11:41 PM, said:
What is the draw distance of the new renderer?
Right now the far clip plane is set to the same value as it is in Polymer and Polymost. I'll make the far plane value a cvar.
Steveeeie, on 03 May 2016 - 03:01 AM, said:
Its all looking really good, I will have to build it on my xbone this afternoon and check it out.
When will we be getting model support?
I know its probably low priority, but the sooner it gets some basic model support, the sooner I can start putting some new things together
When will we be getting model support?
I know its probably low priority, but the sooner it gets some basic model support, the sooner I can start putting some new things together
I'll try to upload Milestone 3(currently Milestone 2.9 till I fix the flashing geo issue) to github tonight. Wait till I do that before you compile and run.
EDIT:
Models and high res assets are a priority after I fix the flashing geo issue.
This post has been edited by icecoldduke: 03 May 2016 - 05:07 AM
#127 Posted 03 May 2016 - 08:37 AM
Glduke reads textures names from the model file and automatically loads textures
Add models is very fast
Add models is very fast
#128 Posted 03 May 2016 - 08:42 AM
TON, on 03 May 2016 - 08:37 AM, said:
Glduke reads textures names from the model file and automatically loads textures
Add models is very fast
Add models is very fast
You fuckers are never going to let me live down Glduke are you
.
This post has been edited by icecoldduke: 03 May 2016 - 08:42 AM
#129 Posted 03 May 2016 - 08:49 AM
icecoldduke, on 03 May 2016 - 08:42 AM, said:
You fuckers are never going to let me live down Glduke are you .
.In the actual eduke32 you need to add 4-10 lines for each model to add it in props.def
This post has been edited by TON: 03 May 2016 - 08:50 AM
#130 Posted 03 May 2016 - 08:56 AM
TON, on 03 May 2016 - 08:49 AM, said:
In the actual eduke32 you need to add 4-10 lines for each model to add it in props.def
This post has been edited by icecoldduke: 03 May 2016 - 08:56 AM
#132 Posted 03 May 2016 - 09:05 AM
I only say that your model loader in glduke is better
But is a minor feature...
But is a minor feature...
#134 Posted 03 May 2016 - 03:36 PM
Milestone 2.9 is live on the PolynerNGPublic repository(P4 rev 184). For those keeping track, Milestone 2.0 was P4 rev 141.
EDIT:
Please note there seems to be a error with github's webviewer, it says I have a DukeNukem folder and a dukenukem folder(spelled the same, different case), when you sync you will not get two folders.
Also I did not upload the VirtualTextureBuilder project; so when you open Visual Studio it will tell you its a missing project. Thats a next milestone feature.
EDIT:
Please note there seems to be a error with github's webviewer, it says I have a DukeNukem folder and a dukenukem folder(spelled the same, different case), when you sync you will not get two folders.
Also I did not upload the VirtualTextureBuilder project; so when you open Visual Studio it will tell you its a missing project. Thats a next milestone feature
.
This post has been edited by icecoldduke: 03 May 2016 - 04:33 PM
#135 Posted 04 May 2016 - 07:33 PM
PolymerNG can now load hi-res textures. This isn't through Virtual Texturing. I have a cache system similar to that in eduke32. The cache file "game.payloads" has to be built offline. It takes the PNG's, converts them to DXT, and zlib compresses each payload(a payload is a DXT image blob). This file will evolve over time to add features exclusive to PolymerNG that would have conflicted with the existing cache system. The Shadow Warrior HRP that is on the Duke4 github, is 64mb, compressed sized of the "game.payloads"(which has all the images in the SW HRP) is 21mb.
All assets are loaded through the def file system. Going forward when releasing mods or hrp's for PolymerNG you will ONLY be releasing prebuilt data files such as the new game.payloads file, rather then a bunch of loose files. More on this later.
All assets are loaded through the def file system. Going forward when releasing mods or hrp's for PolymerNG you will ONLY be releasing prebuilt data files such as the new game.payloads file, rather then a bunch of loose files. More on this later.
This post has been edited by icecoldduke: 04 May 2016 - 07:41 PM
- Duke Plus Developer
-
#136 Posted 04 May 2016 - 08:23 PM
icecoldduke, on 04 May 2016 - 07:33 PM, said:
Going forward when releasing mods or hrp's for PolymerNG you will ONLY be releasing prebuilt data files such as the new game.payloads file, rather then a bunch of loose files. More on this later.
I have no doubt that is more efficient and better for performance etc etc but it does break all existing mods. Remember when some of us just about flipped our shit because you were going to insist that all skins be in tga format? This is much bigger than that. Not only will all mods have to be pre-processed to create the needed payloads before they will work again, but now it will be more difficult for other modders to create forks of existing mods. If someone wanted to fix or replace assets from DukePlus, for example, they would need access to the original assets which aren't necessarily released anywhere publicly once the processed version is out there. Or am I missing something?
#137 Posted 04 May 2016 - 08:35 PM
Trooper Dan, on 04 May 2016 - 08:23 PM, said:
I have no doubt that is more efficient and better for performance etc etc but it does break all existing mods. Remember when some of us just about flipped our shit because you were going to insist that all skins be in tga format? This is much bigger than that. Not only will all mods have to be pre-processed to create the needed payloads before they will work again, but now it will be more difficult for other modders to create forks of existing mods. If someone wanted to fix or replace assets from DukePlus, for example, they would need access to the original assets which aren't necessarily released anywhere publicly once the processed version is out there. Or am I missing something?
I brought this up now so we can have this conversation because I figured there would be some concerns. That is correct in order for mods to work, my thinking is they would have to go through the offline asset build system.
I'm not sure yet the best way forward because all of your concerns are valid. Each mod would have to be processed through the asset packaging system before PolymerNG could load it. This could be streamlined into a end user utility, if you guys want to continue to release loose data files. I have no problems with this. This would mean some users would have to wait for the asset building to finish before they can play your mod.
The reason for the asset packaging system is because it makes things faster to load. I want to have memory ready files on disk so I can pull shit off of disk and put it directly into memory without any processing what so ever. This will making streaming in data much better.
Can you guys live with having to release your loose files, and having the end user have to build the assets before they can run? Maybe we can have modders release two different packages, one with already built assets and one with loose files? As for already released mods, we can have a streamlined process for building the needed data for PolymerNG on the end user side. This will make it so the new system won't break existing mods.
I want to design a similar system for models, which also would be streamlined into a nice end-user utility.
This post has been edited by icecoldduke: 04 May 2016 - 08:42 PM
- Duke Plus Developer
-
#138 Posted 04 May 2016 - 08:46 PM
Just to be clear: I don't necessarily want to release loose files when I release mods in the future or updates of existing mods. I have no problem using the offline packaging system before I release something. The problem is that there are hundreds of mods out there which are already released and have def files and loose files. In many cases, the mod authors are no longer around. In other cases, the mod authors aren't interested in taking the time to update them, even though there may be some players out there who want to try them. So all I'm hoping for is that the packaging system be built into the final executable so that old mods will at least work, even though it will mean a longer load time for them.
#139 Posted 04 May 2016 - 08:50 PM
Trooper Dan, on 04 May 2016 - 08:46 PM, said:
Just to be clear: I don't necessarily want to release loose files when I release mods in the future or updates of existing mods. I have no problem using the offline packaging system before I release something. The problem is that there are hundreds of mods out there which are already released and have def files and loose files. In many cases, the mod authors are no longer around. In other cases, the mod authors aren't interested in taking the time to update them, even though there may be some players out there who want to try them. So all I'm hoping for is that the packaging system be built into the final executable so that old mods will at least work, even though it will mean a longer load time for them.
The reason why I don't want the asset building system as part of the game exe is I don't really want assets to be building on the console; or for that matter on lower end PC's. To build and run the game on the XB1 or Win10 UWP, your going to have to build UWP packages anyway(because I can't supply the Duke3d.grp file), I can make the offline build tool part of that process. This way we don't break pre-existing mod compatibility.
EDIT:
Win32 builds(non UWP builds) won't have to build a "game package" but the end user would still have to run the offline build tool, to ensure the assets are built.
EDIT2:
See post below, I'm going to do that.
This post has been edited by icecoldduke: 04 May 2016 - 09:04 PM
- Duke Plus Developer
-
#140 Posted 04 May 2016 - 08:59 PM
icecoldduke, on 04 May 2016 - 08:50 PM, said:
The reason why I don't want the asset building system as part of the game exe is I don't really want assets to be building on the console; or for that matter on lower end PC's. To build and run the game on the XB1 or Win10 UWP, your going to have to build UWP packages anyway(because I can't supply the Duke3d.grp file), I can make the offline build tool part of that process. This way we don't break pre-existing mod compatibility.
Mods haven't worked on consoles anyway, so no one should be butthurt if making them work requires an extra step.
But on a PC, there should be some continuity. The asset builder could even be a separate exe that is packaged with the game exe. If you try to run a mod without a payload (the game exe detects the presence of the def file or whatever) it says, "Hey, to make this work you just need to run the other included exe, just do that once and then it will work and you won't get this message again."
#141 Posted 04 May 2016 - 09:01 PM
Trooper Dan, on 04 May 2016 - 08:59 PM, said:
Mods haven't worked on consoles anyway, so no one should be butthurt if making them work requires an extra step.
But on a PC, there should be some continuity. The asset builder could even be a separate exe that is packaged with the game exe. If you try to run a mod without a payload (the game exe detects the presence of the def file or whatever) it says, "Hey, to make this work you just need to run the other included exe, just do that once and then it will work and you won't get this message again."
But on a PC, there should be some continuity. The asset builder could even be a separate exe that is packaged with the game exe. If you try to run a mod without a payload (the game exe detects the presence of the def file or whatever) it says, "Hey, to make this work you just need to run the other included exe, just do that once and then it will work and you won't get this message again."
Sounds good, Ill do that
.
- Duke Plus Developer
-
#142 Posted 04 May 2016 - 09:08 PM
icecoldduke, on 04 May 2016 - 09:01 PM, said:
Sounds good, Ill do that .
.I'd be interested to hear what TerminX and Hendricks266 have to say...
#143 Posted 05 May 2016 - 03:03 AM
Trooper Dan, on 04 May 2016 - 08:23 PM, said:
but now it will be more difficult for other modders to create forks of existing mods. If someone wanted to fix or replace assets from DukePlus, for example, they would need access to the original assets which aren't necessarily released anywhere publicly once the processed version is out there. Or am I missing something?
The common way for this to work is to split the repo into two parts src and dist.
The src should contain all of the source files and anything needed to compile it, with instructions on how to run the compiler.
The dist is usually empty until the compiler is run, when the compiler is run it populates dist with files that you can either run in the game or upload to the webs for others to enjoy.
To summarise, People who will want to tweak it will need to clone/branch the src repo. Regular people will just need to download the compiled files.
#144 Posted 05 May 2016 - 03:51 AM
I'm wondering if this will be a problem or not. There are people using an svn for the team to work on a mod. Every time a change is made by someone and a file or files are changed or created, does a new compile have to be run before everyone on the team can view or test the change? That could end up being hundreds of compiles during the course of development.
This post has been edited by Mark.: 05 May 2016 - 03:52 AM
#145 Posted 05 May 2016 - 04:11 AM
Mark., on 05 May 2016 - 03:51 AM, said:
I'm wondering if this will be a problem or not. There are people using an svn for the team to work on a mod. Every time a change is made by someone and a file or files are changed or created, does a new compile have to be run before everyone on the team can view or test the change? That could end up being hundreds of compiles during the course of development.
I've been doing a similar setup while working on my TC. I have all the data files outside of root separated for working, then I "compile"(zip) a grp file and copy it into root (via batch script) to run after changes. My grp is only 2MB so it only takes a few seconds to run but the process is already annoying and it's just me working on it.
- Polymancer
-
#146 Posted 05 May 2016 - 04:38 AM
I have personally seen a lot of people bitching about the time it takes for mods to load, so I don't think it's such a bad idea to have pre-compiled mod files. It might just make loading mods a lot easier, depending on how it is set up. I think a lot of it will hinge on how long it takes to compile the package of a typical mod.
- Polymancer
-
#147 Posted 05 May 2016 - 04:43 AM
Is there any way to run the compile on the server? So if you were working in an SVN, you could have a nightly, or twice daily automatic build.
#148 Posted 05 May 2016 - 04:45 AM
Mark., on 05 May 2016 - 03:51 AM, said:
I'm wondering if this will be a problem or not. There are people using an svn for the team to work on a mod. Every time a change is made by someone and a file or files are changed or created, does a new compile have to be run before everyone on the team can view or test the change? That could end up being hundreds of compiles during the course of development.
Drek, on 05 May 2016 - 04:11 AM, said:
I've been doing a similar setup while working on my TC. I have all the data files outside of root separated for working, then I "compile"(zip) a grp file and copy it into root (via batch script) to run after changes. My grp is only 2MB so it only takes a few seconds to run but the process is already annoying and it's just me working on it.
This another great point. During development the packaged data will have to be updated for all your changes. I was thinking for development we could have, instead of one big monster file, each individual blob would be stored right next to the source asset(similar to UE4). This way content guys can check in the compiled blobs. This new development mode would simply be called "Development". The end user mode would be called "Production". In "Production" mode you can only use these mega files(e.g. game.payloads), since they would be optimized for disk access. In development mode you can load these loose compiled blobs. This should fix the SVN issue, and make it so everyone one the team doesn't have to recompile the big file everytime they pull down changes.
The next issue is, do we run the offline asset compiling tool at startup even in development mode? Do we have the editor build the loose asset blobs? By the way having loose asset blobs would make it faster for doing the final asset packaging pass, since the blob is already prebuilt, we can just copy and paste that into the optimized mega files.
I want to let everyone know I haven't set in stone anything yet. I'm not trying to come into the community and change everyone's workflow. I'm trying to fully optimize every aspect of the PolymerNG engine, and this is a huge optimization; which comes with changes to the workflow, and I want to flush everything out the best we can.
EDIT:
Tea Monster, on 05 May 2016 - 04:43 AM, said:
Is there any way to run the compile on the server? So if you were working in an SVN, you could have a nightly, or twice daily automatic build.
Yes you could set something up to compile assets on the server side. The offline tool is a Win32 Console app that could be ran on anything, I'll make a linux version of the tool as well.
Tea Monster, on 05 May 2016 - 04:38 AM, said:
I have personally seen a lot of people bitching about the time it takes for mods to load, so I don't think it's such a bad idea to have pre-compiled mod files.
The idea is I want to have little to no load times. Imagine this, you guys tend to build maps that reach max limits pretty fast. Then you are forced to start another map to continue on. I want you to have seamless transitions between maps. The only way that can happen is if I have memory ready assets.
This post has been edited by icecoldduke: 05 May 2016 - 05:04 AM
- Weaponized Autism
-
#149 Posted 05 May 2016 - 12:51 PM
Our current texture manager and texture cache systems are not very smart, and they have been retrofitted several times to add features. HTTKC is making these systems buckle and they are quickly climbing my list of things to redo, since I have worked a lot with this code and know all the intricacies of the functionality they provide to modders. Feel free to write new systems as stopgaps for PolymerNG, but I'm going to write a new one that works for all GL renderers optimally. No ETA.
There are several things that could be done to drastically improve load times with our current system of loading PNGs from disk. Seamless would be a challenge, but I think it would also be even with precompiled assets.
icecoldduke, on 05 May 2016 - 04:45 AM, said:
I want you to have seamless transitions between maps. The only way that can happen is if I have memory ready assets.
There are several things that could be done to drastically improve load times with our current system of loading PNGs from disk. Seamless would be a challenge, but I think it would also be even with precompiled assets.
#150 Posted 05 May 2016 - 03:27 PM
Hendricks266, on 05 May 2016 - 12:51 PM, said:
There are several things that could be done to drastically improve load times with our current system of loading PNGs from disk. Seamless would be a challenge, but I think it would also be even with precompiled assets.
Would there be a good reason to want to load PNG's over precompiled assets during level load? The good thing with precompiled assets is they are memory ready. You just grab the data blob, decompress, copy to vram. No processing necessary. The same will go for models. There will be a big ass file containing all the models in the game. Stored in a memory ready format. I'm thinking developers that want seemless level generation they can have some kind of sector that would kick off the loading of the next map. In old maps that have episodes setup, during the score screen at the end of the map, we can start loading the next map, and have it ready by the time the user skips through the score screen.
Unfortunately both of these ideas would mean we have to clean up all the nasty ass global variables that is used by the map loading code, and throw all of that into a class.
EDIT:
Just saw your response in the other thread. I am curious what is the use case you forsee for having to support loose PNG loading in the engine?
This post has been edited by icecoldduke: 05 May 2016 - 03:30 PM
