Recent Posts

Pages: 1 ... 8 9 [10]
Projects / Re: OP2MapImager Development
« Last post by Hooman on August 05, 2017, 08:02:44 PM »
Upon cursory inspection, it looks like a nice API. Though I tend to shy away from adding external dependencies when they can be avoided. It complicates distribution and compiling.

I suppose that's one of the nice things about the Ruby world, or NodeJS. They have their own language specific packaging and distribution system, and the language core libraries insulate most code from platform considerations, so source is often highly portable between systems. It makes it very easy to incorporate external code, without adding significant difficulty for distribution, compiling, or platform considerations.
Graphics Update / Re: OutpostHD Graphics
« Last post by Hooman on August 05, 2017, 07:52:50 PM »
Indeed, that does look better.

Something I can't ignore now, the tube and robot icons at the bottom of the interface could use a resolution facelift. They look out of place in comparison to the rest.
Projects / Re: OP2Archive Application Development
« Last post by Hooman on August 05, 2017, 07:48:05 PM »
I would love to have a console application like this that could run on Linux.

The whitelist makes sense for the CLM files. The CLM files are only really useful for WAV data, and all data must have the same header parameters. The header is stored once in the CLM. The WAV data is stored in a stripped form.

The VOL files are more generic, and can basically store any kind of data. Though with the way Outpost 2 works, it wouldn't make sense to store the DLLs inside the VOL files, since the Windows loader wouldn't be able to access them there, and that's needed for the levels to load and be playable. They might show up in a list of available games if they were in a VOL, but they wouldn't run. Hence the VOL files might have a blacklist for DLL files. Not sure if you'd really want to enforce this though, or maybe just give a warning higher up in the user interface. Nothing wrong with transporting a DLL in a VOL file, though there is no reason to do this.

Something I've learned from experience, the ADD and REMOVE functionality is a pain to implement in an efficient way, and often not very useful in practice. It might be nice to have them for a sense of completeness, but I think they should get lower implementation priority. The issue is that added files means updating the VOL header, which might cause expansion of the header if there isn't sufficient blank space, and so you're left copying the contents to a later point in the file to make space. In effect, it becomes a CREATE operation, where some of the source files are an existing VOL file. Similarly, if you want to remove a file and don't want dead space in the VOL header, you're again copying data back towards the front, again effectively doing a CREATE operation. Hence why I figure the CREATE and EXTRACT methods are the most useful, and you can get away with just those.

Might consider renaming CONTENTS to LIST. I think that would be more standard.
Projects / Re: OP2MapImager Development
« Last post by leeor_net on August 05, 2017, 07:09:19 PM »
Would it make sense to use something like PhysicsFS to handle the cross-platform file handling? I've used it with great success.

Though it may make more sense to grab the code from TrenchBroom (map editor). It has an abstract filesystem that seems to have everything for Windows/Linux/Mac and it works pretty well once you get the hang of working with it:
General Interest / Re: Installing SDL 2.0.5 on Ubuntu 16.04
« Last post by leeor_net on August 05, 2017, 07:04:31 PM »
Welp, once 2.0.6 goes out I'll likely upgrade.
Graphics Update / Re: OutpostHD Graphics
« Last post by leeor_net on August 05, 2017, 06:57:03 PM »
The construction site in-game with both versions. Upper most is without outlining, bottom is with.

The effect is subtle but it's lightyears better.

Graphics Update / Re: OutpostHD Graphics
« Last post by Hooman on August 05, 2017, 06:21:43 PM »
The effect is less obvious on this one. I suppose the vegetation has less hard edges. Still though, I like it.
Projects / Re: OP2MapImager Development
« Last post by Hooman on August 05, 2017, 06:16:38 PM »
MSVC has an option to export a Makefile. It might be easier to use that than generate a new one by hand. Though the NAS2D makefile is pretty generic, so maybe we could just reuse that.

Teasing out the "#include <windows.h>" will be a bit of a pain. It might be easier if we used regular stream code rather than memory mapped files. Perhaps converting that should be the first step.

I played around with the <experimental/filesystem> code today on Linux. Indeed, the directory_iterator does not like empty path strings. It also doesn't like shell globs, and it doesn't like filenames either. It must be a non-empty folder name.

The filesystem library does handle converting paths between various path/string/char* formats. That could allow some slight simplification to the code. For instance, directory_iterator can take any of those 3 types, which means you don't need to convert a string to a path before calling it. You also don't need to explicitly convert a path to a string before adding it to the vector.

After playing around a bit, I built out my example to be similar to your code, minus the filename extension checks. Here's what it looked like:
Code: [Select]
std::vector<std::string> getFilesFromDirectory(const std::string& dir)
  auto pathStr = dir.length() > 0 ? dir : "./";

  std::vector<std::string> filenames;
  for (auto& entry : fs::directory_iterator(pathStr))

  return filenames;

Oh, and I'd say just assume the folder name passed is an actual folder, and not a file. Trying to strip a filename from the path and use the containing folder is a bit unexpected and could lead to subtle bugs in library use. I'd say just let the path feed through to the directory_iterator, where it will cause an exception if it refers to a file rather than a folder.
Graphics Update / Re: OutpostHD Graphics
« Last post by White Claw on August 05, 2017, 04:45:18 PM »
Out of curiosity, I just did the agridome too. I put these both these files through the same post processing, except one is with the outline and the other is not.

Also, I've included the previous pic that did not go through any post processing.
Graphics Update / Re: OutpostHD Graphics
« Last post by dave_erald on August 05, 2017, 04:35:51 PM »
All though outline on everything would be an extra pain in the arse I think it helps define everything much better, especially considering the size of the graphics that will be on screen
Pages: 1 ... 8 9 [10]