Operational Warfare Developer's Blog

Developer's blog for the Operational Art of War series

About the author

Ralph Trickey maintains TOAW III
I set this Blog up for fun, and for my own edication! Nothing is guaranteed, it's for my own use primarily, so even if I say that something may happen with the next release, please understand that it may not. I plan to post random thoughts and other things like that at random times here. I don't have a specific plan for what will be here.
E-mail me Send mail

Recent posts

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2015

I HATE LIBCURL!!!!

Darn it, why do people insist on creating one entrypoint and passing in 27 different possible parameters.

I just spent 12 hours finding out that I needed to typecast the int to a long long or I'd get memory faults when it tried to read a terabyte of data or some such.

 


Posted by Ralph Trickey on Friday, May 08, 2015 9:55 PM
Permalink | Comments (0) | Post RSSRSS comment feed

3 steps forward, two steps back.

Well, that was 'fun' After all that work it worked fine on my machine and failed on everyone else's.

So, rewrite everything in libcurl. 

Aside from all the side alleys filled with gangs of thugs, it wasn't too bad.

First there was the calling convention. The 'norm' is cdecl. I was using fastcall. Instead of a reasonable error like 'dude, you've got the wrong calling convention, I got a much more accurate alnd less useful 'function not found.' Once I fixed all those, I got the even more useful "Invalid read from memory '00001'.

Then there was the MFC party. It wasn't a simple, Dude, you need to link the MFC library first, it was 'Duplicate functions'

Good luck googling that one!

Finally I had to toss the cookies. Don't ask me why, but I couldn't just leave the cookies alone, I had read them, remake the exact same cookie, then it was happy.

Anyway, as long as I don't need SSL, I think I can read/write HTML. At least the simple stuff, we'll see about the complicated stuff later.

I'm going to go relax in a Dentists chair now, it should be more fun.

 


Posted by Ralph Trickey on Tuesday, May 05, 2015 10:38 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Heaps and Heaps

Dang it! Run time libraries shouldn't be lightly intertwined.

I'm trying to link to a C# DLL to do some web related stuff.  Simple right? At least my testbet linked and ran just peachy keen.

Then I tried to link in TOAW.

No peach. Not keen. Errors that have nothing to do with the problem.

After 4 hours, I think I've got it straighted out. You need to include the C++ DLLs when linking to C# instead of just linking them into the program. Why? Darned if I know. Makes no sense to me, but there it is. I may try to separate them later, but for now, it works.

 


Posted by Ralph Trickey on Tuesday, April 28, 2015 1:24 PM
Permalink | Comments (1) | Post RSSRSS comment feed

PBEM

Oh how I hate managing PBEM games, it is so much simpler to let the player worry about finding matches and sending the games back and forthCool Simple for a human, not so much for a computer.

So much code, so little progress. I'm hoping to start seeing something visible soon.

 


Posted by Ralph Trickey on Sunday, April 19, 2015 9:17 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Failure

I just had the opportunity to hit two kinds of failure today.

One was the good kind, I tried to generalize sorted lists and after banging my head against different walls for two days decided that Copy/Paste inheritance was the best fit for this :( I could have kept trying to put that square peg into the round hole and it would (might) have worked, but I just wasn't seeing the savings I'd hoped for. So, I backed out 2 days worth of work. I also learned one problem set that C++ inheritance doesn't really work well with. I'd actulaly hit this before but didn't realize that this was the same problem. If you have two trees that are related, you're going to have serious issues trying to keep them related.

One was the bad kind, I spent the next 4 hours doing basically copy/paste inheritance and when done, tried to figure out how to put it back into Git. Before, it gave me warnings about how I might not want to do this and after searching, finding out that I had to check the clean button in order to actually get that earlier version, so... When I double-clicked on the master branch to try to get rid of the detached head (whetever that actually is) this wonderful tool decided that's OK I'll just go ahead and wipe out your 4 hours of work.

ARGHHHH!!!


Posted by Ralph Trickey on Wednesday, April 01, 2015 9:39 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Unity 5 changes

Unity 5 has made some changes to their product with the 5 release which make it a lot more tempting for me now. The biggest one is that they are now shipping the same engine for the free and paid versions which includes the ability to link to C++ and the free version now includes some important optimizations that weren't there before. I'm going to have to figure out where I can get the time to build a sample in Unreal and Unity to compare them myself. So many toys, so little time.

 


Posted by Ralph Trickey on Saturday, March 21, 2015 9:56 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Modern C++ code

Just for fun, here's a little of the new code that's being written. Helicopters is an array that is created here and contains only the helicopters and is used instead of looping through the unit array looking for helicopters. This is actually within a loop of all hexes on the map, so it is much faster this way.

Right now, I'm struggling a bit with the class design. Right now, I'm saving/restoring the raw C structs and layering the class library above them. I think that creating the class structure from scratch instead would be cleaner, although I'm not sure that the extra work is worth the gain. One example of where this comes into play would be the Intel class. It's obviously completely separate functionality. One thing I could do with C++ is to put the interface in the UnitMapLocation class and the implementation into a separate CPP file, or even in a #pragma section. Part of me doesn't want to do that since it's going to be difficult to avoid putting things into one huge file. I could leave them there and add forwarding functions, but that might take slightly more time. Even so, that's probalby what I'll end up doing. The release build version should end up optimizing them out, but it's gong to make the debug version slower. Since I normally run the debug version, it impacts me. The release version build takes about 10 minutes.

I've got logical layers to the classes like Terrain, UnitMapLocation, MapGraphics, etc. They are there to help me figure out what the code does. Occasiionally they're a pain, but I think they help.

SpecificUnitList helicopters = SpecificUnitList(0, [](const CUnitType *theUnit) { return theUnit->recceHelicopterIcon() || theUnit->attackHelicopterIcon(); });
if (um.allUnitsInLocationAnyTrue([](const CUnitType &u) {return u.anyLandIcon() && !u.isSeaborneStatus(); })) {
	//TODO:Rework, spotting is only for the topmost unit
	if ((localRecce(xyu.owner()) + helicopterRecce(helicoptersu.owner(), xy)) >= OPRandom::rnd(1, 100))
		spot(xyu.owner(), ueSpotting::STATIC_UNIT_SPOTTING);
	else
		spot(xyu.owner(), ueSpotting::MOVING_UNIT_SPOTTING);
}
if (um.allUnitsInLocationAnyTrue([](const CUnitType &u) {return u.airUnitSeaInterdicting() || u.getStatus() == AIR_SUPERIORITY_STATUS; }))
	spot(xyu.owner(), ueSpotting::SEA_INTERDICTION_SPOTTING);


Posted by Ralph Trickey on Sunday, March 08, 2015 10:53 AM
Permalink | Comments (1) | Post RSSRSS comment feed

What's worse than a bug that suddenly appears for no apparent reason?

One that suddenly disappears! You can't ignore it even though it's gone, you still have to figure out where it went.

Yesterday, upon the stair,
I met a man who wasn't there.
He wasn't there again today,
I wish, I wish he'd go away...

When I came home last night at three,
The man was waiting there for me
But when I looked around the hall,
I couldn't see him there at all!
Go away, go away, don't you come back any more!
Go away, go away, and please don't slam the door...

Last night I saw upon the stair,
A little man who wasn't there,
He wasn't there again today
Oh, how I wish he'd go away...


Posted by Ralph Trickey on Tuesday, March 03, 2015 1:18 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Button, Button, who's got the button.

Figuring out how big average text is is HARD.

Normal text isn't too bad, there's a function that will take strings in and spit out the size. Trying to set buttons to the same size so they don't look funny isn't nearly as simple when you can vary the font. I've been hip deep in inner leading and other esoterica trying to figure out a scale factor. Inner leading is the lead they used to put at the bottom of a character when compositing text. External leading is on the outside and not part of the character. All this made a lot more sense back when they put physical characters onto a platten and printed that way.

Right now, I'm taking the average character size minus leading (for the height) and comparing that to the current 8 bit/s per character to figure out the button size. It's that or walk through all the strings on buttons at startup and ask what size they are.

I may end up also exposing button width and height overrides in the font.ini file for people to tweak if the want it perfect.

The joys of building things pixel by pixel, most people can just say 'I want a Blue Button Here, with this text and this size.' 

 

 


Posted by Ralph Trickey on Sunday, March 01, 2015 9:17 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Code status

Don't misunderstand me, TOAW was very well written for it's time. I've looked at other programs written around that timeframe and they are absolute messes in comparison. Norm did a fantastic job given the constraints. It was written before C++ so there is a huge reliance on global variables. There is some separation between the logic and display but some parts are better than others. I'm pretty sure it was also written originally as a DOS program and the conversion to Windows works, but it used to have lots of loops polling the input which was the only way to do it in DOS but not the best way in Windows and impractical for mobile. The interface code was written assuming an 800x600 display and everything was coded using pixel coordinates and an 8x8 font. While it wasn't OO, it did do some sensible things like passing x, y as the first two parameters when looking at terrain and other sensible things like that. 

I've got the advantages of both using C++ and OO and having used several windowing systems (Delphi, C#, HTML, and a few others) so I have some ideas on what the programming interface looks like. So I'm taking the time to do an almost complete rewrite of the graphics system to isolate the windows pieces in a couple of source files and writing an abstraction layer above it. 


Posted by Ralph Trickey on Saturday, February 21, 2015 12:51 PM
Permalink | Comments (0) | Post RSSRSS comment feed