Borland C++ 3.1 Compiler in Windows Vista.

I want to start making TC's for Wolf3d. I tried installing Borland, but it doesn't work on Vista. Sent an e-mail to Brian Lowe about the problem, he said that it's possible with DOSBox. So i grabbed some Fanta, and started working. The installation started, good sign. I renamed the Borland folder to BC. I mounted the folder as: C:\BC. I didn't grab the folder at first, renamed the folders, and it worked. But then i got an error: "Too many subdirectories: Press ESC." What's the trick/way to fix this?

Well the most obvious way to fix this is to stop what you're doing immediately and switch to Wolf4SDL and use a much more friendly development environment like DevC++, Code::Blocks or even (dare I say it) MSVC. There are SOME differences (more macro code mostly and some other, somewhat complex stuff in addition to the obvious port to SDL and Win32 code) between the original DOS and the current SDL Code. You will be free of the 64KiByte memory limit, meaning you can do some seriously cool stuff like textured cielings/floors, 216 wall textures, directional sprites and a LOT of other stuff. Besides the massive number of wall textures, everything I just mentioned (plus some other stuff) already comes put in the Wolf4SDL code, all you have to do is un-comment some preprocessor definitions. Generally speaking, you'd be doing yourself and the community (by propagating the use of a much more functional and portable game) a big favor by using Wolf4SDL. You can do some of this stuff with DOS code, but you'd have to be extremely careful as your memory will quickly be eaten up, 64KiBytes isn't a terrible lot.

However, if you are dead set on using the DOS code, I don't know what to tell you if you're using Win7. DOSBox itself is just an emulator of DOS, so like most other emulations it is not perfect. There WILL be problems. Your first major problem is probably renaming your directory. Don't do that, leave it be. Secondly, BC++ has a mind numbing number of directories, probably more than DOSBox (which was primarily designed for DOS games based out of a single directory) was really designed to handle. So again I just really, really urge you to go with Wolf4SDL.

If a packet hits a pocket on a socket on a port,and the bus is interupted as a very last resort,and the address of the memory makes your floppy disk abortthen the socket packet pocket has an error to report!

At the risk of hijacking this thread, can I ask, in theory, how easy would it be to port a Wolf mod over to SDL? I used to program years ago (old 8 bit basic stuff and later TADS (Text Adventure Development System) and I haven't done anything for a long time. I would like to start messing around again and thought that maybe porting over some older Wolf mods might be a good thing to practice with and also be good for Wolf4SDL and the community... Maybe this info would be useful for WolffanatiK as well?

That's actually a semi-relevant question to this topic. Generally speaking, it depends on how much needs to be done. Naturally, DOS code which has been heavily modified will take quite a bit of porting. The biggest differences between Wolf4SDL code and the DOS code are how the video and memory is handled. For the most part it would be pretty straight forward, adding in new things into the game remains much the same.

It is when you begin messing with the rendering that it gets scary. Wolf4SDL uses modern graphics code to emulate the old video mode. But I mean really, unless you're going to be implementing something which Wolf4SDL doesn't already have support for out of the box, it should be straight forward. Transparent walls and doors require a minor rewrite, and about an hour of your time. The only thing that would REALLY require time and patience is giving it support for 15-32bit color modes. That would require a rewrite of almost everything to do with rendering. But if you're just aiming to convert some existing mods over to SDL, you shouldn't have too much trouble. As it stands, Wolf4SDL already has support for textured flats, hi- and lo-byte 3rd plane info (more than 1 texture on a flat per level), directional sprites, stars/rain/snow, shading, parallax skies and level feature flags like in EoD.

So in short, 90% of the existing ways to modify the engine are still relevant, the other 5% require varying amounts of ingenuity.

If a packet hits a pocket on a socket on a port,and the bus is interupted as a very last resort,and the address of the memory makes your floppy disk abortthen the socket packet pocket has an error to report!

That's pretty interesting. I am stupidly busy just now but when I get some time I think I might just look into that. I have heard good things about Code::Blocks. I'll have a look into that. I can do that in between jobs and I can do the prep work before I start in earnest. I'll also have to read up on SDL as I haven't a clue! Wish me luck.

Oh you'll definitely need some luck lol, and I wish you all of it! And ja, it really will require a lot of your time regardless.

If a packet hits a pocket on a socket on a port,and the bus is interupted as a very last resort,and the address of the memory makes your floppy disk abortthen the socket packet pocket has an error to report!