PolymerNG - Xbox One and Windows 10
#61 Posted 28 April 2016 - 08:14 PM
#62 Posted 28 April 2016 - 09:09 PM
#63 Posted 30 April 2016 - 03:04 PM
This post has been edited by icecoldduke: 30 April 2016 - 03:17 PM
#65 Posted 30 April 2016 - 03:27 PM
This post has been edited by icecoldduke: 30 April 2016 - 03:28 PM
#67 Posted 30 April 2016 - 03:34 PM
icecoldduke, on 20 April 2016 - 03:27 PM, said:
Bringing up the menu is simple, but does the game crash once you enter a level? There is some problem in SW's code related to our increased engine limits that caused severe crashes when I was last working on VoidSW. Besides that, there must be countless game code features that are broken, such as screen tinting, CD audio, etc.
It honestly feels like you're making a UWP-specific fork of the project with no hope for merging.
#68 Posted 30 April 2016 - 03:43 PM
Hendricks266, on 30 April 2016 - 03:34 PM, said:
Bringing up the menu is simple, but does the game crash once you enter a level? There is some problem in SW's code related to our increased engine limits that caused severe crashes when I was last working on VoidSW.
It honestly feels like you're making a UWP-specific fork of the project with no hope for merging.
I did notice the sw folder. I figured you guys were doing some work on it, but I had no idea what state it was in; so I opted to take code I knew worked. So far I haven't touched the engine code, so I'm not modifying any systems to modify a specific use case. The code will be easy to merge since I didn't have to touch any engine code thus far to get SW working.
The game code wasn't that bad to bring over, it was about 8 hours of renaming tilesizx and tilesizy to the struct version. I also had to do a decent amount of syntax modifications to get it to compile under the C++ compiler. You guys also changed vector input for various functions to use the vec3_t class. Then there was that stupid TRAVERSE macro that had to be fixed as well.
Getting sound/music hooked up also wasn't hard. None of this was particularly hard, so far its just been time consuming(8 hours of nasty grunt work). I'm aware getting the game to run into the main menu isn't the same as getting the game into a map.
I'll let you know what I find when I get into a map and see were the current fuckage is at.
This post has been edited by icecoldduke: 30 April 2016 - 03:47 PM
#69 Posted 30 April 2016 - 03:45 PM
I speak of "systems" in the abstract sense, such as how the SW codebase is a system. The editor is a system. The makefile is a system. Input, sound, music, ANM files, RTS files, startup windows, GRP scanning, Steam path autodetection, CFG files, the console. There are many systems in place for game and editor and engine to interact, which have been augmented since the DOS days and JFDuke3D days (as you noticed), and which will need further work for all the games and editors to be able to coexist in one EXE.
#70 Posted 30 April 2016 - 03:53 PM
Hendricks266, on 30 April 2016 - 03:45 PM, said:
I speak of "systems" in the abstract sense, such as how the SW codebase is a system. The editor is a system. The makefile is a system. There are many systems in place for game and editor and engine to interact, which have been augmented since the DOS days and JFDuke3D days (as you noticed), and which will need further work for all the games and editors to be able to coexist in one EXE.
When it comes time to merge my work back over to main, is there a reason why you wouldn't take my SW changes and ditch whats already in the repository? How far does the current code get? By the sounds of it, the code thats in the duke4 depot doesn't get into a map atm. I have no problems leveraging some of the work thats there but now that I have everything compiling and working I don't want to ditch it.
Getting SW and Duke3D working helps the codebase alot. In my opinion this helps flush out bugs with the system, which is what my goal is right now. I want to get SW, DUKE3D and BLOOMCM working 100% before I continue adding rendering features. I want to know the base renderer is working 100% and is fast. The delta's between how content is built and passed down the build engine between SW, DUKE3D and even eduke32 mods such as Blood CM, should expose most of the bugs I have within the PolymerNG engine.
EDIT:
So then if source/sw/ doesn't even compile why would I have used it as a base . I want to work with you on this, and if I can get the game so its playable, that seems like it would get the duke4 depot ahead and you guys can go in and add in all the specific new eduke32 items.
This post has been edited by icecoldduke: 30 April 2016 - 04:16 PM
#71 Posted 30 April 2016 - 04:13 PM
In summary, keeping the work I have done and my method of doing it will result in a better final product. I am unable to articulate my thoughts any further.
Don't bother merging the source/sw/ work or spending time making the game playable. It will be a time sink for you. Focus on the renderer itself, since that is the unique strength that you bring to the team.
#72 Posted 30 April 2016 - 04:26 PM
Hendricks266, on 30 April 2016 - 04:13 PM, said:
In summary, keeping the work I have done and my method of doing it will result in a better final product. I am unable to articulate my thoughts any further.
Don't bother merging the source/sw/ work or spending time making the game playable. It will be a time sink for you. Focus on the renderer itself, since that is the unique strength that you bring to the team.
I feel having more test cases to stress PolymerNG is the best way for me to find bugs. I plan on marching forward on getting SW up and into a map. I'll let you know what I find.
#73 Posted 30 April 2016 - 04:29 PM
Helixhorned has often used my work for stress-testing purposes. Not sure if that's a good thing or not
This post has been edited by Micky C: 30 April 2016 - 04:31 PM
#74 Posted 30 April 2016 - 04:33 PM
Micky C, on 30 April 2016 - 04:29 PM, said:
Helixhorned has often used my work for stress-testing purposes. Not sure if that's a good thing or not
It isn't just the workload; the process of how the data gets sent to the renderer is also important. Which is why SW is important.
This post has been edited by icecoldduke: 30 April 2016 - 04:35 PM
#75 Posted 30 April 2016 - 04:41 PM
#77 Posted 30 April 2016 - 05:45 PM
#define SIZ(array) (sizeof(array)/sizeof(array[0]))
Used like this:
#define NORM_SPRITE(val) ((val) & (SIZ(sprite) - 1)) #define NORM_WALL(val) ((val) & (SIZ(wall) - 1)) #define NORM_SECTOR(val) ((val) & (SIZ(sector) - 1))
When Sprite, Wall and Sector are all pointer arrays, I'm assuming the intent of the SIZ macro is to do sizeof the full array / sizeof single item in the array? As its written it would do size of pointer / sizeof single item.
EDIT:
It seems my assumptions are correct since in build.h in the jonof code, they are using fixed sized arrays.
This code fixes the crash.
// jmarshall //#define NORM_SPRITE(val) ((val) & (SIZ(sprite) - 1)) //#define NORM_WALL(val) ((val) & (SIZ(wall) - 1)) //#define NORM_SECTOR(val) ((val) & (SIZ(sector) - 1)) #define NORM_SPRITE(val) ((val) & (MAXSPRITES - 1)) #define NORM_WALL(val) ((val) & (MAXWALLS - 1)) #define NORM_SECTOR(val) ((val) & (MAXSECTORS - 1)) // jmarshall end
This post has been edited by icecoldduke: 30 April 2016 - 05:59 PM
#78 Posted 30 April 2016 - 06:31 PM
Hendricks266, on 30 April 2016 - 03:34 PM, said:
The code fix above fixes the crash and I am now able to get into a map. This is a debug build, so performance is crap. It's also interesting the monster doesn't try to attack me.
#79 Posted 30 April 2016 - 07:42 PM
#80 Posted 30 April 2016 - 07:50 PM
Hendricks266, on 30 April 2016 - 07:42 PM, said:
It's odd that moving the code over to a newer version of the engine is causing AI issues, since the build engine doesn't do anything AI related. One possible explanation: If the game stores some AI states in the sprite data and we might be bashing it on the engine side?
I'm just going to have to do some more debugging and figure this out. .
EDIT:
I fixed the st1 and other random sprite garbage that you see in that video. AI still acting stupid. I'll post another video before I got to bed.
This post has been edited by icecoldduke: 30 April 2016 - 08:27 PM
#81 Posted 30 April 2016 - 08:26 PM
There are other transition issues, such as the use of what used to be sprite[].filler for something relating to flags in the CTF mode, but that one was easily fixed by adding a new member to the huge game-side per-actor struct that I forget the name of right now.
#82 Posted 30 April 2016 - 08:40 PM
Hendricks266, on 30 April 2016 - 08:26 PM, said:
There are other transition issues, such as the use of what used to be sprite[].filler for something relating to flags in the CTF mode, but that one was easily fixed by adding a new member to the huge game-side per-actor struct that I forget the name of right now.
Thanks for the info .
As a side note I will be forcing Visual Studio to fix all the shitty indenting there is the code. Do you have any objections?
This post has been edited by icecoldduke: 30 April 2016 - 08:43 PM
#83 Posted 30 April 2016 - 08:42 PM
#84 Posted 30 April 2016 - 08:52 PM
Hendricks266, on 30 April 2016 - 08:42 PM, said:
AStyle is fantastic, is there a option to format functions that thier return type on the line above the function decleration?
#85 Posted 30 April 2016 - 08:53 PM
#86 Posted 30 April 2016 - 09:30 PM
#88 Posted 30 April 2016 - 10:29 PM
This post has been edited by icecoldduke: 30 April 2016 - 10:30 PM