[Kyanos]

evil_presley, on 21 February 2019 - 11:25 AM, said:

i just wish we could use mapster with this.

nightsmoke, on 22 February 2019 - 02:38 AM, said:

Awesome port! Much appreciated!It works just fine with my Blood Texture Pack.
Can we get Mapster32 for this port, pretty please?

daMann, on 22 February 2019 - 04:50 AM, said:

Or even Mapster like 😀

I looked into this. Bloods map format is encrypted does nblood hold the keys?

[Hendricks266]

You're not going to be able to hack together a Blood editor from Duke's.

[Master O]

Photonic, on 28 February 2019 - 05:23 PM, said:

I looked into this. Bloods map format is encrypted does nblood hold the keys?

Have you tried de-crypting it?

[Darkus]

Found a major issue: NBlood crashes randomly when you are in 'drunk' mode, or using the 'jojo' cheat. I got even some cases that when entering drunk mode, the audio stop and NBlood crash some seconds after.

It can also crash when quitting NBlood after the 'drunk' state, for example, enter the 'jojo' cheat, and quit NBlood, sometimes you get an error message.

Apparently, this only affect using the software render, I can't replicate the problem in OpenGL mode.

[Kyanos]

Master O, on 01 March 2019 - 07:26 AM, said:

Have you tried de-crypting it?

No, all I've really done was examine the feasibility of the whole thing. I do think it may be possible to either save from mapster into bloods format (maybe parts only), or at least get a better conversion tool than that dos one that only gets sector geometry, even just adding picnums to a converter would be huge for blood mapping, I don't even play blood though and my motivation on this project is more of a curiosity than any actual desire to make blood maps.

[rhoenie]

NukeYKT, on 12 February 2019 - 09:16 AM, said:

After months of hard working NBlood is finally ready to be released.

Compiles fine on Mac OSX 10.7 when I add -lc++ to the linker. Binary runs fine on my Mac-Mini 2018 under Mojave (and inside the 10.7 virtual machine I am using for the build).
I am having the same issues as with Mapster32, though: can't open the application bundle from within Finder with a mouse click but running it from the command-line is fine.

Thanks! :-)

[Hendricks266]

rhoenie, on 03 March 2019 - 03:01 AM, said:

Compiles fine on Mac OSX 10.7 when I add -lc++ to the linker.

Is that parameter needed or can -stdlib=libc++ be used instead?

[rhoenie]

Hendricks266, on 03 March 2019 - 12:26 PM, said:

Is that parameter needed or can -stdlib=libc++ be used instead?

That parameter is actually needed. It wont compile when I use -stdlib=libc++.

I wasn't using Apples compiler but the MacPorts Clang 4.0.1 that I also use for making the EDuke32 builds and I changed the Common.mak file like this:

Zoidberg:NBlood rhoenie$ diff Common.mak.orig Common.mak
8d7
<
96c95
< PRETTY_OUTPUT := 1
---
> PRETTY_OUTPUT := 0
179,180c178,185
<     CC := $(CROSS)clang$(CROSS_SUFFIX)
<     CXX := $(CROSS)clang++$(CROSS_SUFFIX)
---
>     CC := /opt/local/bin/clang-mp-4.0 -I/opt/local/libexec/llvm-4.0/lib/c++/v1/ -I/opt/local/libexec/llvm-4.0/lib/c++/ -mmacosx-version-min=10.7
>     CXX := /opt/local/bin/clang++-mp-4.0 -I/opt/local/libexec/llvm-4.0/lib/c++/v1/ -I/opt/local/libexec/llvm-4.0/lib/c++/ -mmacosx-version-min=10.7
>
>     COBJC := /opt/local/bin/clang-mp-4.0 -std=c99 -x objective-c -mmacosx-version-min=10.7
>     COBJCXX := /opt/local/bin/clang-mp-4.0 -std=c99 -x objective-c++ -mmacosx-version-min=10.7
> else
>     COBJC := $(CC) -x objective-c
>     COBJCXX := $(CXX) -x objective-c++
183,184d187
< COBJC := $(CC) -x objective-c
< COBJCXX := $(CXX) -x objective-c++
570c573,575
<                 OPTOPT := -march=core2 -mmmx -msse -msse2 -msse3 -mssse3
---
>                 # OPTOPT := -march=core2 -mmmx -msse -msse2 -msse3 -mssse3
> 		OPTOPT := -m64
> 		L_CXXONLYFLAGS += -lc++

The -I/opt/local/libexec/llvm-4.0/lib/c++/v1/ -I/opt/local/libexec/llvm-4.0/lib/c++/ parameters for the C-compiler are needed because a bit further down it will use $(CC) -x c++ to compile C++ code and without them two includes it will run into errors.

The only thing that bugs me right now is the inability to start the game by clicking on the icon within Finder. I even can't debug this behaviour because the debugger runs the binary from the console and this is working fine. As I said it's the same as with Mapster32. Against all logic it must be something inside the code and not in the application bundle (I did a few tests on that one).

[Hendricks266]

rhoenie, on 05 March 2019 - 11:21 PM, said:

That parameter is actually needed. It wont compile when I use -stdlib=libc++.

I wasn't using Apples compiler but the MacPorts Clang 4.0.1 that I also use for making the EDuke32 builds and I changed the Common.mak file like this:

Zoidberg:NBlood rhoenie$ diff Common.mak.orig Common.mak
8d7
<
96c95
< PRETTY_OUTPUT := 1
---
> PRETTY_OUTPUT := 0
179,180c178,185
<     CC := $(CROSS)clang$(CROSS_SUFFIX)
<     CXX := $(CROSS)clang++$(CROSS_SUFFIX)
---
>     CC := /opt/local/bin/clang-mp-4.0 -I/opt/local/libexec/llvm-4.0/lib/c++/v1/ -I/opt/local/libexec/llvm-4.0/lib/c++/ -mmacosx-version-min=10.7
>     CXX := /opt/local/bin/clang++-mp-4.0 -I/opt/local/libexec/llvm-4.0/lib/c++/v1/ -I/opt/local/libexec/llvm-4.0/lib/c++/ -mmacosx-version-min=10.7
>
>     COBJC := /opt/local/bin/clang-mp-4.0 -std=c99 -x objective-c -mmacosx-version-min=10.7
>     COBJCXX := /opt/local/bin/clang-mp-4.0 -std=c99 -x objective-c++ -mmacosx-version-min=10.7
> else
>     COBJC := $(CC) -x objective-c
>     COBJCXX := $(CXX) -x objective-c++
183,184d187
< COBJC := $(CC) -x objective-c
< COBJCXX := $(CXX) -x objective-c++
570c573,575
<                 OPTOPT := -march=core2 -mmmx -msse -msse2 -msse3 -mssse3
---
>                 # OPTOPT := -march=core2 -mmmx -msse -msse2 -msse3 -mssse3
> 		OPTOPT := -m64
> 		L_CXXONLYFLAGS += -lc++

The -I/opt/local/libexec/llvm-4.0/lib/c++/v1/ -I/opt/local/libexec/llvm-4.0/lib/c++/ parameters for the C-compiler are needed because a bit further down it will use $(CC) -x c++ to compile C++ code and without
them two includes it will run into errors.

This patch is butchery so I won't merge it, but you should be able to make a wrapper shell script like this:

#!/bin/sh
make PRETTY_OUTPUT=0 CC="..." CXX="..." ... OPTOPT= L_CXXONLYFLAGS+="-lc++" $*

rhoenie, on 05 March 2019 - 11:21 PM, said:

The only thing that bugs me right now is the inability to start the game by clicking on the icon within Finder. I even can't debug this behaviour because the debugger runs the binary from the console and this is working fine. As I said it's the same as with Mapster32. Against all logic it must be something inside the code and not in the application bundle (I did a few tests on that one).

Does this happen even with the open command from the terminal? If so, maybe running LLDB directly on the .app bundle might allow debugging.

[rhoenie]

Hendricks266, on 06 March 2019 - 09:57 AM, said:

This patch is butchery so I won't merge it, but you should be able to make a wrapper shell script like this:

#!/bin/sh
make PRETTY_OUTPUT=0 CC="..." CXX="..." ... OPTOPT= L_CXXONLYFLAGS+="-lc++" $*

Well, this wasn't meant as a patch - I just wanted to show how I compiled it using Mac-Ports clang 4.0.1.

Hendricks266, on 06 March 2019 - 09:57 AM, said:

Does this happen even with the open command from the terminal? If so, maybe running LLDB directly on the .app bundle might allow debugging.

I tried that method too but I had no success with it.

But I think I found it. When I comment out this section in source/build/src/osd.cpp (around line 1642) ..

if (log.lines < log.cutoff)
{
char *chp2 = Xstrdup(tmpstr);
Bfputs(OSD_StripColors(chp2, tmpstr), osdlog);
Bprintf("%s", chp2);
Bfree(chp2);
}
else if (log.lines == log.cutoff)
{
Bfputs("\nLog file full! Consider increasing \"osdlogcutoff\".\n", osdlog);
log.lines = log.cutoff + 1;
}

.. the application fires up successfully when clicked inside the Finder (it then gives an error, though).

[Hendricks266]

Weird. Maybe it doesn't like the malloc in Xstrdup at some point before it's properly initialized?

[Tekedon]

When are you planning to release the next update for this?

[Nuke.YKT]

Tekedon, on 07 March 2019 - 12:04 PM, said:

When are you planning to release the next update for this?

I dunno. Still have some bugs/features that needed to be fixed/done. Probably it's worth to check out development version(i can send you build via DM if you have no compiler installed).

[Tekedon]

NukeYKT, on 07 March 2019 - 12:25 PM, said:

I dunno. Still have some bugs/features that needed to be fixed/done. Probably it's worth to check out development version(i can send you build via DM if you have no compiler installed).

Okay, that is great! Sure I would love that! But I'm "old/older" and dumb, what is a DM? xD (I have no no compiler no)

[Mr. Death]

NukeYKT, on 07 March 2019 - 12:25 PM, said:

I dunno. Still have some bugs/features that needed to be fixed/done. Probably it's worth to check out development version(i can send you build via DM if you have no compiler installed).

Will the next release possibly have a 32bit version? I'm eager to try out this port!

I would also like to get in on this developer build (if it's 32bit).

[Forge]

NukeYKT, on 07 March 2019 - 12:25 PM, said:

have no compiler installed

what's a good, free one, for windows 10 (x64)?

[Hendricks266]

Take your pick.

[TerminX]

If you don't have experience working with Linux-like systems, Visual Studio would probably be your best bet.

[geomancien]

Powerslave?

[Master O]

geomancien, on 09 March 2019 - 04:37 PM, said:

Powerslave?

One of Iron Maiden's greatest albums.

[thelastdisciple]

I know it's not entirely necessary for this but is it possible to launch from Steam via the purchased game files? if so, how would i go about doing that? For some other ports you can usually trick Steam by renaming files and what not. I am just unsure what files i might be able to backup and rename etc. or if it will even work this way.

[Phredreeke]

You could drop NBlood in the same folder and add as a non-Steam game.

[Saucerful]

Wow, great work. This port looks very promising. Performance is fantastic and NBlood is perfectly playable with vsync enabled whereas BloodGDX just isn't... and vsync is a must for me. My only comment, and others have noted this as well, is the mouse look seems off. I have to crank my sensitivity up to 2400 dpi (hardware), adjust the slider almost all the way up in the software, and even then it feels like there's some filtering or something going on which I don't experience in any other game. Sorry I can't be more descriptive than that... any idea what's going on there?

[Tekedon]

Saucerful, on 16 March 2019 - 11:58 AM, said:

Wow, great work. This port looks very promising. Performance is fantastic and NBlood is perfectly playable with vsync enabled whereas BloodGDX just isn't... and vsync is a must for me. My only comment, and others have noted this as well, is the mouse look seems off. I have to crank my sensitivity up to 2400 dpi (hardware), adjust the slider almost all the way up in the software, and even then it feels like there's some filtering or something going on which I don't experience in any other game. Sorry I can't be more descriptive than that... any idea what's going on there?

And please add some easy way to choose usermaps and addons from within the game

[thelastdisciple]

thelastdisciple, on 14 March 2019 - 03:37 PM, said:

I know it's not entirely necessary for this but is it possible to launch from Steam via the purchased game files? if so, how would i go about doing that? For some other ports you can usually trick Steam by renaming files and what not. I am just unsure what files i might be able to backup and rename etc. or if it will even work this way.

Found a solution on the Steam forums for Blood, was recommended to use SteamEdit program. Very handy!

[Saucerful]

I think I've found an issue. Anisotropy is ignored when texture mode is set to "classic". I don't believe this is desired behaviour... most other source ports I've played (Blood and other games) allow this combination. Probably there is some implicit linear mipmapping or something going on when anisotropy is enabled in those other ports, but either way it would be nice if we could have nearest-neighbor texture mode without the shimmering.

[TerminX]

Saucerful, on 27 March 2019 - 07:48 PM, said:

I think I've found an issue. Anisotropy is ignored when texture mode is set to "classic". I don't believe this is desired behaviour... most other source ports I've played (Blood and other games) allow this combination. Probably there is some implicit linear mipmapping or something going on when anisotropy is enabled in those other ports, but either way it would be nice if we could have nearest-neighbor texture mode without the shimmering.

It's a bit more complicated than that. Filtering needs to be entirely re-implemented in a shader to be functional here, which itself will require a bit more backend work. The combination "works" in other ports because the other ports don't support true paletted textures being rendered with actual palette effects like they did in the old days, just wasteful load-time conversion to RGB before/during texture upload, which still doesn't allow the result to be shaded the same as the classic renderer.

On the other hand, even though our method requires all texturing be done in the shader itself, it has the major advantage of allowing the OpenGL renderer to achieve nearly 100% accuracy to the original game as far as color reproduction and shading goes.

[enderandrew]

NBlood has been ported to the Nintendo Switch.

https://gbatemp.net/...-switch.534587/

[NightFright]

Tekedon, on 16 March 2019 - 12:34 PM, said:

And please add some easy way to choose usermaps and addons from within the game

Ideally the same way BloodGDX did. It really can't be easier. It's a big advantage of that port, and there are quite a few amazing Blood addons out there that justify investing time into making it work as smoothly as possible. Ideally, I wished my existing addon folder I made for BloodGDX would work in NBlood without any adjustments.

[Saucerful]

TerminX, on 27 March 2019 - 08:21 PM, said:

It's a bit more complicated than that. Filtering needs to be entirely re-implemented in a shader to be functional here, which itself will require a bit more backend work. The combination "works" in other ports because the other ports don't support true paletted textures being rendered with actual palette effects like they did in the old days, just wasteful load-time conversion to RGB before/during texture upload, which still doesn't allow the result to be shaded the same as the classic renderer.

On the other hand, even though our method requires all texturing be done in the shader itself, it has the major advantage of allowing the OpenGL renderer to achieve nearly 100% accuracy to the original game as far as color reproduction and shading goes.

Interesting, thanks for the explanation. I'm obviously no expert on OpenGL rendering so I had never considered that. Upon a cursory glance at both NBlood and BloodGDX, the colours do look better in NBlood.

Another question then: instead of allowing anisotropy in "classic" mode, is it possible in "filtered" mode to have the option of using nearest-neighbor for the non-mipmapped textures? Or would that just present the exact same problem you already described?