Messages

1756

Programming / Compiling on Cygwin

« on: July 04, 2010, 09:55:46 pm »

I did some research on the resulting objects and it seems although I got an error at the end, there were as many .o files as .h files which makes me think make did what it was supposed to
https://imagebin.ca/img/bPVxkQg.gif

So how do I go from these object files into OpenXcom.exe?

Running gcc *.o -o OpenXcom.exe gave me 'undefined reference' all over the place

main.o:main.cpp:(.text+0x63c): undefined reference to `std::ios_base::Init::Init()'
main.o:main.cpp:(.text+0x658): undefined reference to `std::ios_base::Init::~Init()'
main.o:main.cpp:(.gcc_except_table+0x28): undefined reference to `typeinfo for char*'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o).text+0xa9): undefined reference to `_WinMain@16'
collect2: ld returned 1 exit status


...but that might not be the right way to do it anyway

The .o files mean the Makefile managed to compile all the individual source files (so all the include files are correct), but failed at the final step where it puts everything together into an executable (you didn't show any errors from there) since you mention there isn't one.

The errors you got above are because you're supposed to use g++ not gcc (if that doesn't help you might also need to add -lstdc++ afterwards), make sure you have that properly setup. In any case the Makefile should already include the full proper command.


Also if you don't mind me asking, if you're not familiar with compiling and debugging, why are you trying to compile OpenXcom yourself? There's pre-compiled Downloads freely available if you just wanna try it out.

1757

Programming / Re: Need help with sound files?

« on: July 04, 2010, 09:46:07 pm »

Thanks, I had already looked up the format since it's also used in other Microprose games: https://www.ttdpatch.net/chris_becke_ttdlx.html#hack

The main challenge is having the game properly detect and handle the various game versions (DOS, Windows, etc) and seeing if SDL_mixer supports all those formats. UFO:TTS only accepts the Window version AFAIK.

1758

Programming / Re: [Solved] Detecting if a point is inside a polygon with wrap-around.

« on: July 03, 2010, 04:03:29 am »

Another idea might be that the "point-in-polygon" algorithm is ambiguous on polygon edges. Boy the bugs never stop coming. :rolleyes:

1759

Programming / Compiling on Cygwin

« on: July 03, 2010, 01:16:22 am »

It's still not finding SDL_gfx. These are the steps for compiling it on Linux from the SDL_gfx source folder:

Code: [Select]

./autogen.sh    (optional)
./configure
make
make install
ldconfig

I assume the same works on cygwin. Make sure the library is in /usr/local/lib and the include files are in /usr/local/include (or equivalent in cygwin), they're the ones popping up on the error messages.

1760

Programming / Re: [TASK] Detecting if a point is inside a polygon with wrap-around.

« on: July 02, 2010, 03:07:32 am »

From what I can tell, these "holes" happen in the edges of adjacent polygons, probably because due to rounding errors or approximations or what not the polygons don't actually end up meshing together exactly as they look and you end up with tiny gaps where the test fails.

I wouldn't know where to even begin to fix that though.

1761

Programming / Re: [TASK] Converting cartesian coordinates to polar coordinates

« on: July 02, 2010, 02:43:37 am »

I found the solution! https://en.wikipedia.org/wiki/Orthographic_projection_(cartography)

The functions are frightening but, they work , and now that I got these issues out of the way I can finally work on giving the globe more functionality. Case closed!

1762

Programming / Compiling on Cygwin

« on: July 02, 2010, 02:36:27 am »

Yeah all the errors are from SDL_mixer and SDL_gfx missing, once you sort those out you should be settled.

1763

Suggestions / Re: Configurable alien/civilian counts for terror missions or base assaults?

« on: July 01, 2010, 11:38:18 pm »

On the editor I think probably the best idea would be to make savegame format xml, that way there's no need for any editor (which takes time away from developing the real program: the game...). If XML is too much then at least something text based - property files could do, but they get messy to maintain and read when large. As we all know XML can be and usually is nested so it's very easy to navigate and read. The downside is possibly it's more work to program the saving (there must be some good XML libs for C++ out there though)

People are gonna want editors sooner or later, and if done right they can help and even speed up the development process.

In any case I have been considering using XML for OpenXcom's external data. It's easy to read, easy to write, easy to debug, and I don't wanna be worrying too much about file format and specifications and upgrades and junk like if I go with some binary format.

There are a few C++ XML libraries available, it's just a matter of trying them out.

1764

Suggestions / Re: Selling soliders

« on: July 01, 2010, 04:23:42 am »

But that's cheating, you'd never get any cannon fodder then!

1765

Suggestions / Re: Anti-suggestions

« on: July 01, 2010, 04:15:48 am »

Funny, we recently had the getter/setter discussion brought up at work. Only one developer really think getters and setters are evil, however he has a valid point about boiler plate/cluttered/unreadable code. No matter the size, it's a lot easier to get an overview of the class fields/methods when there's no getters and setters. But I also know that as IDEs get better and better (already actually), overview can be gained more easily by using integrated tools/functions of the IDE than by scrolling through the whole file.

And when you think you don't need to plan for the future (when suddenly you field cannot simply be accessed directly any more) you find yourself with your hands full of other things (don't act  surprised ). Then you wished you didn't need to refactor these things as well as handling every other issue/feature/bug. Lots of things to do seems to cause more errors imho, and too much to do can cause small projects to die (in general). Do correct me if I'm taking this too far, but my point is that it's best to avoid later refactorings when possible. And I think encapsulation is one such thing.

I do hope that with the documentation people don't need to deeply dig around the files to figure out what the code does.

1766

Programming / Compiling on Cygwin

« on: July 01, 2010, 04:11:17 am »

Doesn't look like you installed SDL properly. Check if the libraries are in the respective folders and the paths are right, maybe you forgot a step. These links might help:

https://www.libsdl.org/extras/win32/cygwin/README.txt
https://www.devolution.com/pipermail/sdl/2002-February/042594.html

And remember you won't need just SDL but also SDL_mixer and SDL_gfx.

1767

Suggestions / Re: Couple of (mostly) gameplay related ideas

« on: July 01, 2010, 04:08:39 am »

Nope. I have neither played much of Aftermath or Aftershock. Neither of the games were as good as X-com!

I also never played through UFO:TFTD either. Didn't have the same feel as UFO X-Com...

Wait so are you saying you played them but didn't like them or just didn't play them?

1768

Programming / Re: [TASK] Converting cartesian coordinates to polar coordinates

« on: June 30, 2010, 05:30:13 pm »

I can't say math is exactly my forte either, so so far all the solutions are scaring the crap out of me. But I'll give in and try them if nothing better comes along.

For the curious, this is the current formula:

lat = asin((y - cenY) / r);
lon = asin((x - cenX) / (r * cos(lat))) - rotLon;

Which works fine... as long as you don't rotate the globe vertically (no rotLat in there), that's the real problem.

Typically spherical coordinates (r, lat, lon) convert into cartesian (x, y, z) easily (Wikipedia has the formulas as posted earlier), but in this case the sphere can be rotated which changes the axis, and they need to be flattened for the screen into (x, y). Also the radius is constant since we always want the sphere's surface. But if it's easier for you, you can think of the process as:

(r, lat, lon) -> (x, y, z) -> (x, y)
(r, lat, lon) <- (x, y, z) <- (x, y)

Early on I did try drawing the globe with (x, y, z) through 3D rendering but that just caused a whole lot more problems, so... here we are.

1769

Programming / Compiling on Cygwin

« on: June 30, 2010, 01:29:03 am »

I'm not familiar with cygwin so I don't know why it wouldn't have the CXX variable set by default, but just putting "CXX = g++" yourself at the top of the makefile should fix it.

1770

Programming / Re: [TASK] Detecting if a point is inside a polygon with wrap-around.

« on: June 29, 2010, 05:25:12 pm »

Not had chance to look at the code properly yet, but it looks like you draw the world (Globe.cpp) in polygons after adjusting them on world rotation and zoom, could you not simply perform your mouse check against this polygon set, rather than the initial globe set?

They must be accurate, because you draw them, and you'll know which ones are visible by the backFace variable.

And to save recalculating these, you could create a visibleWorldPolygon list as you're drawing the globe with the real polygon they tie up to, their calculated draw polygon, and any other information

Actually that works pretty well, thanks. I'm shocked I didn't think of it.