[solved] Wall texture problems when compiling as C++

[Scet]

I've been working on a port based off the original Linux Doom source, compiled using VC++ 2008. Everything works when compiling as C, however if I switch to C++ I get this pixel vomit.

As you can see both the wall textures and sky are messed up. While there's only one pattern in the picture, there is another. It depends on what side of the wall you're on.

I'm posting here wondering if anyone else has run into something similar and knows how to fix it. I really have no idea where to look. I've already tried changing a lot of the compiler settings, but they don't seem to have any affect.

[myk]

The status bar also seems to be affected, as some of the graphics applied on it are absent.

[Scet]

The status bar problem was seperate and has been fixed.

[Gez]

This might be a start:
http://www.cprogramming.com/tutorial/c-vs-c++.html

Try looking through the code and converting "C-isms" to "C++-isms".

You might want to look at the ZDoom code for some parts, since it has been successfully ported to C++, however it has drastically changed in a lot of places.

[Scet]

I've solved the problem. It was the "boolean masked" variable in the maptexture_t struct. In C++ it was 1 byte instead of 4, so I changed it to "int masked".

[rpeter]

The same goes for anim_t in p_spec.c: boolean istexture is not a bool value at all.

[chungy]

If there's no practical benefit to using C++ in your project, I would recommend to stick with regular ol' C.

Also for starting off a new port, you might be interested in using Chocolate Doom as a base instead. It's based directly on the Linux Doom source, but it contains as many fixes (or breakage, however you want to look at it) as possible to bring the codebase back to how Doom 1.9 operated. IMO, a better choice for starting off a "from scratch" port.

[Quasar]

This is ultimately a symptom of DOOM doing something you shouldn't do even in C - relying on the size of various data types and on the alignment of structure members in memory.

In the case of boolean, it's a problem because C++ is smarter about assigning the smallest sufficient variable size to enumeration types. C just promotes them all to int AFAIK.

The proper things to do are to eliminate reliance on data types without a fixed size and reading/writing of structures directly from memory where possible, and/or use the appropriate packing pragmas around structures that need to be mappable (like patch_t, in this case :)

[Scet]

I've only had one other problem related to this, the "weaponowned" variable in player_t was set to boolean[] and later cast to (int*) when passed into STlib_initMultIcon. In C++ the extra three bytes are not zero, but "leaked" values from "ammo", again I just solved it by making it int. The game runs fine now.

I was going to use the Chocolate source, but it seems to have ballooned to an enormous size. The Linux Doom source is much smaller and IMO easier to port. Plus finding the "bugs" of the original is half the fun!

The reason I'm using C++ is that I want access to namespaces and templates. I may also use some inheritance, but only if necessary.

Quasar said:

The proper things to do are to eliminate reliance on data types without a fixed size and reading/writing of structures directly from memory where possible, and/or use the appropriate packing pragmas around structures that need to be mappable (like patch_t, in this case :)

That's the point of my port, to clean up the original code and not rely on memory tricks.