[SwissCm]

Blood is an excellent game, some would say that it's the best game to use the Build engine (like me), but we don't have the source available and it's unlikely that we ever will. This sucks, however it doesn't mean we can't get a reasonably accurate port of it. There are countless Blood TC/mod projects out there in varying stages of completion, none of which ever seem to pick up enough steam to get off the ground. I think the primary reason for this is that there are so many ports the community fragments. So I give a rather obvious solution:

No original content, no duplication of effort, just a single TC which aims to recreate Blood as accurately as possible using eDuke32.

A large amount of Blood reverse engineering has already been done but the majority of this information isn't openly available. Perhaps a wiki that contains detailed technical information may help there. It would be a start at least.

There are some implementation issues that are still up for debate. I thought I may address them so they can be discussed.

Fork eDuke32 or TC?
Forking would be a bad idea. eDuke32 has almost everything that is needed feature-wise and it's well understood by the community. Forking it would make it difficult for the projects to share with each other. If there are features that are needed at the source code level, it be best to implement them generically.

Map Format?
An old abandoned project called ReBUILD reverse engineered the Advanced Build map format that Blood uses and created a converter to vanilla Build. This is still only halfway there, ideally it would convert all the Blood special types to it's eDuke32 equivalents. Rebuilding everything from scratch is a waste of time and prevents the use of usermaps. If someone is willing to implement an on-the-fly converter into eduke32 that would be ideal.

Data Files?
Monolith doesn't seem to care about people distributing Blood game data.

I wanna make a new episode and add new enemies and weapons and stuff!
This is a waste of time. The primary aim of the project should be to emulate Blood as accurately as possible.

3D Acceleration?
If it works well with Polymost/Polymer all the better, but even then I think the 8bit renderer should be the target. Basically, if you're running the game at 320x200 it should be nigh-indistinguishable with the original.

Closed or open?
Open. Best if anyone with any knowledge or skill is able to contribute.

I'm sure there are enough people out there to make this happen!

EDIT: Apparently Matt Saettler (one of Blood's programmers) is willing to answer questions about certain aspects of how Blood works. If there is anything that is too difficult to find out through reverse-engineering then he is a useful source of information.

[m210®]

At first, we need a ROR, which doesn't works correctly at eDuke32

[SwissCm]

M210, on Apr 9 2010, 03:51 PM, said:

At first, we need a ROR, which doesn't works correctly at eDuke32

What is the issue currently? Collision/transfer between sectors and other non-rendering related stuff can still be worked on.

[Spiker]

Ambitious project (Like every Blood project), so how do you guarantee that it's going be more successful? Definately you're not going to do this alone, are you? I don't want to see another Blood TC lurking in shadows for years and probably slowly dying. Anyway Blood is also my favorite build game so I wish you good luck

[SwissCm]

Spiker, on Apr 9 2010, 04:29 PM, said:

Ambitious project (Like every Blood project), so how do you guarantee that it's going be more successful? Definately you're not going to do this alone, are you? I don't want to see another Blood TC lurking in shadows for years and probably slowly dying. Anyway Blood is also my favorite build game so I wish you good luck

The idea is for the project to be completely open, almost all the other projects have been closed. I'd like for the developers of the other Blood TCs to help out or at least provide as much information as they can.

[Spiker]

I'm afraid that with an exception of M210 all Blood developers are quite mean in terms of sharing their work. They have "If I can't recreate Blood then noone will" kind of personality.

[Stabs]

well i can see scripting being useful in this situation to do all the textures, one script could save ALOT of work

then there is the issues of using all the original ART which iam not sure could be used, otherwise they would have to "HRP'ed"

[Jinroh]

Spiker, on Apr 9 2010, 03:42 PM, said:

I'm afraid that with an exception of M210 all Blood developers are quite mean in terms of sharing their work. They have "If I can't recreate Blood then noone will" kind of personality.

Yeah the Blood community has had some nasties lately just look at the Hypertension crew and the debacle they caused. >_>

Anyway, I think a proper Blood TC for EDuke32 that gets finished will be cool. There just hasn't been a good track record. You could do without RoR for a while just look at the ZBlood TC for ZDoom, it does quite a lot with ZDoom which doesn't support RoR.

[Headless_Horseman]

I wish you good luck, SwissCm, and I second the Jinroh idea : just develop something that could work decently without ROR.

[m210®]

SwissCm, on Apr 9 2010, 09:10 AM, said:

What is the issue currently?

I am afraid that I can't explain a problem in English, therefore I will shortly make a video about ROR problem.

[m210®]

And look at this:
http://www.youtube.c...h?v=6VLAOdWt578
this is my ROR via con codes. eDuke32 also have that problems as at video

[Mblackwell]

How are you calculating the viewpoint?

[Forge]

Have you looked at that old jonof port winblood project that was abandoned?

winblood alpha 2 with polymost

Never tried cDuke so I have no idea if it performs the ROR that it claims

cDuke

RTCM has some tools and faqs

RTCM

I'm sure you know about all this, but I figured I'd try to toss out some resource links anyway.

[Jinroh]

Forge, on Apr 11 2010, 11:39 AM, said:

Have you looked at that old jonof port winblood project that was abandoned?

winblood alpha 2 with polymost

Even with following the instruction I could not ever get that to work. >_>

[m210®]

Mblackwell, on Apr 11 2010, 05:03 AM, said:

How are you calculating the viewpoint?

I'am used EVENT_ANIMATESPRITE and when the ROR sprite is drawn on the screen, it becomes invisible. I'am used "sizeat 1 0" for this

[m210®]

I made a video with bugs of eDuke32 ROR. It's drawn when player is in a ROR sector only and not drawing when player is near ROR sectors
http://www.youtube.c...h?v=gUc87y3yylU

[Mblackwell]

M210, on Apr 11 2010, 01:35 AM, said:

I'am used EVENT_ANIMATESPRITE and when the ROR sprite is drawn on the screen, it becomes invisible. I'am used "sizeat 1 0" for this

Erm, no I meant literally how are you calculating the viewpoint? What's your math?

[TerminX]

I don't think the ROR in the map is set up right if you're getting null areas in the drawing like that. Take note of the offset the ROR effectors have from the floor and ceilings in the example map.

[m210®]

Mblackwell, on Apr 11 2010, 04:25 PM, said:

Erm, no I meant literally how are you calculating the viewpoint? What's your math?

oh, I'm understand now.
Look for this code:

// Set Player camera variables
	setvarvar x camerax
	setvarvar y cameray
	setvarvar z cameraz
	setvarvar h camerahoriz
	setvarvar a cameraang	
	
//get a coordinates of first ROR actor (Upper level)
		
	getactor[IDSaved2].x x2
	getactor[IDSaved2].y y2
	getactor[IDSaved2].z z2
	getactor[IDSaved2].sectnum sectnum1  

//get a coodrinates of drawn ROR actor (Downer level)
					
	getactor[IDSaved].x x3
	getactor[IDSaved].y y3
	getactor[IDSaved].z z3
							  
	subvarvar x2 x3
	subvarvar y2 y3
	subvarvar z2 z3

//the difference of coordinates added to coordinates of the player [cameracoord]

	addvarvar x x2
	addvarvar y y2
	addvarvar z z2
	addvar z 3072

			  showview x y z a h sectnum1 0 0 319 199

[m210®]

TX, on Apr 11 2010, 07:11 PM, said:

I don't think the ROR in the map is set up right if you're getting null areas in the drawing like that. Take note of the offset the ROR effectors have from the floor and ceilings in the example map.

I will try to make video with bugs on a example map ror.map (water.map)

[m210®]

http://www.youtube.c...h?v=QHxNTboVdj8
Some bugs. Well, how to fix it?

[Sebastian]

No offence, but this whole project just seems like a waste of time when all that effort can be spent on creating something fresh and new for everyone. Unless I'm missing something and nobody is able to play the original Blood anymore?

[Danukem]

Rusty Nails, on Apr 11 2010, 11:31 AM, said:

No offence, but this whole project just seems like a waste of time when all that effort can be spent on creating something fresh and new for everyone. Unless I'm missing something and nobody is able to play the original Blood anymore?

The source code for Blood was never released, so the only way we can play it is through DOSBox. It works, but, the mouse aiming in Blood is crap imo and I would much rather play it on EDuke32. Also, once we have it on EDuke32, it can be modded.

[Sebastian]

Alright, fair enough I suppose.

[Forge]

Jinroh, on Apr 10 2010, 10:11 PM, said:

Even with following the instruction I could not ever get that to work. >_>

I put that up so it could be looked at, anything worth keeping can be used, toss out the rest. Possibly better than starting from scratch.

[Simon_Croes]

I think M210 is doing a great job porting Blood through eDuke32

[Gambini]

I like this idea. Unfortunately there are some huge setbacks on the begining such as how are you going to convert the blood maps. or how are you going to reproduce the blood´s ror (the one Eduke32 features right now seems to be pretty ¨young¨ and basic yet). Everything else could be easily done by a couple of talented modders.

If I were starting this project myself, the first thing i would worry is about how to convert blood maps to eduke32 maps.

EDIT: I really would like to map for Blood if it were easy as it is for Duke.

[m210®]

There is a program "Build map version 6 -> Build map version 7 (convmap7)" But after convertion doors/lifts and some effects doesn't works on maps and it need to fix in mapster32.

[Stabs]

I think blood also use acceleration values for doors and lifts so that would need to be worked out also

[Franpa]

DeeperThought, on Apr 12 2010, 04:40 AM, said:

The source code for Blood was never released, so the only way we can play it is through DOSBox. It works, but, the mouse aiming in Blood is crap imo and I would much rather play it on EDuke32. Also, once we have it on EDuke32, it can be modded.

Also not everyone has a decent CPU for the DOSBox demands. I would assume Monolith don't care about people spreading the game data files etc. at the moment because of the very fact that there is no project/port of the game near completion. I wouldn't put it past them to issue a Cease and Desist order as the project nears completion just like Square Enix did for that fan made mod of one of there games.