Duke4.net Forums: PolymerNG - Xbox One and Windows 10 - Duke4.net Forums

Jump to content

  • 41 Pages +
  • 1
  • 2
  • 3
  • 4
  • 5
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

PolymerNG - Xbox One and Windows 10

User is offline   The Commander 

  • I used to be a Brown Fuzzy Fruit, but I've changed bro...

#61

Is there a video of this that isn't recorded from a silly camera.
0

#62

I record from my cell phone mostly so people know this is a real port running on the XB1. I can probably stop doing that now though.
0

#63

I integrated the Shadow Warrior code(game code only from the Jonof repository) into the latest PolymerNG code(which is integrated into the latest EDuke32 code). A teaser of that working on XB1. Shadow Warrior support will be in the MS3 code drop.



This post has been edited by icecoldduke: 30 April 2016 - 03:17 PM

3

User is offline   Hendricks266 

  • Weaponized Autism

  #64

What the fuck?
0

#65

View PostHendricks266, on 30 April 2016 - 03:26 PM, said:

What the fuck?

What'd I do this time :angry:.

This post has been edited by icecoldduke: 30 April 2016 - 03:28 PM

0

User is offline   MusicallyInspired 

  • The Sarien Encounter

#66

What's the problem?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #67

I don't know where to start. I would have hoped that you took notice of the source/sw/ folder where I've already spent close to 100 hours porting JFSW's game code to our engine and setting up EDuke32 feature parity before having to put it aside for more important work. I don't know how you pulled off a linking build so quickly, but by doing this you're continuing to build systems specific to your own use cases that don't blend with everything else that the project as a whole is trying to do.

View Posticecoldduke, on 20 April 2016 - 03:27 PM, said:

I won't touch game code.

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.
2

#68

View PostHendricks266, on 30 April 2016 - 03:34 PM, said:

I don't know where to start. I would have hoped that you took notice of the source/sw/ folder where I've already spent close to 100 hours porting JFSW's game code to our engine and setting up EDuke32 feature parity before having to put it aside for more important work. I don't know how you pulled off a linking build so quickly, but by doing this you're continuing to build systems specific to your own use cases that don't blend with everything else that the project as a whole is trying to do.

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

0

User is offline   Hendricks266 

  • Weaponized Autism

  #69

Why even bother working on SW now? I understand that what you do on your own time for recreation is your business, but this work on SW doesn't assist EDuke32 as a project. It's simply not going to get merged, because you started at a point further back in the tree. Even then, what's in source/sw/ doesn't build, and I have only committed work that I consider complete.

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.
2

#70

View PostHendricks266, on 30 April 2016 - 03:45 PM, said:

Why even bother working on SW now? I understand that what you do on your own time for recreation is your business, but this work on SW doesn't assist EDuke32 as a project. It's simply not going to get merged, because you started at a point further back in the tree. Even then, what's in source/sw/ doesn't build, and I have only committed work that I consider complete.

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 :angry:. 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

0

User is offline   Hendricks266 

  • Weaponized Autism

  #71

By all means, use SW's sector effects as test cases to assist you in building your renderer. I will be thankful for that when VoidSW is ready.

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.
0

#72

View PostHendricks266, on 30 April 2016 - 04:13 PM, said:

By all means, use SW's sector effects as test cases to assist you in building your renderer. I will be thankful for that when VoidSW is ready.

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.
0

User is offline   Micky C 

  • Honored Donor

#73

If you plan to stress-test polymerNG, look no further than the AMC TC. Ghost Ship in Episode 2 is a particularly complicated map. Although there's a huge variety in level design and mappers so if you can render the full TC that'd cover a lot of cases.

Helixhorned has often used my work for stress-testing purposes. Not sure if that's a good thing or not Posted Image

This post has been edited by Micky C: 30 April 2016 - 04:31 PM

0

#74

View PostMicky C, on 30 April 2016 - 04:29 PM, said:

If you plan to stress-test polymerNG, look no further than the AMC TC. Ghost Ship in Episode 2 is a particularly complicated map. Although there's a huge variety in level design and mappers so if you can render the full TC that'd cover a lot of cases.

Helixhorned has often used my work for stress-testing purposes. Not sure if that's a good thing or not Posted Image

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

0

User is offline   Mark 

#75

Slightly off topic, is VoidSW going to support an HRP or is it going to be classic only?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #76

It will be able to support an HRP.
1

#77

So I found this little gem

#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

1

#78

View PostHendricks266, on 30 April 2016 - 03:34 PM, said:

Bringing up the menu is simple, but does the game crash once you enter a level?

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.


4

User is offline   Hendricks266 

  • Weaponized Autism

  #79

Cool, one down. There are other problems in the AI code, which you noticed. If you can throw a shuriken, it might also exhibit odd behavior where once it hits something it doesn't get deleted and keeps making the hit noise, moving slowly upwards until the game crashes.
0

#80

View PostHendricks266, on 30 April 2016 - 07:42 PM, said:

Cool, one down. There are other problems in the AI code, which you noticed. If you can throw a shuriken, it might also exhibit odd behavior where once it hits something it doesn't get deleted and keeps making the hit noise, moving slowly upwards until the game crashes.

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. :angry:.

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

0

User is offline   Hendricks266 

  • Weaponized Autism

  #81

The game does overload previously-unused bits of sprite[].cstat, wall[].cstat, and sector[].(floor|ceiling)stat that we've since added new meanings for, relating to Polymer, TROR, and some other stuff. I don't think this will cause AI problems, but will definitely cause rendering errors. Fortunately, these bits are strictly internal state data and are never used in any maps, so in my codebase I moved all of them (less than eight bits total) to a uint8_t[max(MAXSPRITES, MAXSECTORS, MAXWALLS)].

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.
0

#82

View PostHendricks266, on 30 April 2016 - 08:26 PM, said:

The game does overload previously-unused bits of sprite[].cstat, wall[].cstat, and sector[].(floor|ceiling)stat that we've since added new meanings for, relating to Polymer, TROR, and some other stuff. I don't think this will cause AI problems, but will definitely cause rendering errors. Fortunately, these bits are strictly internal state data and are never used in any maps, so in my codebase I moved all of them (less than eight bits total) to a uint8_t[max(MAXSPRITES, MAXSECTORS, MAXWALLS)].

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 :angry:.

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

0

User is offline   Hendricks266 

  • Weaponized Autism

  #83

The first thing I did on the code was run astyle and Uncrustify. What you do with your code is up to you, since I'm not throwing mine away.
1

#84

View PostHendricks266, on 30 April 2016 - 08:42 PM, said:

The first thing I did on the code was run astyle and Uncrustify. What you do with your code is up to you, since I'm not throwing mine away.

AStyle is fantastic, is there a option to format functions that thier return type on the line above the function decleration?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #85

I used Uncrustify because astyle didn't do everything I needed. It's been two years, I don't remember what options there are. :angry: I know TX also likes to use clang-format.
0

User is offline   TerminX 

  • el fundador

  #86

I like clang-format because you can get an extension to add it into VS.
0

#87

Awesome Work IceColdDuke
0

#88

As stated before I fixed the sprite bug as seen in the previous video. This was a nasty bug with the PolymerNG code, were I would still render hidden sprites when I earilied out of the sprite plane generation code. I also fixed the AI firing issue. Player can now fire with the controller. Player can now move around with the controller(can't look around yet). Performance is also better.



This post has been edited by icecoldduke: 30 April 2016 - 10:30 PM

6

User is offline   Tea Monster 

  • Polymancer

#89

Whoo- hoo!
0

User is offline   Spiker 

#90

Hendricks why are you so harsh all the time? Do you feel jelaous that ICD makes stuff you wanted to make on your own? Sorry, I'd rather not wait another 10 years for that if it happens at all. Please be more humble.
-3

Share this topic:


  • 41 Pages +
  • 1
  • 2
  • 3
  • 4
  • 5
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options