[MetHy]

I've never ever played Strife. Though I've been thinking of it for a while.

[t800]

MetHy, on 10 April 2016 - 10:56 AM, said:

I've never ever played Strife. Though I've been thinking of it for a while.

Was just asking because its source code was never released and its already lost. So all ports base their functionality of reverse engineering of SvStrife. But this became such a staple, that even purist Chocolate Doom and official release Strife: Veteran Edition utilize it.

[Daedolon]

Strife makes sense on the DOOM engine, like Blood would make sense on the BUILD engine, NOT on the DOOM engine.

[t800]

Daedolon, on 10 April 2016 - 11:02 AM, said:

Strife makes sense on the DOOM engine, like Blood would make sense on the BUILD engine, NOT on the DOOM engine.

This was meant as example of principle, not literaly. Of how sometimes even reverse engineering becomes "officially" recognized part of source port community.

[leilei]

Unsurprisingly there's a teenager doing an "ultimate accurate zblood" with "alpha maps and resources" right now. It's as good as it sounds (read: isn't). Also unsurprisingly, this exists. No comment

Shame about the missed opportunity to call this thread "Blood Coroner"

I still blame all those "abandonware" sites inundating Blood since 2002. I seriously stopped playing it in 1998 and never had an obsession for it.

[deuxsonic]

I like how literally every game gets at least 1 mod for doom.

[leilei]

It's generally a kid prospect with blind understandings of engine features and limitations as well as high/total ignorance for intellectual property law. Something-Life, something: Source, something Portable, Zsomething, etc.

[Psycho87]

Some time ago I tested an idea I had: a modified version of DosBox I call BloodBox that, after loading blood.exe, injects calls to a special interrupt at the start of Blood functions that I reverse engineered. These functions were then ported to C and implemented in BloodBox itself. I was actually able to replace some rendering code, and play around with it by making modifications. The benefit of this approach is that instead of the entire game, only the code useful for bug fixing, modding and adding features has to be reverse engineered.
Obviously this is still a lot of work, and I don't have the time to do it, but maybe this is an approach someone else is willing to consider?

[MrFlibble]

That sounds like an interesting approach, what have you been able to achieve so far, and what is planned?

[Micky C]

Even if only a few of the bigger bugs like the savegame bug could be fixed, that'd be a bit improvement.

[icecoldduke]

Psycho87, on 12 April 2016 - 05:50 AM, said:

Some time ago I tested an idea I had: a modified version of DosBox I call BloodBox that, after loading blood.exe, injects calls to a special interrupt at the start of Blood functions that I reverse engineered. These functions were then ported to C and implemented in BloodBox itself. I was actually able to replace some rendering code, and play around with it by making modifications. The benefit of this approach is that instead of the entire game, only the code useful for bug fixing, modding and adding features has to be reverse engineered.
Obviously this is still a lot of work, and I don't have the time to do it, but maybe this is an approach someone else is willing to consider?

That's not a bad idea.

[MrFlibble]

BTW, can anyone explain why Blood's performance in DOSBox in high-res modes is apparently much less robust compared to other Build games? A quick Google search turned up this thread at VOGONS, but it basically says that any raycasting engine is bound to slow DOSBox down at high resoutions:

Quote

Blood is built on a raycaster engine. Raycasters do not run at high resolutions very well (and by that, I mean actively setting the rendering options in a BUILD engine game like Blood/Duke3d/Redneck Rampge to 1024x768 or higher will result in the game running slower). Running a raycaster game at 320x240 game resolution (but hitting Alt + Enter on dosbox to stretch it up to fullscreen) will not make it run any slower, it's only if the actual rendering engine has to cast more rays that will slow it down.

However, I distinctly remember running Duke Nukem 3D and Shadow Warrior at 640x480 (or maybe even 800x600) in SVN Daum (fullresolution=desktop, output=direct3d) at a quite acceptable, if not optimal, speed on a rather old machine with just 256 MiB RAM and 32 MiB VRAM. I had not tested Blood back then though.

Which brings me to the question: is it possible, at least theoretically, to write a modified version of DOSBox that would be optimized to run Build engine games at high resolutions?

[Daedolon]

I always only play at 640x400 to retain the original pixel aspect ratio (plus it's also the highest mode that doesn't come with 3D mode selection issues on MAPEDIT, since MAPEDIT also reads BLOOD.CFG for its resolution). Doesn't require too much computing power and looks smooth as hell.

[MetHy]

How would you guys rank Blood mapping? Easier or harder to learn than Shadow Warrior ? How's the version of Build coming with it? Because while I can use EDuke32 for some stuff in SW, that can't work for Blood.

MrFlibble, on 13 April 2016 - 07:47 AM, said:

Which brings me to the question: is it possible, at least theoretically, to write a modified version of DOSBox that would be optimized to run Build engine games at high resolutions?

Apparently this does wonders for some people

https://www.gog.com/..._you_know/page1

Didn't change anything for me though. Not that I'd need it because I can play it smoothly in 800*600 anyway, and between that and above hardly makes a difference as far as Build games are concerned.

Also manually setting your CPU cycles (rather than "max=auto") will help. Set it too high though and intro/ending videos may have stuttering sound.

[deuxsonic]

Is there a way to just run it at 640x480 and scale that up to the monitor's native res?

[MrFlibble]

MetHy, on 13 April 2016 - 10:34 AM, said:

Apparently this does wonders for some people

https://www.gog.com/..._you_know/page1

Didn't change anything for me though. Not that I'd need it because I can play it smoothly in 800*600 anyway, and between that and above hardly makes a difference as far as Build games are concerned.

The problem with the existing DOSBox builds is that they all aim to properly support as many games as possible. This is, presumably, less effective that targeting specific titles. I've used vanilla 0.72 and SVN Daum 0.71 for a very long time on that old PC, but switching to SVN Daum 0.74 (some build or other from 2011 IIRC) made an impression that it worked slower. Also it seems to me that, on that same old configuration, Thor's Hammer (a game known to have a choppy framerate in DOSBox) ran significantly faster in vanilla 0.72 and SVN Daum 0.71 than in vanilla 0.74. I suspect something in the new version might have degraded compatibility with this particular game.

By which I mean that DOSBox, being open source, may indeed present certain opportunities to make it possible to run individual DOS games such as Build engine titles optimally, but I'd like to know for sure from people with experience in coding and emulation.

[Daedolon]

MetHy, on 13 April 2016 - 10:34 AM, said:

How would you guys rank Blood mapping? Easier or harder to learn than Shadow Warrior ? How's the version of Build coming with it? Because while I can use EDuke32 for some stuff in SW, that can't work for Blood.

Having 5 stub maps in Blood that I later plan to turn into a full campaign and single stub map in SW, I found the trigger system and editing much easier in Blood, so as long as you have a short checklist next to you when you're getting started. The amount of options might put some people off for mapping for Blood, but in reality the options are there, but they don't really take away from the more simple stuff.

Blood has most of its effects labeled similar to Duke's SEs, so you can't really use that as an excuse not to try out Blood mapping, either. It's just a different beast with more options, but the basics, after you get used to them, are quite simple.

[Hendricks266]

BUILD is not a raycaster. Goddamnit.

[deuxsonic]

Does ROTT use raycasting? It uses a modified Wolf3D engine and that was raycasting but it also has some render code that John Carmack gave to them that was used in DOOM which is not raycasting and lots of other changes but still the orthogonal wall limitation.

[Duke of Hazzard]

MrFlibble, on 13 April 2016 - 10:50 AM, said:

By which I mean that DOSBox, being open source, may indeed present certain opportunities to make it possible to run individual DOS games such as Build engine titles optimally, but I'd like to know for sure from people with experience in coding and emulation.

Nintendo does that in the VC.

I think it's perfectly possible, but I'm a layman, only judging from what I've seen in the market.

[MrFlibble]

Hendricks266, on 13 April 2016 - 03:47 PM, said:

BUILD is not a raycaster. Goddamnit.

I'm sorry for unwittingly reproducing incorrect information.

Can you tell if it is possible to optimize DOSBox specifically to run Build engine games? I know that Shadow Warrior shareware v1.0 and v1.1 are, or at least have been for a long time, completely unsupported by vanilla DOSBox (but playable in third-party builds like SVN Daum). Does this mean there are programme specifics that need to addressed by DOSBox emulation?

[supergoofy]

DOSBox SVN Daum is outdated and has bugs. Instead use the latest DOSBox-X, which is based on DOSBox SVN Daum, but it has many fixes and improvements since last DOSBox SVN Daum release.

DOSBox-X source
https://github.com/j...ell123/dosbox-x

Compiled binaries by EmuCR.com
http://www.emucr.com...&max-results=12

[icecoldduke]

Hendricks266, on 13 April 2016 - 03:47 PM, said:

BUILD is not a raycaster. Goddamnit.

I can't see that misconception going away anytime soon. For those that want to read a good article on how the build renderer works: http://fabiensanglar...e_internals.php I would suggest MrFlibble if you are planning to do dosbox optimization work for Blood VGA, I would suggest reading the article if you haven't already.

[MrFlibble]

supergoofy, on 14 April 2016 - 04:36 AM, said:

DOSBox SVN Daum is outdated and has bugs. Instead use the latest DOSBox-X, which is based on DOSBox SVN Daum, but it has many fixes and improvements since last DOSBox SVN Daum release.

DOSBox-X source
https://github.com/j...ell123/dosbox-x

Compiled binaries by EmuCR.com
http://www.emucr.com...&max-results=12

I didn't realise that DOSBox-X is being updated. I have an old build from somewhere around 2010. Does it yield better performance results than SVN Daum?

[Lunick]

My performance in Blood actually went down when using DOSBox-X rather than Daum

[Hendricks266]

MrFlibble, on 14 April 2016 - 04:24 AM, said:

Can you tell if it is possible to optimize DOSBox specifically to run Build engine games?

I don't know any specifics that would let me answer this one way or the other.

MrFlibble, on 14 April 2016 - 04:24 AM, said:

I know that Shadow Warrior shareware v1.0 and v1.1 are, or at least have been for a long time, completely unsupported by vanilla DOSBox (but playable in third-party builds like SVN Daum). Does this mean there are programme specifics that need to addressed by DOSBox emulation?

------------------------------------------------------------------------
r3868 | ripsaw8080 | 2014-06-19 13:51:42 -0500 (Thu, 19 Jun 2014) | 1 line

Illegal memory reads have all bits set. Fixes early (and buggy) shareware versions of Shadow Warrior.
------------------------------------------------------------------------

[MrFlibble]

Lunick, on 14 April 2016 - 05:15 AM, said:

My performance in Blood actually went down when using DOSBox-X rather than Daum

That's what I'm talking about. It seems that while the majority of DOS games run well with almost any build, there are certain cases that somehow have issues, and performance may vary unpredictably between builds. I'm not even sure how each individual host machine factors into this (save for computing power, obviously).

icecoldduke, on 14 April 2016 - 04:41 AM, said:

MrFlibble if you are planning to do dosbox optimization work for Blood VGA

Just to avoid any misunderstandings, I don't even remotely have the skills necessary to do something like that. I'm asking questions simply because this kind of project seems like a good idea to me, and perhaps could result in a viable solution in the absence of source ports of the game.

[icecoldduke]

MrFlibble, on 14 April 2016 - 06:33 AM, said:

Just to avoid any misunderstandings, I don't even remotely have the skills necessary to do something like that. I'm asking questions simply because this kind of project seems like a good idea to me, and perhaps could result in a viable solution in the absence of source ports of the game.

Unless you are willing to do it yourself it won't get done .

[supergoofy]

Lunick, on 14 April 2016 - 05:15 AM, said:

My performance in Blood actually went down when using DOSBox-X rather than Daum

I assume you tested the x86 binary, but which binary have you tested? from 2016.04.11 ?

Which output method did you use ? for me opengl is the one that works faster.


Note: I don't know if the x64 binary has dynarec

[MetHy]

deuxsonic, on 09 April 2016 - 11:44 PM, said:

Every port Kaiser has worked on has been excellent. I bet you if he was interested in the game, of anyone he could do it. Since he does some ports for Night Dive, perhaps if Night Dive became interested in it they could make it happen. I bought Strife: Veteran Edition after all...

I have a hard time viewing the Saturn version of Duke3D as a "port" because it is genuinely not the same game. It's a different engine and the whole game had to be remade and the end result only vaguely resembles the game it is purported to be. Same thing for the Saturn version of Quake where sprites were used in places where meshes were in the real Quake. They share music and textures, some raw materials, but the maps and practically everything else had to be redone. That's more remake than port. I think Slavedriver was an actual 3D engine, thinking of some of the map layouts for the console versions of Powerslave.

Hendricks266, on 10 April 2016 - 07:29 AM, said:

It's funny that you don't call Saturn Duke a port for those reasons, but don't realize that most of them apply to Kaiser's projects too. He reverse-engineers the file formats but then reprograms the rest of the game, including enemy behavior, from scratch.

I actually stumbled on Kaiser on a forum and asked him about that

Quote

Haven't nailed all the scaling for the sprites yet (the X/Y scale seems to be hardcoded per AI sprite). That screenshot I posted earlier was from an older version, which didn't have colormap variants implemented.

This one is slightly more up to date.

His screenshot :


and mine from Blood for comparison sake, though of course his stuff is WIP.

Quote

The way I handle it is anything regarding to damage values, health, etc is reverse engineered, because that's the most important things that needs to be done right.

Anything regarding to player weapon swaying and object momentum speeds (such as how far you throw dynamite, or how much an explosion knocks you back) is entirely empirical, though I do rely on the assembly as a guide.

AI behavior is 100% identical and taken directly from the disassembly. Though I do add a bit more to it so it can be easily customized by modders. The only thing I am concerned about is how the enemy aims at the player. Build engine games uses a fixed-point slope value while Kex uses atan2/angle pitch to determine the aim.... which results in the AI being a tad more accurate even while the player crouching. I have some ideas to emulate the fixed point slope behavior though.

Everything else (renderer, collision, resource management, etc) is done from scratch.

Surprisingly enough, the 'cansee' function from Build is actually bugged and explains why some explosions do no damage to objects, even when its right next to it. Since Kex has its own way of handling this, explosions will now be guaranteed to damage whatever that is within its blast radius.

I don't intend on alienating BloodCM (a favorite of mine btw) or BloodXL. I am just simply offering another way to enjoy Blood without needing DosBox. In fact my original intention was to show off a more GPL-friendly engine that can run a Build game. I choosed Blood because it's actually the most organized of the Build games (3D Realms' code looks like fucking chicken scratch).

However, its simply up to the user's preference. BloodEX will have the capabilities to support Blood mods though.

So yeah, basically anything regarding hitscan and projectile is redone from scratch either by looking at the code he's dig up or by "empirical" feeling.
I honestly don't believe you can nail Blood that way. You may get something that looks like it with a lot of work.

There are more screenshots if anyone cares.