Author Topic: Remote Pair Programming  (Read 999 times)

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3857
Re: Remote Pair Programming
« Reply #25 on: May 29, 2017, 07:15:49 AM »
Yes, TeamViewer worked pretty good. Lag was minimal, mostly only noticeable when I was trying to scroll to a specific point in a file, and even then not all that much.

TeamViewer can be used with or without registering an account with TeamViewer. It's easiest if you register an account with TeamViewer using your email address, and then add the other person to your friend's list. That allows you to easily send a request to join them using their computer, which they can accept or deny. There is another method we tried first, which didn't require registering an account with TeamViewer, and involved sharing access codes, similar to a username and password. Beware though that these access codes let someone join without prompting to accept on the host end. This method seems to be useful for accessing your own computer remotely, so you can join while it's unattended. To aid this feature, TeamViewer is also set to launch at startup by default when you install it. If you're security conscious, you might want to change that option, and perhaps not use the access code sharing method.

There was some trouble initially getting TeamViewer to use the mic on my end. It was only transmitting audio one way at first. We tried using Discord for the audio, but since TeamViewer was still transmitting audio one direction, including what Discord was playing, it caused my voice to echo back 1 or 2 words later. Very hard to speak clearly when you hear a delayed echo of yourself. It messes with your brain, confuses you, and makes you slur your words trying to compensate. Try it sometime, it's weird and fascinating. I eventually got the mic to work, though in hindsight I wonder if it may have had something to do with closing Skype first.

Chrome Remote Desktop did not connect for us. It failed during the connection attempt, after alerting the other side.

----

Stated project goals seem quite good. I've wanted something that can make scaled images of maps for a long time.

More generally, I would like new code to allow for easy cross platform extraction of game resources. Many of the current tools are Windows specific, and have extra dependencies that need to be installed. I'd like standalone utilities available with minimal dependencies, to ensure stuff just works wherever. Ultimately, I want to make it easy for anyone to access game resources, either through library code, or without needing to program anything, in easy to use standard formats. That should allow people to do whatever they want with the resources, creating new utilities, editing resources, or extracting resources for use in new projects or remakes. I'm hoping easy access to the game resources might spur on new projects.

Offline Vagabond

  • Sr. Member
  • ****
  • Posts: 388
Re: Remote Pair Programming
« Reply #26 on: May 29, 2017, 07:22:17 PM »
Just finished pushing OP2MapImager code into the repository at: \Outpost2SVN\GameResources\OP2MapImager.

I separated the code into 2 more files: MapFileReader.h and MapData.h. I pushed all the code to parse the map file into a class called MapFileReader. All methods except void ReadMapData(MapData& mapData, string filename) are encapsulated as private. I added documentation to most members of MapData.h since it is a very important public structure. Those comments should be proofed by someone else. I'm still not an expert at the contents of the map file.

I also added helper functions to return the map width in non base 2 log form and the tile set filename as a std::string (the parsed data does not include a '\0' terminator). This way an end user doesn't have to deal with odd implementation details, but the data in the MapData struct still represents the MapFile content.



If anyone wants to continue on the project, I am available on Sunday, 4 June at Midnight GMT - 5 June 3AM GMT. That is Sunday 7-10PM Eastern US Time. If this is too early, we could also push later in the day. Looking at about a 3 hour chunk of time for the pairing.

I'll probably discontinue working on the project until then with the possible exception of researching a library for image manipulation or minor fixes if anyone notices dumb things in the code in the repo over the work week.

I'm happy to work with Hooman again or if someone else wants to jump in, myself or Hooman could rotate out? Or if there are 4 of us, we could pair on 2 different projects.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3857
Re: Remote Pair Programming
« Reply #27 on: May 31, 2017, 03:54:39 AM »
Your convenience methods sound like a good idea.

I'd be happy to pair with you again. I've noted it in my calendar.

Offline Vagabond

  • Sr. Member
  • ****
  • Posts: 388
Re: Remote Pair Programming
« Reply #28 on: June 01, 2017, 01:41:06 AM »
It looks like a console VOL decompress/compressor already exists in the repository (Outpost2SVN\GameResources\VolDecompress). The code looks clean and easy to read. While reviewing it, I realized void main(int argc, char **argv) contains a pointer to a pointer (**)... I had to look that up.

Anyways, the program is incomplete:

Code: [Select]
void OutputUsageMessage()
{
// Print usage info
cout << endl;
cout << "OP2Decomp - The Outpost 2 decompressor/unpacker for VOL and CLM files" << endl;
cout << endl;
cout << "To extract all files from an archive:" << endl;
cout << "OP2Decomp [filename]" << endl;
cout << endl;
cout << "To pack a list of files into an archive:" << endl;
cout << "... not sure on syntax yet (but code exists!)" << endl;
}
It looks like at some point we should probably finish up the console interface of the application and separate the backend logic into a library project. Then the OP2MapImager could just reuse this VOL library instead of re-doing all the VOL decompress code. It looks like a lot of work went into writing the code, including a Huffman Tree for compression. I also had to lookup what a Huffman Tree is.




More generally, I would like new code to allow for easy cross platform extraction of game resources. Many of the current tools are Windows specific, and have extra dependencies that need to be installed. I'd like standalone utilities available with minimal dependencies, to ensure stuff just works wherever. Ultimately, I want to make it easy for anyone to access game resources, either through library code, or without needing to program anything, in easy to use standard formats. That should allow people to do whatever they want with the resources, creating new utilities, editing resources, or extracting resources for use in new projects or remakes. I'm hoping easy access to the game resources might spur on new projects.


Since we are currently working in Visual Studio, I think the code can only be easily compiled for use in Windows. I'm guessing it should be pretty easy to use through Wine on Linux though?

If we keep the applications simple enough and generic, the files could be loaded into a new solution in an IDE that supports a Linux or Macintosh compiler and then compiled for use. Is that sufficient?

I don't know a lot about other compilers, but if we used something else like Vim or EMACs, would that be trivial to switch targets and compile natively for Windows, Linux, or Macintosh. Besides a couple of Code::Blocks projects, I believe everything in the repo right now is Visual Studio.

I'm not well versed on cross platform development.
« Last Edit: June 01, 2017, 01:54:05 AM by Vagabond »

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3857
Re: Remote Pair Programming
« Reply #29 on: June 02, 2017, 12:15:16 AM »
Code: [Select]
void main(int argc, char **argv)
The argc is the number (count) of command line arguments. The argv is the actual command line arguments. It is an array of strings, where each string is an array of chars. As each array decays to a pointer, it's simply written as a double pointer.

It might not be a bad idea to finish that project. I'd forgotten about that note about not having a command line interface to repack VOL files.

It's possible the compiled code might run on Linux under Wine. However, the code can't currently be compiled under Linux, which creates a significant barrier to development for anyone using Linux. You could run a compiler in a VM, but this is still an extra step that doesn't integrate well with tooling.

The problem doesn't come from using Visual Studio. That's just an IDE, which is really just a glorified text editor. The problem comes from the code using platform specific features through direct API calls.

The files with platform specific code are CArchiveFile, CVolFile, and CClmFile. Within them, you'll notice "#include <windows.h>". They also make use of the Windows specific HANDLE type, for referencing file handles, along with associated functions: CreateFileA, MoveFileA, DeleteFileA, CreateFileMapping, MapViewOfFile, and WriteFile. To make the code platform independent, those files would need to be rewritten to replace those occurrences.

The files CAdaptHuffTree, CHuffLZ, CBitStream, and even Main.cpp don't appear to use platform specific features themselves, they just rely on the other files that do.

Then there's getting it all to compile in one easy command on a new platform. You'd need a replacement for the Visual Studio project file that basically says what your sources files are, and how to feed them through a compiler. Typically this is done with a Makefile. This is a small issue. Visual Studio already has a built in tool to output a suitable Makefile.
« Last Edit: June 02, 2017, 12:18:35 AM by Hooman »

Offline Vagabond

  • Sr. Member
  • ****
  • Posts: 388
Re: Remote Pair Programming
« Reply #30 on: June 04, 2017, 10:58:16 AM »
@Hooman, I'm still on for the pair programming in about 6 hours (4 June at Midnight GMT - 5 June 3AM GMT). I'll be on Discord and in the OP2 Quake chat room.



I did a little research on cross platform development. This article is about 7-8 years old but I liked some of the advice in it: https://www.backblaze.com/blog/10-rules-for-how-to-write-cross-platform-code/. I also spent a little time reading an overview of makefiles.

The author recommends writing your own functions for file access and other platform specific code and isolate it to a specific areas in your code. You can then control the content of the file access functions using pre-proccessor directives like #ifdef _WIN32. So you could use the native operating system code for each supported operating system in the function. This would isolate all your platform specific code to one or a couple of files and allow you to build with the same .h/.cpp files on any supported platform.

I think a similar option would be to create an interface for the platform specific code functions and then write classes to fulfill the interfaces for each supported platform. You could then use a pre-processor directive to actually load the proper class fulfilling the interface. I have never attempted interfaces in C++, but my understanding is there is no built in support, so you have to sort of hack it.

Offline Vagabond

  • Sr. Member
  • ****
  • Posts: 388
Re: Remote Pair Programming
« Reply #31 on: June 09, 2017, 10:58:57 PM »
Next session will be this Sunday, 11 June at Midnight GMT - 5 June 3AM GMT (same time as last weekend). That is Sunday 7-10PM Eastern US Time. Looking at about a 3 hour chunk of time. Sorry for the late post.

Looks like the plan will be getting the Outpost 2 specific BMP files loaded into memory, then passing the BMP off to FreeImage for crunching. If time remains, we can work on getting FreeImage to actually scale down an image and paste it into a larger imager.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3857
Re: Remote Pair Programming
« Reply #32 on: June 10, 2017, 08:07:52 AM »
Sounds good. Might take a bit of time to handle the custom image format. I should probably review the existing code since it's been a few years.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3857
Re: Remote Pair Programming
« Reply #33 on: June 25, 2017, 11:54:13 AM »
@Vagabond: I'm back from my short banishment from the internet. I'll have to look through your updates to see how things sit, though it looks like you've basically got it working.

@leeor_net: I want to know how outposthd development is going, and what your process is like. Now that some patches have been submitted for the code to compile on Linux, there is little excuse not to look more into your project.


On another note, I've been wanting to experiment with Ruby/Rails and websockets. Anyone interested in some exploratory work? I'm thinking of a test project such as a simple chat room, just to see how the technology fits together.

Offline leeor_net

  • Administrator
  • Hero Member
  • *****
  • Posts: 1534
    • LairWorks Entertainment
Re: Remote Pair Programming
« Reply #34 on: June 26, 2017, 11:38:51 AM »
I've been focused on another project at the moment, one that brings in a small amount of income but nonetheless is income.

Would def like to continue work on OPHD at some point though.
- Leeor
LairWorks Entertainment

Titanum UFO's

Offline Vagabond

  • Sr. Member
  • ****
  • Posts: 388
Re: Remote Pair Programming
« Reply #35 on: June 27, 2017, 01:39:11 AM »
Hooman,

Yes, the OP2MapImager is functioning! Right now I am currently looking through your VOL Decompress code. It looks like I can adopt it without too much trouble to allow the OP2MapImager to search VOL archives in a directory for the given map and wells. I can structure the program to look first in the directory itself and then through the vol files until a map or well with the given name is found. This way a loose file in the directory takes precedent over a file archived in a VOL.

I'll want to modify your VOL decompress code a little to allow sending a list of all filenames within the VOL among other things. How sensitive are you to me mucking around in the VOL decompress code? I would like to make a branch preserving what you have stable. (I've never done this in SVN, so hopefully fairly straightforward).

The other piece is loading the non-standard Outpost 2 TileSet BMPs into memory. I've designed a function within the MapImager class that accepts the raw bits instead of loading a file from the hard drive. I could use some help getting the BMPs into memory. Without help here, I will probably just distribute the modified BMP files with the application instead of hacking my way through the process.

Feel free to work on the MapImager as you see fit. I'm being good about uploading my progress regularly to SVN and checking for updates to keep from getting out of sync with any possible work you do.

Depending on where we want to draw the line on adding new features, the OP2MapImager should be ready for initial release within 2-3 weeks (hopefully????). There is still a lot of cleanup that should be done to the code.

I printed off some talking points about what D is supposed to be and an interview article with one of the 2 creators to read through. It is currently on the TIOBE index as number 22, 1.416% (https://www.tiobe.com/tiobe-index/). Just starting to warm up to trying something in the language and you are already off to Ruby on Rails!

Anyways, I will probably not be available again for pair programming until around middle of August. Once we are in August or my schedule changes earlier then expected, I will see where everyone stands and what the interests are.

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3857
Re: Remote Pair Programming
« Reply #36 on: June 29, 2017, 08:42:47 AM »
Your precedence rules are correct, in that the game looks for loose files before checking the contents of the VOL files.

Quote
I'll want to modify your VOL decompress code a little to allow sending a list of all filenames within the VOL among other things.
Why?

My gut feeling is there's probably a better design to whatever it is you're trying to accomplish, though I'm not clear on what it is you're trying to accomplish.

Quote
The other piece is loading the non-standard Outpost 2 TileSet BMPs into memory. I've designed a function within the MapImager class that accepts the raw bits instead of loading a file from the hard drive. I could use some help getting the BMPs into memory. Without help here, I will probably just distribute the modified BMP files with the application instead of hacking my way through the process.
Very practical set of choices here. Not just in code design, but also in project management, and how the code will evolve.


We can cover some D in a future session if you'd like. Ruby as well. Maybe throw in some JavaScript at some point too. I have multiple project ideas. But, all in good time. Let's try to finish what we've started first before getting too carried away.