Duke3d porting team

ReGex · Post by **ReGex** » Tue Apr 08, 2003 9:35 pm

Are any of you other devvers looking at porting Duke3d? I would like to do this as a team project, so I was wondering if anyone else would like to help out? I don't know if Bero has decided to do anything with this yet, but he would make the best team leader because he's done so many FPS ports before. Has anyone talked to him lately? Anyways, I'd just like to see if there's any interest out there.

-ReGex

BlackAura · Post by **BlackAura** » Tue Apr 08, 2003 11:39 pm

Maybe. I've done two FPS ports (nxDoom and nxQuake).

I think that Duke3D has too much assembler in the Build engine for it to be easily portable. That said, it should be possible to replace it with C code, and we certainly don't need a heavily-optimized software renderer on a Dreamcast.

First off, though, we need to port the Build engine itself. That should be our first target.

ReGex · Post by **ReGex** » Wed Apr 09, 2003 1:25 am

Most of the assembly code I've looked at seems to be very specific texture mapping stuff.. what I'd like to do is more along the lines of a GL port and localization to the DC. I think this is a much cooler approach than simply doing the standard non-accelerated port thing. What do you think? I think it would actually be pretty easy to do (the only thing we'd have to do is compensate for the virtual z-space, which isn't that much of an issue), but I've never done an FPS port before.

-ReGex

BlackAura · Post by **BlackAura** » Wed Apr 09, 2003 4:14 am

I'd agree, and it also have the advantage that a hardware-accelerated port is more possible than a software-rendering port. And it'd look so much better. Of course, we just need to make sure that there's no other important ASM code anywhere.

One problem with using hardware acceleration is that the Build engine doesn't actually use polygons. In most 2.5D engines, the walls are quite well defined, and can be rendered as one or two textured quads, using the 2D vertexes and the floor height, but the floor is just "the area between the walls". While this is fine for a raycasting engine, it's not really appropriate for a polygon-based engine. We'd need some way of turning that into a convex polygon, or a load of triangles, that we can actually render. That could be more tricky, but it should be possible. Either that, or we'll have a version with no floors/ceilings for a while.

The alternative is to try to just replace the rendering part of the raycasting engine, so we use raycasting to convert the 2.5D stuff into 2D coordinates, and then render those. But I've never seen that done before, so I assume that'd be a pain in the neck to do.

I've seen an OpenGL version of the Build engine somewhere. I'll see if I can find it. Even if we don't use it, it'll give us somewhere to start from.

L@ Cible · Post by **L@ Cible** » Wed Apr 09, 2003 4:25 am

I've tried to port the Build Engine from this version :
jonof.edgenetwork.org/winbuild/
but i've poor teorical skill about ray casting technique ( if build really use it )

BlackAura · Post by **BlackAura** » Wed Apr 09, 2003 5:42 am

It does use raycasting. I only have a vauge understanding of the theory, and very little understanding of the practice. I can understand polygon-based engines far better.

It would be a good idea to look at the Build engine port from Icculus. It uses SDL (although I'm not suggesting that we do the same), and it should be easy enough to understand. It also has the beginnings of OpenGL support, which we might be able to build on. Really, the more Build engine ports we look at, the better understanding we should have of what's going on.

I do think that we should try to port the Build engine itself before we even look at Duke Nukem 3D. If we did that, we'd also be able to play KenBuild, which is the build engine demo game released by Ken Silverman.

It'd certainly be interesting to do the first ever non-Intel port of the Build engine.

L@ Cible · Post by **L@ Cible** » Wed Apr 09, 2003 6:09 am

BlackAura wrote: I only have a vauge understanding of the theory, and very little understanding of the practice. I can understand polygon-based engines far better.

What , Doom doesn't use ray casting

L@ Cible · Post by **L@ Cible** » Wed Apr 09, 2003 6:58 am

BlackAura, why do you want to use SDL API for the BuildEngine ???
I think that it easier of is used directly the frame buffer of the DC :

Code: Select all

for(int x =0;x<vid_mode->width;x++)
{
	float AngleInCameraFOV = ((x*90.f)/vid_mode->width)-45.f;

	int DistanceOfFirstWall = LaunchRay(CameraPos,AngleInCameraFOV, ... );

	for(int y=0;y<DistanceOfRay;y++)
		vram_s[x*vid_mode->width+y] = ceilingTexture[???];

	for(int y=DistanceOfRay;y<DistanceOfRay+(vid_mode->height-2*DistanceOfRay);y++)
		vram_s[x*vid_mode->width+y] = WallTexture[???];

	for(int y=0;y<DistanceOfRay;y++)
		vram_s[x*vid_mode->width+(vid_mode->height-y)] = floorTexture[???];


}

euh , maybe not !

BlackAura · Post by **BlackAura** » Wed Apr 09, 2003 9:37 am

Doom uses raycasting, but I don't have a clue how it works. The code is really, really confusing. I can understand virtually everything about Doom but the rendering engine.

Anyway, I don't want to use SDL for a DC port - that would be a bit silly. But the icculus port already uses SDL, and it's trivial to convert SDL framebuffer access to KallistiOS. Besides which, it is useful to have the game running on a PC (using SDL) and a Dreamcast (using KOS), since it's easier to debug on a PC than on a DC. And we need to actually run the game while we're gradually replacing all that self-modifying asm code, and we can't do that on a DC until we've finished.

I think it might be wise to start with Ken's original source release, and patch in any code we need from other ports as required, rather than try to use an already-modified port.

BlackAura · Post by **BlackAura** » Wed Apr 09, 2003 10:53 am

Just found one other problem. The released source only works with v1.5 of the Duke Nukem 3D data files (the Atomic Edition)

The shareware version stops at 1.3d, and the original registered version (which I have) is also version 1.3d. It can be upgraded to 1.4, but only if you buy the Plutonium Pak. Which, of course, 3D Realms no longer sell...

That means that any port would only work correctly with the full Atomic Edition.

I did get it to run the original registered version (sort of) by modifying the CON files a little bit. But it doesn't quite work correctly. I assume that's because the CON files are different in the Atomic Edition. That means that we might have to do a bit of hacking to get it working on the shareware or original registered versions. Maybe someone experienced in Duke3D CON editing could help with that, since I really don't have a clue what most of it does.

Mask of Destiny · Post by **Mask of Destiny** » Wed Apr 09, 2003 11:32 am

People have been getting the ports to work with 1.3d files. If you look around on the 3DRealms forums you should be able to figure out what they did.

ReGex · Post by **ReGex** » Wed Apr 09, 2003 11:37 am

Hey BlackAura,
I have sort of a method devised for translating the floor/ceiling into polys (it's actually pretty simple, just a little bit of list processing). I'll write a doc about it this eve. (got a pile of stuff to do today though).

I've been basically just reading the source and figuring out strategies for the biggest challenges. I'll put my comments file up on my website this evening too. I think if we can look at filesystem/map/resource data structure code it shouldn't be too hard to figure out what's going on to support shareware data files etc..

Overall, I think you're right, there's no point in starting directly on an SDL port on the DC. I think a quick PC OpenGL Win32 port should be done, then it'll be easy to move to the DC (especially because the compiler differences will filter out mostly between the Watcom -> VS6 conversion, so there will be fewer problems moving VS6 -> GCC).

Look at the drawrooms(...) function in engine.c in all the other ports, that's where the jumble really starts to build. I think the stereographic image support should be removed too, but that's kind of unimportant ATM.

-ReGex

BlackAura · Post by **BlackAura** » Wed Apr 09, 2003 12:20 pm

People have been getting the ports to work with 1.3d files. If you look around on the 3DRealms forums you should be able to figure out what they did.

I got it working, but not terribly well. I'll look around the forums and see what I can dig up. There should be a way to get it running perfectly, although I suspect we'd have to tweak the engine a bit (remove the last episode, for a start).

Overall, I think you're right, there's no point in starting directly on an SDL port on the DC. I think a quick PC OpenGL Win32 port should be done, then it'll be easy to move to the DC (especially because the compiler differences will filter out mostly between the Watcom -> VS6 conversion, so there will be fewer problems moving VS6 -> GCC).

Sounds like a good idea. It shouldn't be too hard to strip out all of the Watcom dependencies, especially since we don't need them for Win32/Linux/KOS. Just as long as we don't start using VS6 extensions, we should be OK.

Of course, there's no reason not to use SDL for a quick Win32 port. It's much easier than trying to use the Win32 API, and much, much easier than trying to use DirectX. And KOS is easier to use than the lot of them, in my opinion.

I'm going to read through the unmodified, original source code for Ken's Build engine, and see if I can clean it up a bit. If we have a more portable base to work with, it should make porting this easier.

Still, I have a feeling that converting a raycasting engine to a 3D polygon engine is going to be a bit of a headache.

ReGex · Post by **ReGex** » Wed Apr 09, 2003 12:34 pm

[quote]Still, I have a feeling that converting a raycasting engine to a 3D polygon engine is going to be a bit of a headache.[/quote]

Actually, my main fears center around the light + mirror engine. Rather than casting rays backwards from a mirror, you have to do some geometrical tricks to get the desired result in 3d.

I have a pretty nicely encapsulated Win32 OpenGL framework that I've developed, that I can share around too.

-ReGex

BlackAura · Post by **BlackAura** » Wed Apr 09, 2003 12:45 pm

How much does this framework encapsulate? If it could be modified a little, so that it encapsulates everything that's different between OpenGL and KallistiGL, we could use it on the Dreamcast and Win32, and not have to modify any of the code, especially for texture loading.

Actually, my main fears center around the light + mirror engine. Rather than casting rays backwards from a mirror, you have to do some geometrical tricks to get the desired result in 3d.

Stencil buffering would be useful for that. But I don't think the Dreamcast supports them.

ReGex · Post by **ReGex** » Wed Apr 09, 2003 1:22 pm

Actually, there's very little practical difference between KGL and the MS OpenGL engine (geometry wise, at least, if not for a few missing features). If we get the geometry engine working under Win32, then moving it to the DC would be more or less trivial.

-ReGex

EverStoned · Post by **EverStoned** » Wed Apr 09, 2003 3:49 pm

ReGex wrote:Actually, there's very little practical difference between KGL and the MS OpenGL engine (geometry wise, at least, if not for a few missing features). If we get the geometry engine working under Win32, then moving it to the DC would be more or less trivial.

-ReGex

DukeGL wouldn't need any of the speicalty OpenGL features that KGL can't handle, would it?

BlackAura · Post by **BlackAura** » Wed Apr 09, 2003 8:42 pm

Geometry code is very similar, but I was thinking about things like texture loading, which is very different in KGL, and other stuff like starting/finishing a frame.

BlackAura · Post by **BlackAura** » Thu Apr 10, 2003 12:36 am

Actually, my main fears center around the light + mirror engine. Rather than casting rays backwards from a mirror, you have to do some geometrical tricks to get the desired result in 3d.

Actually, the mirrors in the Build engine are faked, as far as I remember. At least in Duke 3D, you need to create a copy of the room behind the mirror, flip it around, and give it some special tags. It then renders that area normally, and clones any sprites from the real area into the mirrored area.

Basically, in real life, there appears to be another room behind the mirror. In Duke 3D, there actually is another room behind the mirror.

I've been stripping as much of the asm code out as I can understand. Mostly the non-DOS stuff in pragmas.h. I have most of the math code converted to C #defines, and some of the utility functions.

Why didn't he do them in C anyway? I wouldn't think that this code:

Code: Select all

a = b * 5;

would be worth optimizing in asm, since the compiler should generate the same code anyway. Unless the compiler is terminally stupid, of course. An optimising compiler, especially for the SH-4, should generate even faster code, since it doesn't have to do any register swapping like Watcom's "#pragma aux" does

Edit: Seriously, why is this in assembly? Below is an actual replacement I'm using to replace about ten pages of assembly code:

Code: Select all

#define tmulscale(a,b,c,d,e,f,g) ((a*b + c*d + e*f) >> g)
#define tmulscale1(a,b,c,d,e,f) tmulscale(a,b,c,d,e,f,1)
#define tmulscale2(a,b,c,d,e,f) tmulscale(a,b,c,d,e,f,2)

...

#define tmulscale31(a,b,c,d,e,f) tmulscale(a,b,c,d,e,f,31)
#define tmulscale32(a,b,c,d,e,f) ((a*b + c*d + e*f))

// And here's some really pointless stuff...
#define mul3(a) (a*3)
#define mul5(a) (a*5)
#define mul9(a) (a*9)
#define divmod(a,b) (a/b; dmval=a%b) 
#define moddiv(a,b) (a%b; dmval = a/b)

Edit 2:Having trouble with some of this asm code. It's pretty convoluted, and I've not done very much x86 asm programming in... ooh... ever. As far as I can work out, this:

Code: Select all

#pragma aux divscale =\
	"mov edx, eax",\
	"shl eax, cl",\
	"neg cl",\
	"sar edx, cl",\
	"idiv ebx",\
	parm nomemory [eax][ebx][ecx]\
	modify exact [eax ecx edx]\

Should be replaced with:

Code: Select all

#define divscale(a,b,c) ((((__int64)a)<<c)/((__int64)b))

But I really don't have a clue what this does:

Code: Select all

#pragma aux boundmulscale =\
	"imul ebx",\
	"mov ebx, edx",\
	"shrd eax, edx, cl",\
	"sar edx, cl",\
	"xor edx, eax",\
	"js checkit",\
	"xor edx, eax",\
	"jz skipboundit",\
	"cmp edx, 0xffffffff",\
	"je skipboundit",\
	"checkit:",\
	"mov eax, ebx",\
	"sar eax, 31",\
	"xor eax, 0x7fffffff",\
	"skipboundit:",\
	parm nomemory [eax][ebx][ecx]\
	modify exact [eax ebx edx]\

I'm guessing that it's supposed to multiply two numbers and scale them, as in mulscale, but then it bounds it to a 32-bit range (-2G ... 2G) instead of leaving it as a 64-bit value. But it's pretty confusing stuff.

ReGex · Post by **ReGex** » Thu Apr 10, 2003 11:13 am

Did you look at the message decryption/version/copyprotection system Ken put in? Check out the kensmessage code at the beginning of engine.c. Yeah, not like you couldn't have done that in C. I knew guys like this back in highschool who thought that thought binary searches and sorts were "so much easier to read" in x86 ASM... BLARRRGH.

-ReGex

PS - Not the foggiest what's going on there, looks like he's rangechecking the top 31 bits out of the boundary (shift + rotate right 31 bits, then xoring what's left... the purpose of xoring that would just find the bits that were 0's in the original number shift + rotated over 31 places- the practical purpose of this ... damned if I know). What is the s? jump condition (sorry, I'm a lil' rusty on my x86 ASM myself).

[Edit: Didn't see it before, after taking another look, I think you're right, that's more or less what's going on... sar isn't shift and rotate, it's signed arithmetic rotate right?]