[icecoldduke]

Hey,

I couldn't find my old post, but quite a few people have been asking what I'm doing with my Unity Build C# port. I didn't plan to unveil this now, but just wanted to catch people up who were interested. I couldn't find my old post, sorry about that Evan .

I have Duke Nukem 3D ported to C#.




I need to preface it with, its not that playable yet. I'm confident in 90% code, except for the con-script virtual machine. The layers of pointers in that system are driving my crazy, so that's one of the biggest reasons I'm sharing right now, I need some help understanding what these three pointers actually do: actorscrptr and insptr. I ran some tests and I think I have most of the system working. I think that because I put a lizzard trooper in a room, and output the script command it wants to execute in parse(). And all of the execute commands line up(that was a HUGE milestone for me today). I think the last bit of problems I have is understanding actorscrptr, specifically this area isn't working(this is inside of function EGS).



Which eventually causes a crash here:


The same issue is I believe causing some of the remainder of my AI state problems as well.

If anyone has any ideas let me know:
https://github.com/j...all23/DukeSharp

Duke Specific C# bits are here:
https://github.com/j...ssets/Code/Game

I have implemented quite a few changes and fixes to the BuildEngine C# code in this depot since I released the original BuildEngine C# code. The DukeSharp code I first ran through tangible c# converter, but I converted most of that work by hand, and fixed up all 15,000 errors. I'm not using any pointers(it compiles with safe code), the sector annimation code I need to do, Multiplayer I haven't done as well.Anim Movies are not implemented yet. Automap isn't implemented.

[Hudson]

Woah, this is some really impressive work ICD! I know a few folks who will find this news quite up their alley and most welcome

[icecoldduke]

I made quite a bit of progress and fixed quite a lot of bugs, but one huge issue that still hangs over the project is the con script virtual machine. I just created a tool that converts the con scripts to C#. Here's the result(retail con scripts), the tool and source is in the same folder. Next step is I'm going to try and rip out the con script virtual machine and have it call the generated c# code directly.


Generated C# on the left, con code on the right, I think it looks pretty good

Full con code to C# conversion result:
https://github.com/j...ls/conscript.cs

[icecoldduke]

I released a progress video, aside from the automap and multiplayer, its playable just has bugs at this point. Only show stopper at the moment is swinging doors.

[Danukem]

Nice! Looks like you already have gamepad support, too.

[icecoldduke]

I have fixed quite a few things, and I'm able to play through all of E1M1, and proceed to E1M2 without any progression blockers. Doors are fixed, audio is implemented, and lots of other bug fixes are implemented as well.

[Reaper_Man]

[icecoldduke]

I released a build today for Windows, Linux and MacOS. I'm trying to get as much feedback as possible, so try it out and let me know what you think.
This is the first release of IceDuke(formally DukeSharp). IceDuke is a full C# port of original Duke Nukem 3D GPL release. Everything is ported over to C#, including the con code. As a result of the con code being converted to C#, .CON files are not loaded.

DOWNLOAD(Windows, Linux, MacOS)
https://github.com/j...ases/tag/Alpha1

INSTALLATION:
Windows:
Copy duke3d.grp to windows\DukeNukem_Data\StreamingAssets
Linux:
Copy duke3d.grp to linux\linuxtest_Data\StreamingAssets
MacOS
Copy duke3d.grp to mac.app\Contents\Resources\Data\StreamingAssets

KNOWN ISSUES:
The game is fully functional, and there aren't any known progression blockers preventing you from playing from the start of the game to the end of the game, but because this is a complete language port, there will be bugs, and crashes.

1) E1L2 - 30% crash when opening the rotating door from the door, for some reason the code puts the player into a -1 sector and that causes a out of bounds index crash.
2) The hud sometimes has the wrong sector color palette.
3) Save/load is not implemented yet.
4) Automap is not implemented yet.
5) Underwater sector color changes don't work yet.
6) Only works with Duke Nukem 3D 1.5(non of the addons).
7) Command line arguments are not implemented yet.
8) Some animations run very quickly.
9) Holoduke causes a crash.

MODDING:
Since all of the game code(including the con code) is hardcoded, the only way to mod the game currently is to install Unity. This will be fixed in a later release. However modding IceDuke is a lot easier because its all in C#, and debugging is quite a bit easier.

[icecoldduke]

I uploaded a new build with modding support for those that want to check it out:
https://github.com/j.../tag/Alpha1-MOD

Just open up DukeScript.csproj in the mods folder and hit build

[dnskill]

Great job! Duke under C# is cool 😎

[Danukem]

What are the goals as far as being able to make scripted mods with more robust capabilities like in eduke32? So for the included actor scripts only seem to replicate the functionality of the old script system from 1996 (which is pretty impressive!)

[icecoldduke]

 Danukem, on 23 November 2020 - 06:22 PM, said:

What are the goals as far as being able to make scripted mods with more robust capabilities like in eduke32? So for the included actor scripts only seem to replicate the functionality of the old script system from 1996 (which is pretty impressive!)

Getting DukeScript right is more important to me then adding 3d rendering support. I think we should start a open discussion on were to go next with DukeScript.dll. I think the first step is get to a functionality level similar to eduke 2.1 and go from there. What kind of specific things are you guys doing?

[Ninety-Six]

2020 seems to be the year of resurging Duke 3D source ports.

Naturally this is hardly a bad thing.

[Danukem]

 icecoldduke, on 23 November 2020 - 07:29 PM, said:

Getting DukeScript right is more important to me then adding 3d rendering support. I think we should start a open discussion on were to go next with DukeScript.dll. I think the first step is get to a functionality level similar to eduke 2.1 and go from there. What kind of specific things are you guys doing?

There's a lot. But the guiding principle is to expose as much of the game to the scripting system as possible.

To start with, manipulation of the game structs:

https://wiki.eduke32...ructure_members

Any of those members can be read and nearly all of them can be written. That includes the player, all sprites, sectors, walls, input, user settings, and even the "tsprites".

With EDuke32 we also have the ability to draw sprites and text directly to the screen:

https://wiki.eduke32...wiki/Screentext
https://wiki.eduke32.../Rotatesprite16

The custom projectile system is pretty handy:
https://wiki.eduke32...efineprojectile

Actor sprites run code 30 times per second and custom ones can be made to do a lot of work behind the scenes. But that doesn't help in menus or in various other situations. It's also handy to have access points to the game when specific things happen. So in EDuke32 we have "events", and there are a lot of them:

https://wiki.eduke32...wiki/Event_list

A good example of when events are needed as an access point for inserting code is for creating a custom hud display, since that needs to be updated in time with the framerate and can't depend upon an in game actor.

There's definitely some reduncancy in EDuke32 because various events and commands have been added over the years, making many older ones obsolete, but the older ones are kept around for compatibility.

[icecoldduke]

I moved the DisplayWeapon logic over to DukeScript, it should have similar functionality to eduke 2.1 without the nasty syntax, let me know what you think:

https://github.com/j...ipts/weapons.cs

[Danukem]

Even though I have used CON script for many years now I'm still pretty ignorant about the source code and why you would do things a certain way. I'm looking at this just from the point of view of someone who might want to make a project or two using Dukity (or Icedduke...not sure what the name is). Why would you want to start with myospal which lacks key features we currently have rotatesprite?

https://wiki.eduke32.com/wiki/Myospal

EDIT: OK I get it, myospal literally calls rotatesprite in the source code; myospal is essentially a stripped down version handy for displaying weapons. But from my point of view as a scripter I would rather just have access to rotatesprite right away. You would be surprised at how often those additional features come in handy -- like being able to change the rotational angle of the displayed sprite.

[icecoldduke]

 Danukem, on 24 November 2020 - 12:00 PM, said:

Even though I have used CON script for many years now I'm still pretty ignorant about the source code and why you would do things a certain way. I'm looking at this just from the point of view of someone who might want to make a project or two using Dukity (or Icedduke...not sure what the name is). Why would you want to start with myospal which lacks key features we currently have rotatesprite?

https://wiki.eduke32.com/wiki/Myospal

EDIT: OK I get it, myospal literally calls rotatesprite in the source code; myospal is essentially a stripped down version handy for displaying weapons. But from my point of view as a scripter I would rather just have access to rotatesprite right away. You would be surprised at how often those additional features come in handy -- like being able to change the rotational angle of the displayed sprite.

I'll expose rotate sprite as well, myospal is just a utility function that assigns the palette of the sprite to be that of the sector, then calls rotatesprite. It was just a port of the original code moved over to DukeScript, so I didn't change that originally. Any other thoughts? Is the code easier to read then the con script was?

[Danukem]

 icecoldduke, on 24 November 2020 - 12:26 PM, said:

I'll expose rotate sprite as well, myospal is just a utility function that assigns the palette of the sprite to be that of the sector, then calls rotatesprite. It was just a port of the original code moved over to DukeScript, so I didn't change that originally. Any other thoughts? Is the code easier to read then the con script was?

Weapon display was never part of the original CON script when the game shipped, it was all hardcoded. The ability to script weapon display was added much later for eduke. Your script there does look cleaner than what we have currently in EDuke32, mainly because you don't have to declare a bunch of game variables, put the various values into them and then use them as the parameters.

[Reaper_Man]

I've not loaded this up to give it a try, but my question is: Do these DukeScript files have to be compiled before launch, or are they going to be interpreted at runtime the way CON is? Will modders have to compile a DLL or an executable and ship that to users?

 Danukem, on 24 November 2020 - 12:36 PM, said:

mainly because you don't have to declare a bunch of game variables, put the various values into them and then use them as the parameters.

Welcome to how any other programming language works

[Danukem]

 Reaper_Man, on 24 November 2020 - 01:50 PM, said:

Welcome to how any other programming language works

To be fair, in recent years you can refer to structs directly when reading in CON commands, but writing still requires separate set commands.

[icecoldduke]

 Reaper_Man, on 24 November 2020 - 01:50 PM, said:

I've not loaded this up to give it a try, but my question is: Do these DukeScript files have to be compiled before launch, or are they going to be interpreted at runtime the way CON is? Will modders have to compile a DLL or an executable and ship that to users?

DukeScript has to be compiled before launch, but any C# compiler will work fine. You can compile once(Visual Studio, Visual Studio Code, MonoDevelop, etc), and you simply include DukeScript.dll with your mod, and it will work on all platforms, despite the file extension. You don't need to build the executable, I build Unity packages for all platforms, and you simply drop in the new DukeScript.dll, its that easy, and it works with all platforms.

I moved all of the weapon fire code into DukeScript and moved all the weapons to their own source files. New source files for people that want to take a look https://github.com/j...master/Scripts/





Fire and display events are all hooked up for everything except the pipebomb, each source file has fire and display functions that you can modify in DukeScript

[icecoldduke]

I made a quick how to video for modding DukeSharp

https://vimeo.com/483651785

I go over how the package is laid out, editing a episode name, changing the pistol so it fires rockets, and changing the pistol so it fires freezer rounds and every fifth shot it fires missles The latter is to show how global variables in c# can be very powerful went editing dukescript.
I also go over how step through debugging and watching a variable in the debugger in DukeScript

[Danukem]

I am committed to finishing my ongoing projects that I started on EDuke32, which will probably take me another year, but after that I will definitely be interested in making stuff for this.

[icecoldduke]

Alpha 2 release:
https://github.com/j...ases/tag/Alpha2



Fixes:
* Voxel support, included voxels from the NightFright asset pack.
* Fixed a issue with ifcanseetarget returning incorrect results.
* Hitactor move/actor/ai now gets reset on new spawn.
* Fixed a bug were setaspect wasn't called after a new level was spawned.

[icecoldduke]

I published a video of initial 3d rendering support inside my Duke Nukem C# port in Unity. You can now play the game with 3D rendering support in Unity.

[Danukem]

It looked like maybe the player bullets were a little off center, but it's hard to tell with no crosshair.

[icecoldduke]

 Danukem, on 29 November 2020 - 08:34 PM, said:

It looked like maybe the player bullets were a little off center, but it's hard to tell with no crosshair.

I released a new build, with Render3D if your interested in trying it out, it doesn't feel off to me, but let me know what you think.

I've updated render3d since the video above to have sector shading, palette color and visibility bits.

New Features:
1) Render3D
2) Everything now runs on the same thread, dos while loops changed to state machine.
https://github.com/j.../tag/Alpha3-R3D

[stillTodd]

Hey icecoldduke! I don't have a ton of time to help atm, but glad to do some QA. Just point me to something specific if you wish.

(have exp in formal testing/quality assurance, programming starting with C way, way back in the day, sysadmin/troubleshooting, and playing DN3D for far, far too long)

[icecoldduke]

 Vagan, on 30 November 2020 - 06:24 PM, said:

Hey icecoldduke! I don't have a ton of time to help atm, but glad to do some QA. Just point me to something specific if you wish.

(QA, programming, sysadmin, troubleshooting, playing DN3D for far too long...)

Thanks for your support -- If you could simply play the game and let me know of any progression blockers, crashes, etc that would be awesome!

[stillTodd]

Will avoid big/custom maps for now. I'll get cracking on this tomorrow pm starting with something like HH.