Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Scet

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

Recommended Posts

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.

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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".

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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 :)

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×