Half-Life for Dreamcast has some functional multiplayer components

Alright so another cool progress update. Loading TFC by running 'startgame tfc' then loading a half-life map, the game still fails to load and stops around 80%-100%. This is really cool because it shows it's not a map issue with TFC maps. An asset is being loaded, or not loaded, that causes the engine to lock. Again strengthening the possibility the startgame command does more than change the search path

 

Weighing in here since @TerdFerguson poked me on this. On the Dreamcast (unlike in regular Windows programming) handling the interface to communication device (modem or BBA) was up to the game. A developer couldn't just call for network access, and have the platform negotiate a connection for it. This is why some games support BBA and others do not, and why every games dialing process looks different.

Even if we were able to re-enable to code for networking from within the game, someone would need to write the code to establish a connection. I tried to read back through the posts here to see if that problem had been solved, but didn't find it. Is there a resolution to this issue? Or are you still assuming the connection will be established on behalf of the game?

 

It seems like you are more interested in getting mods to run, I didn't realize that was the focus. That's cool, but really not that interesting to me personally, compared to adding BBA support to the WinCE kernel anyway.

Honestly I think all you need to do is get the build environment set up properly and import the sources. I don't know anything about the HL external dependency build process (and don't really have a huge desire to learn) but as long as the DLL's are standalone and not resolving any external symbols outside the WinCE libraries, you should be able to compile them with a copy of Visual Studio Enterprise and the WinCE 2.1 Dreamcast SDK. You can read the steps required to get the build environment up and running in the 'Getting Started' HTML file in the WinCE SDK directory. Note that Visual Studio has progressed significantly in the last 15-16 years so you might need to get a version that was in use closer to the build date of the software (2001 IIRC).

The SH4 DLL sources that were linked in this thread haven't really had much changed that I can tell apart from some calls to POSIX string compare functions instead of the legacy Windows ones. The makefile in the root directory is still setup to build a .so file for an i386 Linux machine, so you will need to build the project in Visual Studio yourself. This really isn't difficult to do, but I am not a Windows dev and don't really want to jump through the hoops required to get everything up and running.

I looked at the emulator situation a bit and they pretty much all suck for development work. Developing on native hardware would required a BBA which I don't currently have, and a second TV which I also don't currently have. Given that the focus is mainly on mod work, and the fact that I don't have any way to develop and debug, I probably won't go any further with it any time soon. Good luck-

 

It's not really that I'm more interested in getting the mods to load over multiplayer. I'd be cool with playing HLDM without mod support. But if we can load the extension DLLs then the support for the Dreamcast's networking hardware can likely be added there, unless someone can tell me why that wouldn't work. Eliminating the need for deep/extensive binary hooking

What I mean is, when a mod is made if any new functions to the engine need to be made they're made in the sources provided in the SDK. This produces a new client DLL. An extension of the engine. So in the case of the Dreamcast, if we compile an extension and it loads then AFAIK changes to the engine can be made as far as the persons skill and creativity allow.

Then my hypothesis is support for the modem/broadband adapter can be defined along with the console commands to use them. This can be open sourced for anyone who ports, for sake of discussion, the sources to CS 1.5, can add that in the compile. Allowing multiplayer, rather than just loading the mod. I feel like you guys are misunderstanding that

I'm not asking to add the hardware support. But if we compile an extension file, with something added to know it loaded then I can investigate further and try getting it to load. To prove the concept. Then if anyone with the skill, and time wants to add the hardware support and/or port mods the concept will have been proven and well documented here

-----------------------------------

I got those from someone who got them from Moi. Was told they were ready to compile for the most part for HLDC. I don't have any coding skill so I wouldn't be able to tell how much or how well they were modified. I contacted Moi asking for the extension he compiled. But he isn't online too much

 

@Trident6 When you get the chance, could you take another look at the assembly and tell me what the startgame command does? It's clear it does more than change the search path, but I can't tell exactly what else

 

I understand what you are trying to do. What you need to understand is that the Dreamcast has an on-board MMU that is used to provide virtual memory addresses in the 4GB range to map to the physical 16 MB SRAM and memory-mapped onboard peripherals. WinCE uses the MMU to provide a protected address space to each process, meaning that a process can't write to memory outside its own virtual address space without trapping the MMU and halting the system. These are the read access errors you posted pictures of earlier.

The kernel or BIOS is typically responsible for MMU initialization and arbitration. In the case of a normal Katana-developed game, there is no concept of a process so it is up to the developer to use the MMU as they see fit withing the constraints of the hardware. In the case of WinCE, with a heritage from desktop operating systems, the concept of a process is inherent to it's design. In fact, the Katana BIOS/OS has no concept of time-sharing or multitasking at all if you read the SDK docs (that I could find anyway). This is somewhat significant as the Q3 engine was inherently multithreaded, meaning that Carmack either hacked the CE kernel to add BBA support or wrote his own multitasking kernel to sit on top of the Katana BIOS, depending which route he went with development.

Regardless, in this case the WinCE kernel either sits on top of or bypasses the standard on-board BIOS (it isn't clear to me which) so access to the memory-mapped hardware will need to go through the kernel. When you load a DLL, it gets loaded into the process address space. Consequently any side-loaded commands attempting to access the hardware from virtual process address space will fault. If you want to access the hardware, the functionality needs to already exist in the kernel and you just make the system call to tell it what to do.

Could you bypass this? Sure, that is what kernel 0-days are all about. But that would take an astronomical amount of effort and would pretty much be pointless since I have the ability to change the kernel before it is even loaded and executed.

 

At least I now understand when the "mnemo cache" is. So if the kernel can be changed before load, what would have to be done to append the virtual address space needed and hook the binary to load the extensions? Is that less of an involved task than hooking network handling?

I'm still going to try to compile a DLL, either myself and learn how or find someone who is willing. There is still a possibility it can be loaded when properly compiled for the Dreamcast and using the 'startgame' command. And if that turns out to be the case, maybe gearbox already did the necessary coding to append the extension DLL to the MMU. Or perhaps it will work, but will crash the engine with read access errors like you said. Either way, we'd need an extension to test that or to know the modifications to the kernel/hooking to load it worked. That will be my current task

But could you tell me what's in the assembly for the startgame command? Those "customization" commands lead me to believe it is in fact trying to load the extensions, or something else and crashes

Apologies if I seem annoying because I don't have the skill or knowledge I need to see this through myself. But through the many months of research in this, I still find new, perhaps overlooked stuff like the auto-config CFG on memory card, or the startgame command. The one or two mods I ripped both had the files in the "barney" or "valve" folders. And there's no info i've found about multiple mods on-disc. I think if I get an extension to compile, and do some more digging I'll eventually strike gold

 

Well I have everything setup in the CE dev software. I'm down to only 4 errors. I cannot copy text from the virtual machine, so I'll attach screenshots



I tried doing this in all the include files for pm_math.c

Code:

#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif

But that didn't work

The rest are syntax errors for one function




I didn't want to ask for help here. But those are the last four errors. I fixed the rest. If I somewhat understand how to fix i'm sure it'd be a no-brainer for you guys. After I'm pretty sure it will compile. Hope you guys can help

 

http://stackoverflow.com/questions/...th-math-h-but-not-with-cmath-in-visual-studio

 

Thank you. So before the includes put

Code:

#define _USE_MATH_DEFINES
#include <math.h>

?

Edit: Ah cmath must be one of the default includes in visual studio yeah?
Edit 2: Do this in pm_math.c or in one of the header files?

 

No dice, I tried

Code:

#define _USE_MATH_DEFINES
#include <cmath>

before anything in the file

Even tried putting this in a header file and including it

Code:

#pragma once
#include <cmath>
#ifndef M_PI
namespace
{
    const double M_PI = std::acos(-1.0);
}
#endif

Off to sleep, I'll work on this more tomorrow night. What about those syntax errors?
If I compile, I'll upload the compile ready sources to github and post the DLL here. Thanks for assistance

 

Dreamcast have no BIOS in term like it is in PC. there only small set of functions sitting in start of RAM, so called "syscalls", to access GD-ROM and flash. obviously they exists for security purposes only, so numerous people who has access to Katana or WinCE SDKs can't dig in its libraries information about how to access that parts of hardware.
at the rest - Katana or WinCE builded binaries is self-sufficient executables, and doesn't uses some sort of runtimes or external calls.

 

Add this to the beginning of the .c or .cpp file where you get undefined external symbols:

#define M_PI 3.14159265358979323846

'startgame' is a very complicated function, I won't have time to look at it with any depth for a few weeks.

Understanding virtual-to-physical memory address translation gets into the fundamentals of OS design, you can look it up on OSDev if you want or find more information on the internet. But essentially every address is a 32-bit number in the 4GB space, including the MMIO addresses. A process can try to read any address it wants, but if the kernel (via the MMU) says that it doesn't belong to the requesting process, it will trap. There is no concept of an 'extension' to the MMU. There are a few more details to how the WinCE kernel allocates memory mapping in this specific case but you can read the docs if you want, I think I will just confuse you by trying to explain it here. It is in the 'Managing Memory' section of the .CHM.

BIOS is generally understood by non-technical people to mean hardware-provided software routines. Different hardware vendors provide a different amount of functionality at this level. It is semantics to me, you can call it BOOT.ROM or whatever you want. The fact that the BBA functionality is provided in static and dynamic libraries in the Katana SDK is what makes me think it would be possible to add to the WinCE kernel without too much effort.

Regarding DLLs, that statement is untrue. There is about 20 pages of information on how to compile, load and use DLLs, both at link-time and runtime in the WinCE documentation ('Dreamcast DLLs and Resources').

 

Alright so that fixed the undefined identifer error. But the syntax errors still prevent it from compiling. They're the last 3 errors and I think it'll compile

 

The way Moi setup the source, his files for example go in myprojects/DC-dlls. And either single player or multiplayer source folders go in the myprojects folder. So when I get this to compile I'm going to try swapping the included sources with the source for CS 1.5, TFC etc. Perhaps I can compile dlls for each game, but I doubt it

 

The string with syntax errors is

Code:

void VectorScale (const vec3_t in, vec_t scale, vec3_t out)
{
    out[0] = in[0]*scale;
    out[1] = in[1]*scale;
    out[2] = in[2]*scale;
}

Forgive me for the novice coding questions this is my first dabble in programming and after I think it'll compile

 

That seems fine to me, although my C is rusty. Maybe check the previous function/scope, sometimes an unbalanced parentheses or bracket can create an error on the next correct pair.

 

The second previous function has the comment // FIXME. Perhaps that's the function at fault?

 

Knowing the error message would help, from the previous pictures I was under the impression it was an issue with curly braces, looks like the three errors are linked as it finds a brace where it shouldn't and then the matching/scope is all broken.

The line you identified should not create any problem from the compiler pov.

Although I just noticed there's a variable in the erroneous function that is a vec_t type whereas all the other variables are vec_3t types, maybe you should try to change it.

 

Are you positive you are using the C compiler and not the C++ one? The syntax looks fine to me, and I can get it to compile in clang and gcc. M_PI is defined in mathlib.h though so I'm unsure as to why your compilation unit couldn't see it. Try changing those three lines to 'out[x] = (in[x]) * (scale);' If that doesn't work you will probably need to hop on freenode and get some help.