Wolf4SDL\DC

Talk about Quake, Doom, Wolfenstein 3D, or other DC first person shooting game ports and mods for those games in here.
Post Reply
User avatar
emptythought
DC Developer
DC Developer
Posts: 2015
Joined: Wed Jan 30, 2002 9:14 am
Location: UNITED STATES NRN
Contact:

Wolf4SDL\DC

Post by emptythought » Thu Feb 25, 2010 12:54 pm

I'm starting a Wolf4SDL\DC page for requests and help speeding it up. Any suggestions please reply!
Stryfe
Psychotic DCEmu
Psychotic DCEmu
Posts: 577
Joined: Mon Aug 11, 2008 9:34 am
Location: Nowhere U.S.A.

Re: Wolf4SDL\DC

Post by Stryfe » Fri Feb 26, 2010 11:25 am

I can't really help with programming. All I've ever done is compile some examples, and the older PC I did that on is in storage right now...

As far as suggestions go: (I might have mentioned these before)

There are site that offer mods for Wolf3d, and it's sequel SoD. The Wolf 3D Dome for instance. All these mods require are the original '.WL6' data files from the registered Activision (1.4) version, or the '.WL1' files from the last shareware demo version.

Like GAMEMAPS.WLx gets replaced to change the ingame level maps...

All the mods do is replace certain WL6, or WL1 files, leaving the rest of the game files intact.

What this means though is that you could only have one mod, or original game on a disc. Is there a way a selected folder on the disc could be loaded from a list entry? (Instead of the default 'wolf3d')
ImageImageImageImage
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am

Re: Wolf4SDL\DC

Post by Chilly Willy » Sat Feb 27, 2010 2:27 pm

You might try working from the PSP version of Wolf3D.
speewave
DCEmu Fast Newbie
DCEmu Fast Newbie
Posts: 18
Joined: Sun Feb 28, 2010 9:29 pm

Re: Wolf4SDL\DC

Post by speewave » Mon Jun 07, 2010 9:55 am

i thought someone had a working SDL port of it
Stryfe
Psychotic DCEmu
Psychotic DCEmu
Posts: 577
Joined: Mon Aug 11, 2008 9:34 am
Location: Nowhere U.S.A.

Re: Wolf4SDL\DC

Post by Stryfe » Tue Jun 08, 2010 5:31 pm

i thought someone had a working SDL port of it
...
...
...

The OP does, and It's called Wolf4SDL:

Code: Select all

http://dcemulation.org/?title=Wolf4SDL\DC
He was asking for any (general?) suggestions, and/or help from any devvers on speeding it up.
ImageImageImageImage
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am

Re: Wolf4SDL\DC

Post by Chilly Willy » Fri Jun 11, 2010 11:51 pm

Well, two generic tips related to the graphics that make a BIG difference:

First, make all graphics buffers uncached. Graphics flood the cache, slowing things down, and frame buffers in particular are nasty on the cache. It's easy to see the affect drawing has on the cache - display the FPS, look towards the middle of an area, then turn to look at the wall. You'll see a HUGE drop in the frame rate. That's CACHE related! Making the frame buffers and whatnot uncached will cause that drop to go away.

Second, since you are now not caching the frame buffer, if you use software to draw the actual frame from the frame buffer the game draws into, fetch the data as longs, not bytes. For example, here's how I update the display in my PSP version of Doom:

Code: Select all

	for (j=top; j<height; j++)
		for (i=left; i<width; i+=4)
		{
			u32 fp = *(u32 *)&screens[0][i + j*SCREENWIDTH];
			if (video_is_laced)
			{
				if (j & 1)
				{
					base_address[i + (j>>1)*lineWidth] = palette[fp&0xff];
					base_address[i + 1 + (j>>1)*lineWidth] = palette[(fp>>8)&0xff];
					base_address[i + 2 + (j>>1)*lineWidth] = palette[(fp>>16)&0xff];
					base_address[i + 3 + (j>>1)*lineWidth] = palette[fp>>24];
				}
				else
				{
					base_address[i + (j>>1)*lineWidth + 262*lineWidth] = palette[fp&0xff];
					base_address[i + 1 + (j>>1)*lineWidth + 262*lineWidth] = palette[(fp>>8)&0xff];
					base_address[i + 2 + (j>>1)*lineWidth + 262*lineWidth] = palette[(fp>>16)&0xff];
					base_address[i + 3 + (j>>1)*lineWidth + 262*lineWidth] = palette[fp>>24];
				}
			}
			else
			{
				base_address[i + j*lineWidth] = palette[fp&0xff];
				base_address[i + 1 + j*lineWidth] = palette[(fp>>8)&0xff];
				base_address[i + 2 + j*lineWidth] = palette[(fp>>16)&0xff];
				base_address[i + 3 + j*lineWidth] = palette[fp>>24];
			}
		}
One long in is converted from four 256 color pixels into four 32-bit direct color pixels.
User avatar
emptythought
DC Developer
DC Developer
Posts: 2015
Joined: Wed Jan 30, 2002 9:14 am
Location: UNITED STATES NRN
Contact:

Re: Wolf4SDL\DC

Post by emptythought » Tue Aug 17, 2010 1:48 pm

Stryfe wrote:...

What this means though is that you could only have one mod, or original game on a disc. Is there a way a selected folder on the disc could be loaded from a list entry? (Instead of the default 'wolf3d')
I started thinking about a mod list based on "Robert's Jukebox" menu but the code in Wolf4SDL needs an entire overhaul to implement this sort of menu since the graphics are loaded from the maps (CheckForEpisodes()) and then cached into memory... I'll have to look more into it.
Stryfe
Psychotic DCEmu
Psychotic DCEmu
Posts: 577
Joined: Mon Aug 11, 2008 9:34 am
Location: Nowhere U.S.A.

Re: Wolf4SDL\DC

Post by Stryfe » Fri Aug 20, 2010 5:31 pm

I was originally considering bin hacking the game-file names in the binary.

Because many mods I encountered just replace 'some' of the original files, I was going to try changing the correct 'GAMEMAPS.WL6' instances in the binary (through a hex editor) to 'GAMEMAPS.WL7', or 'GAMEMAPS.WL8', etc...

Then I would have used Dream Inducer to multi-boot the renamed, separate, binaries. All the game files ('.wl6', '.wl1', '.sod', etc...) would then be placed in the 'WOLF3D' folder.
ImageImageImageImage
User avatar
emptythought
DC Developer
DC Developer
Posts: 2015
Joined: Wed Jan 30, 2002 9:14 am
Location: UNITED STATES NRN
Contact:

Re: Wolf4SDL\DC

Post by emptythought » Sat Aug 21, 2010 3:36 pm

Well my idea for the mod menu:

The disc layout:

Code: Select all

/cd
    data
        Wolfenstein 3-D
            demo
                14
                    *.WL1
            full
                14_gtinteractive
                    *.WL6
            mod
                nazialert_12
                    LIST
                    GAMEMAPS.WL6
                    MAPHEADS.WL6
                    VSWAP.WL6
The mod menu's LIST file:
Nazi Alert
1.4
GT Interactive
Full
Wolfenstein 3-D
I haven't gotten here yet but I need to figure out how I'm going to deal with file names that have a different extension (GAMEMAPS.KWF).

Still, that's pretty possible but I really want the menu done under Robert Jukebox's menu code and with that said there's a lot to get out of the way to even start on the mod menu unfortunately.
User avatar
Christuserloeser
Moderator
Moderator
Posts: 5918
Joined: Thu Aug 28, 2003 12:16 am
Location: DCEvolution.net
Contact:

Re: Wolf4SDL\DC

Post by Christuserloeser » Mon Aug 30, 2010 10:47 am

I'd like to request a cfg file to customize controls and options while booting the engine.

i.e. I not only prefer 138's control scheme, I can't even play properly using yours. But it would be nice to be able to control other aspects of the engine as well (i.e. music/sfx volume, etc.).
Insane homebrew collector.
Stryfe
Psychotic DCEmu
Psychotic DCEmu
Posts: 577
Joined: Mon Aug 11, 2008 9:34 am
Location: Nowhere U.S.A.

Re: Wolf4SDL\DC

Post by Stryfe » Fri Sep 03, 2010 11:53 am

I appreciate anything emptythought does with this. It's nice to know that there are some DC ports still being worked on. :)

I think that the resolution may end up being selectable (320x240 vs 640x480), but I wouldn't get my hopes up for customizable controls.
ImageImageImageImage
User avatar
emptythought
DC Developer
DC Developer
Posts: 2015
Joined: Wed Jan 30, 2002 9:14 am
Location: UNITED STATES NRN
Contact:

Re: Wolf4SDL\DC

Post by emptythought » Sat Sep 04, 2010 2:24 pm

Not really a problem. I'm just making it a stepping stool for people who want to speed it up. I don't think I'll be able to implement the uncached graphic routine ChillyWilly suggested.
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am

Re: Wolf4SDL\DC

Post by Chilly Willy » Mon Sep 06, 2010 11:23 pm

You don't need to worry about every detail, just get something working. Others can then pitch in here and there for little bits to make it better. That's the good part of open source. If you can't get uncached display buffers working, someone else may. :grin:
User avatar
Christuserloeser
Moderator
Moderator
Posts: 5918
Joined: Thu Aug 28, 2003 12:16 am
Location: DCEvolution.net
Contact:

Re: Wolf4SDL\DC

Post by Christuserloeser » Tue Sep 07, 2010 10:29 am

I wonder if you could use parts of your SH2 code to improve upon the Dreamcast port, Chilly... ? From what I heard the SH4 actually is compatible to SH2 code, aside of the little endian/big endian issue (not that I'd really know what that means).
Stryfe wrote:I think that the resolution may end up being selectable (320x240 vs 640x480), but I wouldn't get my hopes up for customizable controls.
I don't think the resolution needs to be upscaled. Dreamcast automatically upscans to 640x480p in VGA, and for non-VGA compatible monitors 480i would be a disadvantage provided the graphics aren't redrawn to actually make use of the higher internal resolution.

Customizable controls however would be really nice to have, especially for a DCEvolution image, so we could adjust the default configuration to match those of the other Dreamcast FPS.
Insane homebrew collector.
Chilly Willy
DC Developer
DC Developer
Posts: 414
Joined: Thu Aug 20, 2009 11:00 am

Re: Wolf4SDL\DC

Post by Chilly Willy » Tue Sep 07, 2010 2:24 pm

Christuserloeser wrote:I wonder if you could use parts of your SH2 code to improve upon the Dreamcast port, Chilly... ? From what I heard the SH4 actually is compatible to SH2 code, aside of the little endian/big endian issue (not that I'd really know what that means).
Yes, there's not a lot of difference there. Mainly speed, endianness, and floating point support. Anyone who can do SH2 code can do SH4 code.

Endianness is just the order of bytes in memory - little endian means the least significant bytes come first, while big endian means the most significant bytes come first. The DC is little-endian, while the 32X (with the SH2) is big-endian. Such differences are easy to deal with... when the programmer thinks about that ahead of time. Part of the issue with Doom when the code first came out is the programmers at id didn't consider endianness, so a lot of work (some of it by myself) went into finding all the places the endianness mattered and fixed the code to deal with it.

In any case, there isn't a lot of assembly in Wolf32X - just two pieces:

multiplying two fixed point numbers

Code: Select all

fixed FixedByFrac(fixed a, fixed b)
{
    fixed c;
    asm("mov %0,r1"::"r"(a):"r1");
    asm("mov %0,r2"::"r"(b):"r2");
    asm("dmuls.l r1,r2");
    asm("sts mach,r1");
    asm("sts macl,r2");
    asm("xtrct r1,r2");
    asm("mov r2,%0":"=g"(c));
    return c;
}
byte swapping a longword

Code: Select all

static __inline__ uint32_t SwapInt32(uint32_t i)
{
	//return	((uint32_t)(i & 0xFF000000) >> 24) |
	//	((uint32_t)(i & 0x00FF0000) >>  8) |
	//	((uint32_t)(i & 0x0000FF00) <<  8) |
	//	((uint32_t)(i & 0x000000FF) << 24);
	uint32_t v;
	asm("mov %0,r1"::"r"(i):"r1");
	asm("swap.b r1,r1");
	asm("swap.w r1,r1");
	asm("swap.b r1,r1");
	asm("mov r1,%0":"=g"(v));
	return v;
}
Using uncached memory is actually pretty easy - just OR a value with the pointer (when the MMU is not in use for the DC). On the SH2, the value is 0x20000000. On the SH4, the value is 0xA0000000.

For example, here's how I got uncachable memory for Doom for DC:

Code: Select all

    vid_size = SCREENWIDTH*SCREENHEIGHT*4+SCREENWIDTH*ST_HEIGHT;
    vid_mem = malloc(vid_size);
    if (vid_mem == NULL)
      I_Error ("Couldn't allocate memory for screens\n");
    dcache_flush_range((uint32)vid_mem, vid_size);
    vid_mem = (byte *)((int)vid_mem | 0xA0000000); // uncached access
Just allocate memory, flush is from the caches, then OR the magic value to the pointer you use to access the memory.

Funny enough, I never got around to putting the assembly fixed multiply or byte swap into Doom for DC. :oops:

The current fixed mul is

Code: Select all

fixed_t
FixedMul
( fixed_t	a,
  fixed_t	b )
{
#ifndef USE_FLOAT_FIXED
    return ((long long) a * (long long) b) >> FRACBITS;
#else
	return (fixed_t)(((float)a * (float)b) * FRACINV);
#endif
}
and USE_FLOAT_FIXED is not defined, so it's using long long (64 bit) math.
User avatar
emptythought
DC Developer
DC Developer
Posts: 2015
Joined: Wed Jan 30, 2002 9:14 am
Location: UNITED STATES NRN
Contact:

Re: Wolf4SDL\DC

Post by emptythought » Fri Oct 30, 2015 1:31 pm

I have started a project called Project wildcardHASH. This is the two public links I have for everyone.

viewtopic.php?f=29&t=103775
https://docs.google.com/document/d/1NzM ... DzNNc/edit

Thanks.
Post Reply