Author Topic: OutpostHD - An Open Source Remake of OUTPOST by Sierra On-Line  (Read 170974 times)

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #50 on: January 11, 2016, 10:34:07 PM »
I saw you were working on the resource management, and I'm curious on your current plan. The 'Update the way the player's usable resources are handled'-task denotes a problem with complexity, but no preferred solution.

Note this in the task description:

Quote
TODO:

Finish fleshing out this thought and create tasks revolving around this problem.

Basically, I started defining the task and ran out of time and steam and had to get to bed for work in the morning.

Part of the problem is that I don't have a good grasp of the actual problem. I haven't fully worked it out in my head but it comes down to one thing; my current implementation is far too simple and worked while I was just starting the game development but it's time to provide a more sophisticated approach to it. I'm too tired tonight to finish 'fleshing out my thoughts' so I probably won't be updating it until tomorrow sometime in the afternoon.

Quote
As I understand it, Agridomes store their own food, which means every Agridome - object has its own counter and behaviour. This is similar to the original, but I'm not sure why this isn't done with a global counter.

Because it's easier to use the internally built objects to manage all of this instead of global counters. I never liked global counters and it doesn't fit the simulation model specified by the original game. Hooman touches on one of the reasons I went with this approach:

Quote from: Hooman
In a way it almost makes more sense to have food stored at agridomes, and potentially losing it if the agridome is destroyed.

Bingo. This is why I went with this design. If you don't manage your structures properly and a structure that contains perishable storage goes inactive for one reason or another, you very well could lose all of that resource. You could even consider regular storage tanks to have 'perishable storage' such that if one was disabled the seals on the containers could leak leading to corrosion and deterioration of the stored resources.

Bulldozing a structure would be handled a little differently (this is where a global counter would make sense); Resources stored within the structure would be pushed into other like structures and whatever remains would effectively be lost. Kinda sucks but that's the way it works in real-life too.

*** Quick though while it's on my mind, if a Storage Tanks structure was destroyed during a disaster, bulldozing its remains should probably provide a higher level of resources than an empty Storage Tanks due to whatever remains of its stored resources could be scavenged. ***

Quote
On storage of resources (and later items in warehouses); the original did that per object. That is the plan, I gather, but I wouldn't have the faintest on how an implementation would look like.

This is the plan. Without going into too much detail, suffice it to say that at least for resources, I use an object that defines a number of resource types. This object can act as either a simple container (e.g., to pass along construction, manufacturing and recycling values as well as required input resources) and can act as a storage container with push/pull functions (e.g., pushing resources into the container and pulling resources from it). These storage management function check the given capacity of said container and will only allow so many resource in.

By using these resource objects within certain structures, implementation is fairly trivial. The logic is contained within the structure itself on what resources get pushed/pulled from storage and the resource objects themselves handle push/pull requests.

Quote
In the original, I would build a tokamak and forget about my energy needs. Energy was implemented, right?

Pretty much. At this point the only energy provided is the meager 50 units by the SEED Power Facility. I haven't yet implemented the Tokamak. I'm not sure exactly when I will but probably after I get the storage situation finished and cleaned up.

Quote
The master report was a bit odd, but it could be made useful.

This is true, but simply cloning it and improving it to me is a waste of time. Why fix something that's badly designed when you can redesign something superior? I'm not a great UI designer by any stretch so any thoughts on this front would be helpful especially any mockups. Keeping in mind that I want to kind of stray away from the modified Windows 3.1 GUI approach.


Offline Galactic

  • Administrator
  • Full Member
  • *****
  • Posts: 144
    • http://www.konker.net
Re: OutpostHD - An Outpost Redesign
« Reply #51 on: January 20, 2016, 01:50:33 PM »
Looking good so far, keep up the good work.
Take me to your leader! I bare the claws of a corndog.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #52 on: January 22, 2016, 08:38:47 AM »
For those of you who don't want to download the game yet because it's technically not 'playable', here's a short video demonstrating some of the various aspects of the game.

« Last Edit: August 11, 2017, 01:42:32 AM by leeor_net »

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1015
Re: OutpostHD - An Outpost Redesign
« Reply #53 on: January 22, 2016, 12:43:46 PM »
Leeor,

I'm excited about this project. I enjoyed playing through Outpost 1.5 a few times years ago.

Glad to see the progress and nice video.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #54 on: January 22, 2016, 05:01:48 PM »
Thank ya!

I'm not sure how to upload in higher resolution... perhaps I just need to set it to full screen and record it that way.

Still pushing a long. The last few weeks have been exhausting at work so I've pushed it to the back burner because of how tired I've been but I have a weekend coming up and then 6 days off from work so I hope to have storage and resource management figured out and probably saving/loading figured out by next the end of next week.

After that it's truck routing and research trees!

Hooman, if you're up for it maybe you could help me figure out some math for the population model? I keep going back to a full-blown population simulation and that seems like total overkill for this game.

Offline Charles_Bronson

  • Newbie
  • *
  • Posts: 5
Re: OutpostHD - An Outpost Redesign
« Reply #55 on: December 14, 2016, 01:58:22 PM »
thats good progress! Really nice work done!

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #56 on: December 14, 2016, 02:45:37 PM »
Thanks! Been at it for a year and have a lot to show for myself. Goof has been super helpful too especially with developing a lot of the structures. Would feel very bare without his help.

BTW, I see it's been what, almost 8 years since you posted last? Welcome back!

Offline lhark

  • Newbie
  • *
  • Posts: 11
Re: OutpostHD - An Outpost Redesign
« Reply #57 on: June 10, 2017, 11:23:45 PM »
Hello everyone, i just discovered this forum and the outpostHD project.
Outpost has a big place in my childhood memories and it warms my heart to see people are still passionate about it :)

Anyways, being a big free software supporter, i tried (and succeeded) building OutpostHD and it's underlying API NAS2D on linux.
It runs reasonably well after a few bugfixes.

I've already submitted a pull-request on github for NAS2D, but i don't know to do the same with the OutpostHD svn repo :/
Do i need to provide a patchfile ? do i get push access to the repo ? to a feature branch ?
I must confess i'm not that familiar with svn.

Once again, thank you for the great work you put into this project :)

Offline Vagabond

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1015
Re: OutpostHD - An Outpost Redesign
« Reply #58 on: June 11, 2017, 12:40:35 AM »
Ihark,

The repository is read only until an admin like leeor_net gives you write access. Just keeps people from making a mess of it. It sounds like you already found the repo location to download the source code.

We have some limited, basic info on Subversion in the wiki here: http://wiki.outpost2.net/doku.php?id=opu:repository.

I'm glad to hear the code compiled without too much difficulty on Linux.

-Brett

Offline lhark

  • Newbie
  • *
  • Posts: 11
Re: OutpostHD - An Outpost Redesign
« Reply #59 on: June 11, 2017, 11:53:57 PM »
Thankks for the answer :)

I guess I'll wait for an answer by leeor_net then.

By the way I also updated OutpostHD to NAS2D v1.4.2 (that had absolutely nothing to do with me not realising
that outposthd was not using the last release when I started ^^).

EDIT : In fact the only part that wasn't already v1.4.2-compatible was ui_builder which is not really part of the game
« Last Edit: June 12, 2017, 12:01:10 AM by lhark »

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #60 on: June 13, 2017, 10:22:57 PM »
I actually don't have admin access to the SVN -- that's something Leviathan handles (can get a hold of him via IRC).

If you'd like you can submit a patch file for OutpostHD via PM (or send me a message if it won't allow you to attach the file(s) and I'll give you my e-mail address).

Will look at the pull request for NAS2D -- I've been visiting my parents in NJ for the last few days so I've been unable to do a whole lot with it.

And thank you for taking care of the Linux parts! I don't have a linux installation but when I was building The Legend of Mazzeroth (LoM, as in the code base for the file system) the base code worked well.

Once you get write access to the SVN from Leviathan, if you're interested in poking around the OutpostHD code, by all means! I could use a bit of help -- I was starting to work on it again last week but ended up being contracted to build some tooling for a new project so I had to put it down.

Anyway, plan over the next couple of weeks is to implement population requirements check and then move on to the product production and storage implentation. See the Redmine roadmap for the general plan.

Thanks for updating to the latest version of NAS2D! I never got around to it.

I kinda forgot about UI_Builder after I realized I'd have to build a lot more than really cared to do at the time. I should pick that project back up and just build the layout interpreter file and just make my life a lot easier. UI coding can be miserable -_-
« Last Edit: June 13, 2017, 10:24:54 PM by leeor_net »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: OutpostHD - An Outpost Redesign
« Reply #61 on: June 25, 2017, 01:17:49 PM »
I just tried compiling the source on Linux and got the following errors:
Code: [Select]
outposthd$ make
/bin/sh: 2: [: src/Map/: unexpected operator
/bin/sh: 2: [: src/Map/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/Things/Structures/: unexpected operator
/bin/sh: 2: [: src/Things/Structures/: unexpected operator
/bin/sh: 2: [: src/Things/Robots/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/Core/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/UI/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/States/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
/bin/sh: 2: [: src/Population/: unexpected operator
/bin/sh: 2: [: src/: unexpected operator
make: *** No rule to make target 'API/NAS2D/lib/libnas2d.a', needed by 'bin/OPHD'.  Stop.

Offline lhark

  • Newbie
  • *
  • Posts: 11
Re: OutpostHD - An Outpost Redesign
« Reply #62 on: June 25, 2017, 10:59:25 PM »
Ok, that's weird, I can only reproduce half of your problem. On the last line it complains about a missing library and is right about it : leeor_net forgot to include it with the rest of my patch.

If you want, you can compile the missing library yourself leeor_net accepted my pull request for https://github.com/lhark/nas2d-core.

As for the other problems, I can only that my shell scripting wasn't fully POSIX compliant :/

Maybe try the following fix on line 24 of the Makefile

-   if [ "$${dirs#*ui_builder/}" == "$$dirs" ]; \
+   if [ "$${dirs#*ui_builder/}" = "$$dirs" ]; \

Also, leeor_net, you should have a look at line 436 in src/States/GameState.cpp, I think you have a bug : the string sLevel becomes SLevels at one point without any new declaration.
« Last Edit: June 25, 2017, 11:01:13 PM by lhark »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: OutpostHD - An Outpost Redesign
« Reply #63 on: June 26, 2017, 03:17:03 AM »
Thanks, removing one of the equal signs solved that problem.

I needed to install the SDL2 dependency (using Ubuntu):
Code: [Select]
sudo apt install libsdl2-dev

I also needed to add the "-std=c++11" flag to CFLAGS in the Makefile:
Code: [Select]
-CFLAGS         =       -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
+CFLAGS         =       -std=c++11 -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
That removed a ton of errors and warnings about "nullptr".

I see a few errors about "sLevels", as stated above. I renamed the occurrences to "sLevel" just to see if it would compile. No other compile errors, though lots of warnings about non-void functions having no return statement (they are dummy stubs), and a few typedefs being locally defined but unused.

And of course the error stated above was still present:
Code: [Select]
make: *** No rule to make target 'API/NAS2D/lib/libnas2d.a', needed by 'bin/OPHD'.  Stop.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #64 on: June 26, 2017, 01:23:52 PM »
Also, leeor_net, you should have a look at line 436 in src/States/GameState.cpp, I think you have a bug : the string sLevel becomes SLevels at one point without any new declaration.

Seems to be an artifact of merging some changes. Have to admit, I'm finding Git to be far better at merging than SVN.

I'm also seeing that the code itself is wrong, again probably due to changes made between several commits between me and Goof.

Offline lhark

  • Newbie
  • *
  • Posts: 11
Re: OutpostHD - An Outpost Redesign
« Reply #65 on: June 28, 2017, 01:14:25 AM »
I would also be in favor of a migration from SVN to git, but I don't think my voice is worth anything yet^^

About the makefile, I completly rewrote it in order to have some dependency management: before, if you where to change just one header file,
the whole project would basically need to be rebuilt. I did a single test with GameState.h and got a five fold improvement on the build speed :

Code: [Select]
new makefile: make                  6.31s  user 0.44s system 99% cpu 6.747 total
old makefile: make -f Makefile.old  32.60s user 2.31s system 99% cpu 34.920 total

I also needed to add the "-std=c++11" flag to CFLAGS in the Makefile:
Code: [Select]
-CFLAGS         =       -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
+CFLAGS         =       -std=c++11 -g -Wall -I./API/NAS2D/include `sdl-config --cflags`
That removed a ton of errors and warnings about "nullptr".
Thank you for the tip, I didn't really focus on reducing the volume of warnings ^^

By the way, is there an easier way for me to push this modification now that I have access to the redmine ?

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: OutpostHD - An Outpost Redesign
« Reply #66 on: June 29, 2017, 01:20:25 PM »
Nice job on the compile time improvements. That's a huge win for iterative development.

I think the "nullptr" issue led to actual errors since they were showing up as undefined identifiers before. Though some messages were warnings. Different systems might have different default language standards.


Slightly unrelated, but I use git-svn so I can download the changes into a git repository and work with the code using git. Using git at the source could simplify that slightly.

Offline Goof

  • Jr. Member
  • **
  • Posts: 57
Re: OutpostHD - An Outpost Redesign
« Reply #67 on: July 08, 2017, 07:06:53 AM »
Also, leeor_net, you should have a look at line 436 in src/States/GameState.cpp, I think you have a bug : the string sLevel becomes SLevels at one point without any new declaration.

Seems to be an artifact of merging some changes. Have to admit, I'm finding Git to be far better at merging than SVN.

I'm also seeing that the code itself is wrong, again probably due to changes made between several commits between me and Goof.

Yes it seems to be a merge mistake.
R228 was good with the new code and R229 was messy with part of the old code.
It should be right on live SVN version now.

I also add the navigation thru depth levels with First / End / Page Up / Page Down  keys.
Since, for me, it seems to be obvious shortcuts.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: OutpostHD - An Outpost Redesign
« Reply #68 on: July 10, 2017, 12:39:27 AM »
I made another attempt to compile things on Ubuntu. Seems a few more updates are needed.

I pushed the changes to the Makefile for the = versus == POSIX compliance thing, and added the -std=c++11 flag.

I found additional dependencies needed to be installed outside of just the core SDL2 library. The core SDL library (libsdl2-dev) is needed for the sdl-config utility used in the Makefile. Additionally, other libraries are needed by the compiler. The full install set for OutpostHD is:
Code: [Select]
sudo apt install libsdl2-dev libsdl2-image-dev libsdl2-mixer-dev libsdl2-ttf-dev libphysfs-dev libglew-dev

I'm thinking a rule could be added to the Makefile to install these.

I looked into removing some of the warnings. It looks like there are attempts at compile time errors within templates using the familiar negative array index hack. I'm thinking this should be changed to the new static_assert introduced in c++11. Here's an example:
Code: [Select]
-       typedef int ERROR_CantUseHorrible_cast[sizeof(InputClass) == sizeof(u) && sizeof(InputClass) == sizeof(OutputClass) ? 1 : -1];
+       static_assert(sizeof(InputClass) != sizeof(u) || sizeof(InputClass) != sizeof(OutputClass), "Can't use horrible cast");
Note the negated condition. The code with the negative array index hack gives the condition for passing the check, rather than failing the check. The conditions would need to be rewritten as if the "1 : -1" was reversed to "-1 : 1".

There was one odd example I'm not so sure about:
Code: [Select]
-               typedef char ERROR_Unsupported_member_function_pointer_on_this_compiler[N-100];
+               static_assert(N < 100, "Unsupported member function pointer on this compiler");
What is going on with that check against 100? Seems like a hack. What is it doing, and is there a better way to do that?

I noticed a few sections of code similar to the following:
Code: [Select]
	AiVoiceNotifier() {}; // Explicitely Declared Private
AiVoiceNotifier(const AiVoiceNotifier&) {}; // Explicitely Declared Private
AiVoiceNotifier& operator=(const AiVoiceNotifier&) {}; // Explicitely Declared Private
The operator= caused warnings due to no return value from a non-void function. Removing the "{}" removed the warning. It's not called, so not having a body won't produce an error. But this gets more to the heart of the idiom used here. As the function is explicitly being declared private to prevent its use, it would be more clear to use the "= deleted;" syntax introduced in c++11. This would apply to all 3 methods as well, and would give more clear intent.

Another missing return from a non-void function was:
Code: [Select]
int incrementFuelCellAge() { mFuelCellAge++; }
I'm thinking just change the return type to void. I don't think it needs to return a value. I also noticed it's not called anywhere. Another thought, should the return value actually be desired, it might make more sense to use the pre-increment operator: "return ++mFuelCellAge;". That would return the value after the increment, rather than what the value was before the increment.


It took me a while to realize NAS2D was a separate download. The folder in OutpostHD is really just the development headers. This of course means a new set of challenges.

The Makefile for NAS2D also needed to have the "-std=c++11" flag set.

I needed to install another library:
Code: [Select]
sudo apt install glee-dev

There was one include I needed to update in src/Renderer/OGL_Renderer.cpp:
Code: [Select]
-#include "SDL_image.h"
+#include "SDL2/SDL_image.h"

I still get some errors with NAS2D in src/Renderer/OGL_Renderer.cpp:
Code: [Select]
src/Renderer/OGL_Renderer.cpp: In member function ‘virtual void NAS2D::OGL_Renderer::fullscreen(bool, bool)’:
src/Renderer/OGL_Renderer.cpp:494:44: error: ‘SDL_SetWindowResizable’ was not declared in this scope
   SDL_SetWindowResizable(_WINDOW, SDL_FALSE);
                                            ^
src/Renderer/OGL_Renderer.cpp: In member function ‘virtual void NAS2D::OGL_Renderer::resizeable(bool)’:
src/Renderer/OGL_Renderer.cpp:518:59: error: ‘SDL_SetWindowResizable’ was not declared in this scope
  SDL_SetWindowResizable(_WINDOW, static_cast<SDL_bool>(_r));
                                                           ^
Makefile:22: recipe for target 'obj/Renderer/OGL_Renderer.o' failed

According to the SDL docs:
Quote
This function is available since SDL 2.0.5.

According to the output of apt install:
Code: [Select]
libsdl2-dev is already the newest version (2.0.4+dfsg1-2ubuntu2).

Looks like the packages available for Ubuntu are too old to contain this function.

I'm stopping here for now.
« Last Edit: July 10, 2017, 12:43:28 AM by Hooman »

Offline lhark

  • Newbie
  • *
  • Posts: 11
Re: OutpostHD - An Outpost Redesign
« Reply #69 on: July 10, 2017, 01:38:43 AM »
Wow, very nice and in depth test.

Sorry about the dependency, I didn't write them down anywhere, and it wouldn't have been usefull to you anyway as I'm running archlinux.
However, I don't think that adding the dependency install to the makefile is a good practice or even a good idea. You would need to support
all the different packet managers that are out there (apt, pacman, yum to cite just a few of them).

I reckon a better idea would be mentionning that in the README.

About NAS2D, theorically, if we ship libnas2d.a with the rest of the windows libraries, it should work. But seeing as it's only compiled for
amd64 right now, that wouldn't be really portable.

As for the include in NAS2D/src/Renderer/OGL_Renderer.cpp, I didn't get any issue with it.
It might have something to do with the fact I have both versions of the SDL installed on my machine though.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: OutpostHD - An Outpost Redesign
« Reply #70 on: July 10, 2017, 03:31:24 AM »
Quote
As for the include in NAS2D/src/Renderer/OGL_Renderer.cpp, I didn't get any issue with it.
It might have something to do with the fact I have both versions of the SDL installed on my machine though.

Ahh, that could be it. Interesting, if there is a mixed version compile happening. I mentioned it precisely because I thought it was odd nobody else had a problem. I figured there must be some configuration where that header file worked, and if I changed it, I might break someone else's setup on another platform.

Well, I suppose one way to find out, is to "fix" it, and see if anybody complains. ;)

Though now that I check, I also have libsdl-dev installed, which is version 1.2.15. Perhaps one of the other packages is involved, or it is a platform difference.

Quote
Sorry about the dependency, I didn't write them down anywhere, and it wouldn't have been usefull to you anyway as I'm running archlinux.
However, I don't think that adding the dependency install to the makefile is a good practice or even a good idea. You would need to support
all the different packet managers that are out there (apt, pacman, yum to cite just a few of them).

I reckon a better idea would be mentionning that in the README.
I was wondering what version of Linux you used.

I was also thinking the package names will differ by platform, as will the package manager. Still, I think dependency installation can still make sense in a Makefile as an independent rule, similar to the .PHONY rule for "clean". Perhaps a rule name "install-deps-ubuntu". Could throw in a rule for Arch Linux too.

The rules might not work for everyone, but I figure it's just as easy to add a Makefile rule as it is to document that in a readme, and for the few people that it helps, it's quite a convenience.

Might even be possible to have a generic "install-deps" rule that detects the distro and passes control to the right place.


Hey leeor_net, how come NAS2D is up on GitHub, while OutpostHD is hosted on the OPU SVN server?

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: OutpostHD - An Outpost Redesign
« Reply #71 on: July 13, 2017, 10:46:27 PM »
Why does NAD2D use both GLee and Glew? From what I understand, they are both OpenGL extension loader libraries. They seem to do the same thing. Indeed, I've read that although you can use both in the same project, you can't include both headers from the same compilation unit.

I've also found a few places that suggest GLee is no longer maintained, and hasn't been in years. Of note is the open bug on the GLee SourceForge project page, which never got a reply:
Quote
We're going to be restructuring the SDK area of www.opengl.org and, since glee is listed there, wanted to ask what the current state of the project is, and if it should continue to be listed as a current resource. The sourceforge project seems pretty dead by casual inspection.

The use of GLee seems to be restricted to: src/Resources/Shader.cpp
« Last Edit: July 13, 2017, 10:49:58 PM by Hooman »

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #72 on: July 18, 2017, 10:37:21 AM »
It's not supposed to. I originally used GLEE but after that was discontinued I switched to GLEW. Anything from GLEE can be considered legacy and removed.

As a note, Shader.cpp contains... very old code that hasn't been updated in a long time. But, since I've learned a lot more about shaders I'm probably going to start updating that again soon.

Anyway, in the mean time GLEE references can be killed.
« Last Edit: July 18, 2017, 10:39:27 AM by leeor_net »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 4955
Re: OutpostHD - An Outpost Redesign
« Reply #73 on: July 21, 2017, 03:53:19 AM »
Question for lhark:
How come you used .PRECIOUS in the makefile? Is there a reason to use this over .SECONDARY?
Code: [Select]
$(DEPDIR)/%.d: ;
.PRECIOUS: $(DEPDIR)/%.d

I read the GNU Make special targets page:
Quote
.PRECIOUS
The targets which .PRECIOUS depends on are given the following special treatment: if make is killed or interrupted during the execution of their recipes, the target is not deleted. See Interrupting or Killing make. Also, if the target is an intermediate file, it will not be deleted after it is no longer needed, as is normally done. See Chains of Implicit Rules. In this latter respect it overlaps with the .SECONDARY special target.

You can also list the target pattern of an implicit rule (such as ‘%.o’) as a prerequisite file of the special target .PRECIOUS to preserve intermediate files created by rules whose target patterns match that file’s name.

...

.SECONDARY
The targets which .SECONDARY depends on are treated as intermediate files, except that they are never automatically deleted. See Chains of Implicit Rules.

.SECONDARY with no prerequisites causes all targets to be treated as secondary (i.e., no target is removed because it is considered intermediate).


On another topic, I read somewhere that #include lines should omit the "SDL2" directory, and instead add a -I flag to include the SDL2 directory in the include search path. The main reasoning seems to be different install paths and hierarchies on different platforms, or with different setups, such as using a local install rather than a system install. By keeping that out of the source, and in the makefile, it's supposed to make it easier to compile in different environments.

Personally I feel the suggestion to omit directory names is a bit backwards from most other languages. Most other languages have a defined directory layout for packages, and a mapping between package imports and their directory. Having the package/directory in the source makes it very clear what version you're expecting, and makes sure you don't accidentally grab the wrong import.

In this case, specifying "SDL2/SDL.h" rather than just "SDL.h" ensures you're compiling against version 2, and not against version 1. However, there seems to be a lack of a well defined standard in C++ about where package header files go. Indeed, the current source files have a number of platform specific defines to include the right header files. Perhaps the includes should be normalized to not include the directory name, and the build scripts updated to include the necessary include directories? If done correctly, a lot of the platform specific checks could be eliminated.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 2352
  • OPHD Lead Developer
    • LairWorks Entertainment
Re: OutpostHD - An Outpost Redesign
« Reply #74 on: July 21, 2017, 06:47:12 AM »
As a side note, I've since updated NAS2D -- fixed a bug in one function that Goof pointed out and I've also commented out all of the shader code.