NASTY: Not A Sourceport, Thank You (Alpha 4)

Alpha 3 release!

You can now take screenshots with the P button (button configs are on the list eventuallyyyyy), and also load multiple texture definitions!

Get it here:

https://github.com/jmickle66666666/DoomUnity/releases/tag/v0.1-alpha.3

As always, if you have any issues or feature suggestions, please post them in this thread or on the issues page on github! https://github.com/jmickle66666666/DoomUnity/issues

If you have anything in particular you'd like me to focus on feel free to suggest too :)

On 5/8/2018 at 1:21 PM, jmickle66666666 said:

If you have anything in particular you'd like me to focus on feel free to suggest too :)

Maybe, but it would help if I knew what your long term plans are. For example, is your engine just for rendering, or do you plan to add Doom, or some other type of gameplay? And, were you thinking of adding Doom monster animations, or perhaps something different?

That's a big thing to focus on. You've got some good rendering going on there. If it were me, I think I'd try to add objects...at least the ability to render their first standing frame, with rotations. Later, if you want, you could add collision detection via BLOCKMAP, or something else, and use it to let the monsters walk around.

Good luck - this is a very cool project!

If you load it up you can see the monsters and items are already there. I'm loading the state tables from multigen.txt, but it doesn't read anything more than the standing sprite name yet. My current focus is on pk3 and UDMF support, then I'll be getting to more state behaviour

Back in business with this stuff. Today i've gotten PK3 archives, PNG textures and UDMF maps loading. No UDMF/zdoom features are supported as of yet, and there are still a bunch of problems but for the most part it is possible to run around udmf levels now. 

I have also taken a stab at monster behaviour, and now sprite rotations work correctly, and state animations too: 

Here you can see monsters facing the correct direction, and playing through the spawn state frames. They can switch to other states and animations play correctly. I just need to code the actions next, which is a lot of busywork.

Hopefully I'll have a wonderful new build soon when I have this stuff cleaned up!

1 hour ago, jmickle66666666 said:

Back in business with this stuff. Today i've gotten PK3 archives, PNG textures and UDMF maps loading. No UDMF/zdoom features are supported as of yet, and there are still a bunch of problems but for the most part it is possible to run around udmf levels now. 

 

I have also taken a stab at monster behaviour, and now sprite rotations work correctly, and state animations too: 

Here you can see monsters facing the correct direction, and playing through the spawn state frames. They can switch to other states and animations play correctly. I just need to code the actions next, which is a lot of busywork.

 

Hopefully I'll have a wonderful new build soon when I have this stuff cleaned up!

Ooh - nice, you do quick work. Didn't know you had the monsters...and now you've got them doing the two-step. Collision detection will probably be harder than the actions. The id Software way has a lot going for it, but it's a bit complex. Anyway, good luck!

collision detection is already done

Wow, very cool. I'm going to have to keep up with your work better, obviously.

More suggestions (that you probably already have done...) How's your menu, HUD/status bar, music, and sound effects?

Here's something fun: How about a command-line option to feed it a WAD, and have it spit out overhead screenshots of all levels. Maybe the user specifies camera height and angle, and desired bitmap size. That could be used to make HTML pages with images of a WAD's maps. There must be some tools out there that do this...I got the idea from your early screenshots.

You know what to do, anyway, right? :)

Music has been a really tricky one, turns out its not so easy to get midis playing properly in Unity 😛 I rewrote mus2midi.cpp for the third time (previously having done so for javascript and python) in C# and it appears to be working fine, but there is an issue with the midi library I'm using still. I'm not sure I'm capable of fixing it. (It's playing *some* drums on piano instrument.)

Sound effects are working fine.

Statusbar I have begun work on but have put on hold for more exciting work. In terms of HUD I have a console and messages. The console is a bit janky but does allow users to change settings in game, like mouse sensitivity.

Command line to spit images out might be fun! I think thats gonna be a low priority feature though since the camera angle stuff wouldn't be particularly useful I think. Manually taking shots is more convenient, and it's currently very slow at loading levels, so screenshotting an entire wad would take forever.

I should point out that a lot of this stuff is done so quickly because I'm using Unity. Deciding to build with an existing game engine instead of my own from scratch is the only reason this project has gotten to where it is.

Unity might be nice, and all, but bringing all the components of a complex game like Doom together takes pure skill. Don't cut yourself short.

On the screenshot camera angle: I'd try to automate it, maybe like this:

Find the longest map dimension of the compass: like North/South, Northeast/Southwest, East/West, or Southeast/Northwest. Then choose which of the 2 has the lowest walls. Let's say the longest direction is East/West, and the East side has lower walls than the West side. Take the most East point, and move a fixed distance further East, and further upward a fixed height. This is your camera X Y Z. That lets you see across the whole map with least chance of obstruction. Then, calculate a triangle across that length, so you're looking, say, 3/4 across the map. That gives you the pan up/down angle.

I'm curious: Why does it take a long time to load the map? Does Unity have to do a bunch of conversions for rendering?

No, it's just my code. I did some profiling and optimisations today and the bulk of the time building a level is spent triangulating sectors into convex shapes to build a mesh from. It is by far the most complex part of nasty, and the least fun to work on, so the code is very messy and very unoptimised. Some deeper profiling showed that the worst culprit in the triangulation is this function here. It's all in C#, just like Doombuilder, so anotak very kindly took some time to take a look through to try and see if there were any easy gains to be made. The conclusion is basically root problems with my approach with a lot of it, but its not code I fully understand anyway (I'm honestly surprised I got it working to the level it has), so changing the way things work is very difficult.

There are optimisations to be made all over, but triangulation is the first part to fix, as it is taking up a huge portion of the time. For reference (though take these numbers with a grain of salt, they're running on my kinda underpowered machine, in-editor (lots of overhead)): BTSX MAP06 takes around ~8.5 seconds to build the geometry for, 4.5 of which are spent in that one function alone. This doesn't include the actual geometry being built, building the textures and sprites, or anything else; each of which also haven't been optimised. 

This is entirely a solvable issue, too, since Doombuilder triangulates these maps in under a second, also in pure C#. I am either going to tear out and replace it with a new method (for instance the method GLBSP uses), or rewrite a similar approach from scratch, using the knowledge I've gained working on it. It's just not particularly high on my priority list since it's so difficult, and there are many other things to work on before Nasty is a usable engine.

Alpha 4!

Downloaf: https://github.com/jmickle66666666/DoomUnity/releases/tag/v0.1-alpha.4

* Entity states

* Entity sounds

* Item pickups

Wonky stuff:

* Pk3 support

* Preliminary UDMF support

* PNG texture/flat support (warning: very buggy!)

(edit: turns out that build was broken! updated with fixed version)

Looking good! Yeah, I saw the triple loops in there. The fact that you have it working is what's important. Things can always be optimized later.

i made a huge optimisation to the in-game speed the other day, but realise to implement sector height changes (for doors, lifts etc), i am going to have to replace a lot of the mesh generation code, nullifying the optimisation. I think its still possible to use the same optimisations though, I just need to do some tests to make sure. Lots of stuff has been getting rewritten recently.