Duke Nukem 3D - C# Unity
#1 Posted 16 November 2020 - 05:25 PM
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.
This post has been edited by icecoldduke: 16 November 2020 - 05:38 PM
#2 Posted 16 November 2020 - 08:08 PM
This post has been edited by Hudson: 16 November 2020 - 08:08 PM
#3 Posted 17 November 2020 - 11:41 PM
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
#4 Posted 19 November 2020 - 08:54 PM
#6 Posted 20 November 2020 - 10:23 PM
#8 Posted 22 November 2020 - 08:54 PM
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.
This post has been edited by icecoldduke: 22 November 2020 - 09:07 PM
#9 Posted 23 November 2020 - 05:09 PM
https://github.com/j.../tag/Alpha1-MOD
Just open up DukeScript.csproj in the mods folder and hit build
This post has been edited by icecoldduke: 23 November 2020 - 05:09 PM
#11 Posted 23 November 2020 - 06:22 PM
#12 Posted 23 November 2020 - 07:29 PM
Danukem, on 23 November 2020 - 06:22 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?
#13 Posted 23 November 2020 - 08:00 PM
Naturally this is hardly a bad thing.
#14 Posted 23 November 2020 - 11:28 PM
icecoldduke, on 23 November 2020 - 07:29 PM, said:
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.
#15 Posted 24 November 2020 - 11:53 AM
https://github.com/j...ipts/weapons.cs
#16 Posted 24 November 2020 - 12:00 PM
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.
This post has been edited by Danukem: 24 November 2020 - 12:20 PM
#17 Posted 24 November 2020 - 12:26 PM
Danukem, on 24 November 2020 - 12:00 PM, said:
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?
#18 Posted 24 November 2020 - 12:36 PM
icecoldduke, on 24 November 2020 - 12:26 PM, said:
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.
#19 Posted 24 November 2020 - 01:50 PM
Danukem, on 24 November 2020 - 12:36 PM, said:
Welcome to how any other programming language works
#20 Posted 24 November 2020 - 02:32 PM
Reaper_Man, on 24 November 2020 - 01:50 PM, said:
To be fair, in recent years you can refer to structs directly when reading in CON commands, but writing still requires separate set commands.
#21 Posted 24 November 2020 - 07:43 PM
Reaper_Man, on 24 November 2020 - 01:50 PM, said:
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
This post has been edited by icecoldduke: 24 November 2020 - 07:44 PM
#22 Posted 25 November 2020 - 09:27 AM
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
This post has been edited by icecoldduke: 25 November 2020 - 09:28 AM
#23 Posted 25 November 2020 - 02:13 PM
#24 Posted 25 November 2020 - 06:59 PM
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.
#25 Posted 29 November 2020 - 07:06 PM
#26 Posted 29 November 2020 - 08:34 PM
#27 Posted 30 November 2020 - 06:02 PM
Danukem, on 29 November 2020 - 08:34 PM, said:
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
#28 Posted 30 November 2020 - 06:24 PM
(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)
This post has been edited by Vagan: 30 November 2020 - 06:59 PM
#29 Posted 30 November 2020 - 06:40 PM
Vagan, on 30 November 2020 - 06:24 PM, said:
(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!
#30 Posted 30 November 2020 - 08:16 PM
This post has been edited by Vagan: 30 November 2020 - 08:57 PM