Tutorials

Tutorial Screen

So my update schedule is going to be a little hit and miss as personal things are popping up in the way. Nothing bad, and I'm still working away. The good news is I have an idea of the seven tutorials that are going in. I'm going to be writing a supplemental tutorial editor for myself, just to make editing the timelines a little easier. Also, I have been looking at some new themes for the game proper. Nothing concrete yet, but I'm starting to narrow down what I want the true "Default" theme to look like. It's a little more blue and white with grey and a slight cartoony touch, but the "Classic" mode will still be there too.

 As for right now, there is a lot to back-end and co-opt the old help system, but this is the last functional feature I'm adding that I know of, unless I forgot anything.

Manual is Complete For Now.

New on the left, old on the right.

First pass of the manual is complete. All the graphics and callouts are in there. I did a quick review and saw it's not 100%, but it's in a self-contained format that can be edited and exported to PDF. I'm thinking about actually releasing the manual as a kind of promotion for the game, but I'm not sure I'm going to call that yet.

There are some subtle differences between the versions. In a perfect world I would of set up headings and other auto-format items, but as the original documentation was already formatted, I didn't bother. However, the headers are what's used for the auto table of contents and linking system. This is why the title in the page header is also missing. Even though the current version is a page-for-page copy of the original (for the most part), I have a lot of aggressive page breaks that's going to wreck havoc when I update the documentation. I'll worry about that when I'm in the finalization phase.

Next is the tutorials. I was monkeying with the demo save/record functions a little bit today. I'm not keen on the timers yet so I need to figure those out. There are 4 timers in the game, and they all have a resolution of 100ths of a second. Originally they were dependent on clock(), which required <time.h> but I wrapped allegro's timer function around them.

The 4 timers are as follows.

long mtime //The master timer that starts from 0 and runs as the game plays
long ktime // The keyboard timer for keeping track of when keys were pressed for demo recording playback
long rtime //??
long ntime //??

The last two are used for time swapping but never really investigated as they just seemed to work after I replaced the clock() function. This will be getting scrutinized as I convert the demo system into a tutorial one. That's tomarrow's mission.

Still On the Manual Thing

The manual is slow and steady, but while reformatting and reviewing it, I have lots of ideas for tutorials and guided tours now. I'm also jotting down ideas on how to implement the lessons in a back-of-the-napkin kind of way. As I said before, the keyfiles are simple list of what key was pressed and when. It does not save mouse clicks, and on top of which, the mouse is disabled when recording a keyfile anyway. However, one of the interesting things about ROE is that it has object list of all the buttons in the game. The button object info also includes the locations and sizes of them so I'll probably be capitalizing on that to highlight buttons that were pressed with a callout to the tutorial text.

Speaking of callouts, reproducing them in the manual is kind of tedious. If it isn't obvious, I'm using LibreOffice. Sadly, the callouts native to that program have boxes around the text elements. This means I'm having to do the text elements and the line separately. Looking at the original scanned manual, it appears that the graphics were physically pasted into the paper and the lines were drawn with pen. This is a massive improvement.

Anyways, back to putting my editor's hat on.

Manual Labor

I've decided to make it a weekend project to finish the manual. At least get it current and into some kind of  baseline. I've had to update some graphics a little but most of it is simply pushing things into the right areas and putting pagebreaks just so. 

It's yet another unglamorous thing. But it's been fun updating some of the icons to Unicode. Sadly the symbols used for PageUp/PageDown and Home/End were not the ones that the Unicode standard chose. (But are the ones in the game) so I had to make due with a graphic.

Speaking of graphic I updated some of the lineart to SVG. Looks pretty snazzy.

All of this work is giving me ideas for tutorials. I think I have about five or six of them in my head now. I finalize them when I'm done with the manual. I'm on page 87 of 220 after a days worth of work.

Keyfiles and Tutorials

I was able to knock out the keyfile/demo system today. It was pretty simple. I can now record and play back keyboard inputs as the basis of the upcoming tutorial system. However, it then became a question of... What should I tutor?

ROE has kind of an esoteric interface. It's one of the things I find charming about the game. However you shouldn't have to read a 220 page manual to learn how to play content anymore. Current gamers, for all of their nostalgia, reminisce about when games came with booklets. I can relate. However, here's a little tidbit. Right now I'm learning how to play breach so I can get the IGS linking done properly. That game is not very intuitive at all! It's 126 page manual, (Which also doubles as it's copy protection), is a bit heavy interspaced with stories and lore. However, you have to get to the end to find the quick-start tutorial and the key bindings. Another thing is RTSs have grown a little and there are conventions nowadays that didn't exist in 1991.

Giving the manual a facelift.

It get an idea what is important, I decided to end-to-end the ROE manual. While cracking it open, I figured while I had it, I might as well work on updating that as well. When I get the ROE sourcecode, it came with the manual in both DOC and Adobe Pagemaker 4 formats. Sadly, there is nothing that is going to crack open the Pagemaker files. The last program that could open those was version 7 and Adobe redirects you to InDesign, which can't open them at all. Such is progress I guess.

So I'm updating the DOC files, that seem a bit out of date. I'm filling in the gaps from a scanned PDF of the original manual. It's looking good, and while I go through it, I'll be getting together a tutorial syllabus and implementing what I think is important. Most likely there will be a run though of the Shakedown Cruise. This may require me to do a little datafile shenanigans as it will require me to make a commander and start a game that won't mess up the player's settings.

I'm also mapping what the actual command line arguments are for the game. I know most of them, but it's best get get them all written down somewhere.

Zoom Works - All Options Complete

Zoomed 16:10 on 16:9 display. Side borders are visible.

After straightening out my math I was able to get the Zoom option to work. I also added some bilinear filtering to make zoom and stretch options look a little better. It makes things a touch blurry, but That will look better when the HD graphics are implemented.

My next task is the Demo/Tutorial system. The demo system in this game uses what's called a "keyfile", which is a timed list of recorded keys pushed during gameplay. I have a sample demo file, but it doesn't have much. While I was checking the filesystem functions for the keyfiles, I saw that my data path variables could stand to be a global so that any function could use them. I streamlined that a bit.

During the initial porting process, I had an issue with the keyfiles before so I left them alone. The problem was I couldn't process the accelerator keys. I actually don't think I'll need these as all the commands I have run across so far don't use them. Especially as I'm going to use the keyfiles for tutorials. The idea is that with every keypress, a bubble will pop up explaining why that button was pressed. That tandem script will be found in a .tut file with the same name. The game only uses one demo file called "rules.dem" but I will take advantage that the keyfile loader allows for different filenames. The idea is the tutorials will be found in the F1 Help function. Right now it just gives a general blurb about the screen you are on. After adding the Option button, I should have no problem modifying the help system. I'll have to come up with a syllabus. Most likely I'll have it auto-play though the shakedown cruise mission as the "final" tutorial.

I've been working a little extra to make up for my lost GDC time. My Trello TODO list is getting shorter too :)

Stretch and Squish

Ship builder in 1080p. It's cooler then it looks

The ability to stretch the game full screen corner to corner works, along with the mouse. Going along with this was a little optimization to the rendering flow. I'm now prototyping the "Zoom-Maintain Aspect Ratio", but I started it late in the day and my brain is having difficulties mathing the proportions right. The aspect ratio is backwards so it's taking my 1280x800 picture and squishing it into a neat 1280x720. (i.e., it's applying the 16:9 aspect ratio of my screen onto the picture, and not the other way around.)


After the display squishing is done, the next project is the keyfiles, which should be turned into a Tutorial system. The keyfiles were originally the prerecorded input used for "demos", which was popular in the 90s. I may extend this a bit with a commentary file that is read in tandem.

It may not look like much, but it's going better then I imagined. 

Seamless

Overlap at the corners

So I was able to correct the seam problems. Most of it was overthinking the problem. What I was doing was tweaking the corners to try and hide the very edge of the texture. What I wound up doing was remodeling the cube to have the edges overlap by a tiny amount. That was able to fix the seam issue once and for all. On the right is the model I used. It was just a matter of making a cube and then "pushing" in each face a little bit.

I fixed the FadeIn() fader. It wasn't anything than needed a rewrite, just some order of operations were backwards. I also just got the starfield implemented.  I've having the border  update when the game updates the screen. Keep in mind that ROE updates the screen asynchronously. This means the border rotates faster on some screens then on others. This is actually a good thing, as it allows me to look for bottlenecks. ROE is not a computationally complex game, but some screens are giving me less then 10 FPS and my CPU is spinning up to 100%. Some screens "pause" input which causes everything to freeze until you press "OK". During my optimization pass I will need to get the background spinning as fast as possible and then I'll put in a timer to get the updates consistent. However, for now, the background is implemented. Now on to the squishy/stretchy bits.

The rotating starfield is ubiquitous while in full screen mode.

Crossing the Border

Full screen experiment using a test border

So this implementation of the border code is going much more smoothy then I thought it would. I haven't started on the squishy/stretchy bits yet, but I have been able to shim in where to render the background. Even better, this allows the theme to have semi-transparent screens so that the background will show from underneath. I have the (admittingly unoptimized) skybox code functional. I have a "lab" that I develop experiments in. It's a completely different solution then the ROE project. I've used it in the past to work out color tinting, audio mixing issues, and other odds and ends to check if what I'm attempting if feasible. If it looks good, it goes into the main code with a little cleanup. In fact, the options menu was one of the first times I wrote a whole chunk of functionality in situ. Much of that required functions in the game itself

Seam errors

 As far is the skybox code goes, everything rolls in an lazy clockwise corkscrew. I have the camera slowly yawing and pitching to give it a slow precession. I am having a problem with my texture seams that I still have to work out. In Allegro, the textures repeat and so if you have a dark edge on one side and a bright edge on the other, the interpolation will sometimes "bleed" though. What you normally do is clamp the textures so you don't get rendering errors, but I don't seem to have that functionality in Allegro out of the box. There is a OpenGL extension I can use, but I think I can work with that I've got. If anything I can give the edges a little "push" outside the cube to hide that.

Sadly when fading in with the new border, it looks like garbage.  I'm going to need to recode the "fade in from black" function again, making it my 4th rewrite. The original game used a simple CULT fade, but I don't have that in Allegro 5 and instead rely on layers going from opaque to transparent on a timer. I think I may need to "Fix Once and for All" that code once and for all.

Skybox

Testing the skybox UV mapping

So I decided to do things the "hard" way and make the starfield border a skybox. It just seemed like a better way to render it. If I would of gone with the 2D tile route, I wold have had to deal with a rotating a tile matrix and repeating textures. With a sky box I can make the stars pan, roll, and pitch in any direction with no repeats. So far everything works well. I have to remove a lot of the extra cruft and you can also see the skybox seams. I've played with skyboxes in the past with Blender so that's pretty easy off-by-one error you fix. As far as the textures go, I'm going to need to do some perspective correction, resolution boosting, and a apply a little little bicubic filtering as well. I know doing the silly 3D thing is kind of overkill, especially when most of it is going to be covered up by the game. However, what I'm envisioning in my minds eye is holding up and it should look much cooler then a boring black border.

I actually had to make the cube by hand, and manually set the UV points. I'm kind of glad I only had 36 vertexes to deal with. I'm also dealing with some pretty primitive 3D so I don't have to worry about surface normals pointing in the wrong direction. (They all are, which is why the numbers are backwards). This also means my skybox is also inside out , but as it's stars, it't not really a problem.

It Feels good to be back in the programming seat again. I'm going to need to fix this 3rd shift sleeping schedule soon.

Making sure the textures align.

Starfield

When you deal with aspect ratios, there is always going to be the question of what you do with the border. This is a big issue as ROE was originally designed for a 4:3 monitor. As I espoused in the past, the game was 320x200 which is a 16:10 aspect ratio. Doing a little research, from 2003 to 2008 16:10 displays were super popular for computers. It seems they were just square enough for laptops, and desktop uses like the extra height. In 2008, the market abruptly shifted to 16:9 to match TVs. The idea is, just make one aspect ratio to keep the cost down. Android phones, however, still retain the 16:10 aspect ratio.

Now that the options menu is done, I need to add the Zoom/stretch modes. In Native and Zoom mode I'm going to have a border. I plan to fill this space with an animated starfield.

My rendered border tile

I found a real cool free program that generates starscapes. It actually generates a skybox. For now I'm just using a texture that I rendered and then edited in Gimp to make it tileable. However, on second thought, I may look into the skybox idea. The upshot is that the borders will slowly be moving. Not fast, but more of a graceful roll with a comet streaking every once in a while. It may even change directions. Right now I'm doing rendering experiments to see if it matches what I'm envisioning in my head. I may devote the weekend to this experiment.

I was able to remove two cards off the trello list into the done pile. I'm no longer adding things to the "Todo" side so the alpha is good and underway.

I want to have a beta by June.

More Darkwork

I'm still on the options menu. It can flip from full screen to windows mode and it can set the audio settings. I'm quite proud of myself as I can set the audio with sliders or clicking the buttons and with or without the mouse. I'm learning how the GUI works in this system and I'll be using what I know to attack things down the line.

It's taking a little longer then normal, but I'm now back in the saddle. That trip to GDC really knocked me out and it took a lot to get back into the proper headspace again. Tomorrow I'll be doing the text input and hopefully will be going on to the new graphic modes. It's really nice to be able to run the game without editing the config file anymore. The only other "Big" addition I'll be making is the demo system into a tutorial system. It's just a matter of extending the keyfiles a bit. Looking at my Engineering tasks in Trello, that's that and IGS integration, which is coming along as I work the filesystem. 

More Options Work

Still working my 3rd shift schedule. No glamorous screenshots. I'm still working on getting options to work right. Most of my work so far on ROE has been to get old functions to function and try and get the game to run as out of the box as possible. In this alpha phase I'm actually adding in functions that were not there before. For extra hard-mode credits, I'm actually using the original Nermal API. Keep in mind, there is nothing stopping me from adding functions in Nermal (I have actually extended it somewhat). What is different now is I'm adding functions into the game proper.

There's a lot of gluing and pixel counting.

I have (yet) another hacky solution to my themes. When the game runs "stand alone" the theme folders will be in the same directory as the executable. However, as I'm writing the game, they are currently not. Visual Studio is doing some path magic where my default folder is my working directory and the executable has been sequestered off into a "Debug" folder. Now that I explicitly name theme folders I need a copy of them with the executable, which botches up my working directory and saving my resources to Git. In Linux this would be no problem to solve as I could just make a symlink to the theme folder and call it a day. In Windows however....

In Windows you do exactly the same thing.

Did you know that Windows systems after Visa support symlinks? Yea, me neither! Actually NTFS 3.1 could do it in Windows XP, but XP's shell has issues with it. Now I have a duplicate theme folder that will change when I update from my working directory. Pretty cool.

A Slight Rework

My sleeping schedule is all shot again. I got up on Monday night and just decided to just work 3rd shift. I decided to rework the options menu. It looks so much better and appears like it belongs now. The reason why I'm using the "Classic Theme" is to keep things consistent. When I start implementing the new theme(s) I want to use "Classic" as my template.

Short of some hacks, I am able to read the config data for the most part. I discovered that my theme engine is quite hacky and needs to be corrected. Also, converting a char from 0-255 to a string from 0-100 requires and ugly cast to float. I something I can fix, my brain power is empty now. Also the sliders don't move when you click on them with a mouse. I'll steal that code from the captain builder.

This options menu covers everything from the installer with a few things cut. There is no audio on/off as setting the volume to 0 does the same thing. Also, the game auto detects a pointer device and will give a pointer if appropriate. As you saw from my touch demo, it hides the pointer automatically in that mode.

There is still some cleaning up the theme code and then starting on the Squish/Stretch rendering of the display. I *will* lose my blitter and my mouse when I do this, but it's better to break these and fix them then to have something break and not even know.
 

Keeping Options Open

Every once in a while I'll have an inconvenience get under my skin and I'll will want to fix something "Once and for all". I did this for the Nermal library and then for the BlitBit() function. (Something I rewrote three times).  Now that I'm in the mode of getting ROE feature complete, it was time to attack the "Options" button.

Layout is still in work.

Originally options were set when you installed the game. I added an options button, but all it did was change from windowed to fullscreen and required a restart I'm now adding options and putting in controls. It doesn't work quite yet, but when I get this functional, I'll be off to break/fix the scaling code. When I was at GDC, there was a developer there that made a "retro" game in 4:3 and came up with a slick way to animate the dead space on the sides when it was displayed on a 16:9 display. I told the chap that I as going to straight up steal his idea. He was happy to let me ape the design. I know that once I start messing with aspect ratios it's going to be all over the place. I might as have the option available to put things back when it inevitably screws up so I'm not hex editing the config file all the time. The listing in the screenshot should be all the options I need for this game.

I need to make a few buttons in the menu and get the input right, but this is going to be my pet project for a while.

Easter Egg Hunting

Breach2 import works

So I have the ability to load Breach2 commanders now, which is nice. I only have a handful of filesystem functions left that depend on the stdio.h library. While playing the game, I noticed that if a mission had an enemy named "FWRP" that my communications  picture changed from the alen form to a human FWRP officer. I went hunting down where that was and that's where I discovered the "Easter Egg" aliens. I knew they were there as I had a graphic for them, but I never saw it loaded and I assumed that it was some legacy fluff.

Nope!

Turns out that there is a list if 14 alien names that will change the image of what your race will look like. They are listed below.

"'EJYO' DIVI'" =  Captain Picard
"TERRAN" = Blue Superhero(?)
"TLHINGAN" = Klingon
"FWRP" = Federated World Reserve Personal (In universe)
"FWSF MARINE" = Federated World Star Fleet Marine (In universe)
"ROMULUSNGAN" = Romulan
"OVERLORD" = Devil
"ALLIANCE SSE" (In universe)
"MARVIN MARTIAN" = Loony Tunes chatacter
"UNITED PLANETS" = (In universe)
"ROBBY ROBOTS" = Robot from "Forbidden Planet"
"GORT" = Robot from "The day the Earth Stood Still"
"METALUNAN MUTANT" Alien from "This Island Earth"
"CONRAD NEAL" - Dog with a bow tie

I tried making a Marvin Martian race and, yup... Easter Egg still worked. Sadly, those are going to have to be unceremoniously ditched except for the in-universe races. Cute Egg though.

Sorry Marvin :(

Breach 2 Integration

Breach 2 Detection code is in now. See the new Options button?

So I'm still trying to kick out the rest of the filesystem stuff and I'm working on the integration for Breach 2. This means that I need to make plans about how a theoretical Breach 2 game is going to install if I ever port it to Windows.  First thing is that the data files are going to be installed in a set location and I have that all planned out. Next is the Breach 2 commander conversion code, which I unceremoniously dumped a few weeks ago and now have to put back. I have some new code where I can detect if B2 is installed and then grab the files without asking for a path first. After this will be some backtracking to figure out why my mission loader is misbehaving. It's not only crashing, but some missions are being misread, but I'm pretty sure it's the IGS data that's embedded in the file. Emails went out to some people I met at GDC. I have a project request too, so I'll see what that is all about.

I also have to say, thank goodness I documented much of the core functions in  Doxygen. It's making adding buttons (Like my new "Options" at the top) and alert dialogs so much easier to do.

Wise from your Gwave!

Hey, It's been a while! Looking good! How are the kids? That cool.. Oh where have I been. Well, I wish I could say it was a long story but it was a double-whammy of being sick and a profound desire to just take a break.

I'm back for what it's worth.

Artist's rendering of my fate

It all kinda started on Friday at GDC. I had awaken from my slumber with what could only be described as my insides desperately wanting to get out. There are only two ways anything was going to exit my body and my entire digestive system was giving it a go at both ends. You know in the movies where Death decides to pay you a visit and it's always this skeletal from in a black robe and scythe? Well, remember that he's just one of the Four Horsemen of the Apocalypse. For some reason, Pestilence decided to stop by. I can imagine he was having a great time wandering about GDC in his green cloak, quiver, and bow. I'm almost positive he delighted in putting on every HTC Vive, Oculus, and PlayStation VR at the event. I mean, he did have a job to do. There were so many people from all over the world crammed into one place. I made an effort not to put my face into any virtual reality mask, but it was all for naught.

At 3:30am on Friday, a knock comes to my door. I get up and open it, and there, I swear to God, stood Pestilence.

"Hey dude," He says. "Mind if I chill for a bit at your place for a bit?"

I thought about refusing, but over looking over his shoulder into the parking lot, death was hanging out on his pale horse. He waved at me with a grin.

"That's cool", I said, like I had a choice. "I have an extra bed and the Wifi is free. The password is on the desk. If you don't mind. I have to go to the bathroom now and empty the contents of my stomach in the most uncomfortable way biologically possible."

"Sweet!", Pestilence said, letting himself in and jumping into the extra bed. "Do they have cable here?"

"BLLUUAAARRGGAGGAHHHHHH" I said into the toilet.

I was supposed to checkout that day at 11:00am. I was planning on spending the rest of the day a GDC with my luggage tucked away and catch my red-eye home. I wound up having to pay an extra day at the hotel. I ordered room online with means the rate went to $140 for the extra 10 hours. When my alarm woke me again at 8:00 at night, the horseman was still in the other bed on his phone. I got up and packed as best I could and made my way to the office. My green cloaked friend followed. The front desk was very accommodating and, upon hearing that I haven't eaten anything all day, offered me a pizza slice. When I opened the box, Pestilence tapped my on the back with one of his arrows.

"I wouldn't eat that if I were you." He advised. "It's your call though!"

I nursed the pizza slice until I got to the airport.

The next couple of hours were kind of a blur. I honestly don't remember how I got back to Wisconsin. I kind of remember during the flight, Pestilence coming back from the bathroom and sitting next to me. I groggily rolled my head over to his direction. He was playing Candy Crush Saga.

"Look dude." I said. "I don't mean to be rude, but why are you following me?"

"Oh!" Pestilence replied, looking up from his phone. "I have this deal with the airline. I'm dead-heading to Chicago. There is this thing going on at the Jardine Water plant next to the mouth of the Chicago River. It's gonna be lit!"

"I bet"

When I got back home that Saturday morning, (I don't recall driving home, but my car is definitively in the parking lot), I fell exhausted in my bed, and spent the next week there. I have discovered that the older I get, the time to spring back from being sick gets a little longer. Not excessive, but it's noticeable. Whenever I do get sick I tend to have a persistent cough that hangs out a little longer then normal. But, as a parting gift, Pestilence decided that a bout of bronchitis would be a great way of saying goodbye.

During this time, coding was the furthest thing from my mind. I decided to just write off the whole adventure as a two week vacation. On Monday I had discovered that getting back into the code was such an awful experience I had no idea what to do. I had bookmarks all over the place. Trello in-works that were not in work, and other tasks that just seemed to be too monumental to attempt. I was drained and due to me work stoppage felt like Sisyphus at the bottom of the mountain.

I compiled the code I had. It still worked. I'm am now at my seat and ready to
start in what feel like starting over. I'm here now... I'm feeling OK. Thanks for asking :)

GDC Day 3

I'm dead again

If I don't lose 10 pounds by the time this is done I will be shocked! Meeting lots of people. Went to an awesome marketing seminar and I'm starting to get my web presence known. Coming back to the hotel after a day of GDC-ing I am asleep as soon as I hit the pillow. I'm getting ready to go out again. I think I have the subway system figured out now.

It rains an awful lot here.  

GDC Day 2

I'm writing this the morning after because I literally died last night when I got back to my hotel room. Somehow I was resurrected this morning by my legs feel like noodles. It's a strange environment here. You just walk to up to interesting people and say hello. You chat for a bit, throw out your pitch and have a conversation. I have talked about game narrative, styles, publishing, business, and lots of others just in random. I even pulled an old prototype game from years ago to show to some interested Japanese and swapped cards.

There are vary famous people here. Amusingly, during the GDC 101 talk I attended we were warned to kind of stay "at our level", nothing wrong with striking up a conversation with Mr. Video Game Superstar, but there won't be much that guy can do for you.

I have a video demos of what I have for ROE done on my phone read to go at a moment's notice and people have been interested and have given me great feedback. It's also been fun looking at the reactions from C++ programmers about the thing I've had to do to pull 20 year old code kicking and screaming onto new platforms.

Today the expo proper opens so we will see what goes on there... If you are coming here from the link on my business card. Hello! My whole adventure is here for you to read. Thanks for coming!

GDC Day 1

I'm exhausted.

Flying is fun!

I kind of misjudged days and spent my first day of GDC just getting out here. I'll be getting my badge at 7:00 tomorrow and start making the rounds. I have a few missions, most having to do with the marketing side of ROE. I'm going to hunt down a few publishers just to say hello, and chat up companies that do what I do, namely port legacy programs to new platforms.

I'm flying back business class though!

Into the Breach

Broke though the sound problem and now super productive again! Go me! I was battling an issue where the game would only play two sounds and refused to play the rest. For the last two days I could not get the sound to work at all. That was two days of going though the documentation and everything. I even got in contact with the library developer and sent him sample code and he didn't see why it wasn't working either... Do you want to know what the problem was?

smpl_hits = al_load_sample("res\hits.ogg"); //<---- was not working
smpl_hits = al_load_sample("res/hits.ogg"); //<---- working

Yup I had backslashes in my path. This was even a dumber mistake because here I am trying to abstract the filesystem away, only to use relative resource paths on the filesystem. After I found that I immediately removed all folder references and used Allegro's path system instead. I am now almost done with the filesystem stuff, but came across the functions dealing with loading Breach 2 data. I now had a choice. I could disable it for now or implement it in case I have an opportunity to port Breach 2. I didn't have any samples of the files I needed, so I started to comment out the functions. I then realized this was breaking the whole reason why I'm keeping binary compatibility. I guess if I'm going to make the game feature complete for the beta, I need to  have the Breach 2 stuff functional as well.

I procured myself a copy of Breach 2.

Old School DRM

When I opened it, I was hit with a screen asking me to look up page 27, line 2, word 1 of the instruction manual. It took a bit but I was able to procure the manual too. I then went into Breach and created the files I will need for ROE to work. Added that a new TODO in Trello. Now going to see if I can't get these guys to link together.

Game is still going forward!

Sound Test Below....

More Prep Work

Successful repo download and compile

So today I didn't spend a lot of time in Visual Studio. I did update the repo with build instructions. Most of today was spent nursing a sick laptop to what I was hoping was better health. Also it was my first time really exorcising Git to make sure I could check in and check out thing correctly. After fixing my commits that was all smooth too.

Sadly the laptop has seen better days. The charging circuits don't work and it has a dodgy power connector. I'll probably just take the chromebook make some presentations using pictures and video from the blog here. I can always RDP from the chomebook back home if I need to get some work done. So that means was mostly marketing research. I spend time online chatting with others who are going to be going to GDC and arranging meet-ups. I'm also fleshing out a schedule of what to do while I'm there.

Other than that, nothing special. Oh, the sound mixer in Allegro has a bug in it and one of the library  developers are looking into it. I sent him example code and he confirmed that it's acting bizarre. That the thing about when you use computer systems daily for hours. Even with commercial systems, sooner or later you will find a bug.

Going to GDC - and other things

So on Monday I'll be in San Francisco for GDC. That's going to be fun. I spent all day today prepping for it. One of my tasks was bringing my travel laptop back from the dead. It hasn't fared well. The last time it was fired up was when I was in Japan last year. I've been spending most of my day getting things updated and moved around.

I bit the bullet and got a GitHub account and uploaded ROE to it so I could work remotely. Also, my online backup is expiring next month so it was better to get a copy of my work somewhere safe. I'll be switching backup providers as well. I worked in I.T. far too long to see what happens when you don't back up your stuff. Heck, even the provider I have now saved my skin when a HDD blew out. The provider I have now is moving to company-only solutions and exiting the home market.

 I need to still get VS2015 on this machine and get a sync going as well. This means getting Allegro set up and a copy of ROE compiled. I also think my power plug may be dodgy. I'll investigate that too. I'm hoping I don't need a new laptop. If worse comes to worst I'll set up remote desktop and use my chromebook.

Game-wise all the sound effects are complete, but the implementation is acting up. When I monkey with the sounds, I'm losing my audio subsystem all together. May be an allegro bug, but I can use another lib if push comes to shove. It would be a bummer to add a dependency after working so hard kicking lots of the legacy stuff out.

Came across a new development word today; "Darkwork". It's a term for when you code something and the result was no different visually then before. It was used by a coder who was making his own engine and was describing when he was coding up the infrastructure. Meaning he had to do a lot of Darkwork before he had anything even functional towards an engine. I've had Darkwork days too, but as I move to Ugly Beta, there will be a considerable amount of prettiness coming up. I should be thinking about what the new theme is going to look like. I have some ideas, but will need some time in Inkscape/Gimp to see what I can achieve.

Fwreep Fweep Fweep!

So I spent most of today in Audacity working with hundreds of public domain sounds. It was time to implement  the sound effects in the game and that meant getting rid of the old Star Trek effects. This required the playback of many many audio files to see if I could find anything close to what I was imagining in my head. You also have to make sure you use the right search terms. You can't just look for "Door Schloop noise" and find anything useful.The last bit is also making sure what you have is in the public domain. I would be dumb to replace a sound effect you don't have rights to with another you equally don't have rights too. I'll probably have the effects loader and player all done by tomorrow.


I also had a crack at printing TTF fonts on their side and was able to get some matrix transforms working. I can print downwards, but upwards uses the original function to make sure one of the return values are calculated correctly.

I should be getting rid of the rest of the non-Allegro filesystem commands. One requires a filepicker and I'm wondering if I should just use the OS's one via the Allegro hook. I'll see how it looks.

On a closing note, Trello is pretty rad and have been great for me to track what I'm doing and what needs to be done. I was told by some of my indie peers that it's great for small stuff, but does not scale at all. I'll see when I start to roll other people into it.

TTF fonts work for the most part

Working the weekend. I think this is the quickest I've ever implemented something from beginning to end. The implementation on the code was pretty quick. The hardest thing was getting the TTF to exactly match the same spacing as the original bitmap font. Now that that's in place, the text routines are all super fast. This also means I can replace the font very quickly if another comes along. I'm still having issue with an aux Gprint() functions and need to write two that print sideways.

For my next trick I'll be adding the config button, but I also have been looking at using a pixel shader to replace ColorMask(). Right now I'm working with each pixel with an honest-to-goodness loop and can probably optimize it better too.

Let see... command import, sound effects, and I still to figure out a final "look" for the updated GUI.  Lots of thing to get done before I'm anywhere calling anything a beta.

Wow, It's 10:00 AM!

Back in the foundry again!

So last night after posting my blog post I decided to check to see how feasible it was to replace the fonts for ROE. I was just going to see how the letters looked and if a public domain font I had was close enough.

I just spent the last 14 hours making the new font and now it's ready to be implemented in the game.

I honestly didn't know what time it was until I looked over my shoulder and saw sunlight spill into my apartment. It just few by so fast. I took a quick screenshot of the finished font and played with it a little. The last font I made too three days, so I guess I'm getting faster at it.

I'm trying to exactly match the spacing of the font used in the game. The whole reason why switching from a bitmap to a TrueType font is because the game's text editor is horrifically slow, and this should speed it up. Also I get the added benefit of scaling if I decide to go that route. When I get back to Visual C, I'll try a replacement Gprint() and see what happens. If anything it will look nicer than that I currently got.

Also also - need to get enemies to the artist... That needs to be done too! In fact, I'll Trello that before I go to bed.

(Note: This was supposed to be posted at 10:00 this morning, but I saved it as a draft on accident)

Now for the details.

So I was able to sleuth out where the enemy render code was for the game. Updated it and now the little dudes are colored like they are supposed to be. For fun I also decided to add the compile-time switch for a demo executable and that compiled first time through. The game is, shockingly, not crashing which is kind of worrying me :)

I spend an hour hunting down sound effects for the game that need to be implemented. Once upon a time I wrote down a table of what sounds I needed and where they were. I even posted it on this blog. Turns out, I deleted it after I was done. That was dumb.

Also today I cracked open fontforge to look at creating a font that will be replacing the bitmap font used in gprint(). I think I can have that done over the weekend. Also looking into getting that "Options" button added.  Originally the game was configured with a setup program. That is no longer needed but I will probably be looking into an installer package.

My goal is to have a Beta by the end of the month.

And so my Space Career Begins...

Comms work now.

I was able to (hopefully) peg down that last null pointer, and was able to play the game. For some reason, my mouse would die when I went to either the navigation or tactical screens. These are the "busiest" screens that are using my very ugly color hacks. The game was running at a blazing 2 FPS. I'm actually impressed that it was going that fast. The mouse clicks, however, were being delayed by anywhere between 10 and 45 seconds. The strange thing was the keyboard queue was fine, so there was something up with my mouse queue.

Enemies are not rendered right.

After digging a but I discovered that my mouse event queue was storing hundreds of mouse movement events, and not just the mouse clicks. The means that the game grabbing a single unneeded mouse movement event every frame and throwing it away, only to grab another the next frame. If you didn't touch the mouse It would eventually "catch up" and grab that click. I updated my event handler to simply delete all accumulated mouse movement events in the queue until it comes across a click or until the queue is empty. The game is supposed to check for a click first and then asks the OS where the mouse pointer actually is on the screen. Mouse movement is handled by the OS. This also allows for a touch interface. When you tap the screen, your finger X and Y location is read after that.

The good news is that I was able to create a new fleet commander, assign him to a mission, and then run though the whole game and win. The game, for the first time, ran end-to-end! This doesn't mean the game isn't without bugs. I still have to set up my alpha channels for transparencies right, but that's cosmetic. I'm also getting closer to changing the game font to a TrueType font to speed up rendering.  My biggest hurdle right now is figuring out how to render the enemies in game. It's not using my render routines I made for the builders. Once I have that nailed down, it will be time to start adding some functionality such as the "options" button and sound effects. I hope to have an "Ugly Beta" by the end of the month. The Ugly beta is a beta version of the game with the legacy graphics and before an art pass.  I have yet to run the game "outside" of Visual Studio stand alone.  I just added that as a Trello goal.

Oh and I have to get the builder off the the artist :)

I FINISHED A MISSION!

Pew Pew!

PEW! (Transparency isn't set up quite yet)

Guns work, but there are still underlying issues. Computer systems nowadays are extremely  intolerant of dereferenced null pointers. It actually threw me for a loop too. It's was another issue where DOS was very forgiving, but Windows was not having any of it. The whole issue came down to what NULL used to be, and what it is now.

In the olden days before memory protection, when you set a pointer to NULL, it was largely up to the compiler to implement what that meant. Sometimes the compiler would just set the pointer address to 0 and some would even be nice enough to dereference the value of a null pointer to 0. (A useful example given to me was when you wanted to dereference a null string.) Suffice to say, ROE makes an assumption that the compiler is "nice" and dereferenceing null will give you something. Here's is an example I'm coming acorss.

MissPtr m;           //m is a pointer to a missile object

m = Game->missiles;  //Game->missiles = NULL at this point in the game

//Memory is allocated for a new Missile object

Game->missiles = (MissPtr)malloc((int)sizeof(struct MissStru));

//The old Missile object is linked back (In this case NULL) 

Game->missiles->link = m;

m->prev = Game->missiles;  //CRASH! m is NULL and member is invalid.

I can see how that can be valid on old systems. The compiler is assuming that if the object is NULL then all the other members of that object are also NULL. On newer systems, the act of asking for m->prev is the same as asking "Hey can you look at this obviously invalid address and and give me a data value that in that area?"

The OS will take away your program counter, kill the program, and tell you to think about what you just did. You are not getting data from unknown parts of memory. That's the whole point of protected mode.

I have a feeling there are lots of these in the main code. I ran into one just running the game for fifteen minutes. I have a Trello card now for this so I'll be looking for it.

It Runs as Long as You Don't Pick Up the Phone.

Matching loading/saving of each member

What a fun day. I can consistently load saved games and start the few missions I can throw at it. I tooled around a solar system for a bit and then went back into Visual Studio to write the code to save the game. (I was using saves I generated in DOSBox from the original version.) This required me to go though about 600 lines and make sure all the data members I was loading was being saved in the same order with the same type. Once again again I was hit by off-by-one errors. I have to match the bit width of the read, write, and the original struct data member. I'm sure I have a few misalignments still.

Loading the first mission. HD Stars!

I was able to make a new fleet commander, add him to a mission and then start the mission. This means almost all the functionality on the "101" main screen is done and I have to start working the bugs in the game proper. The big one is when I try and send a communication to another ship and ask for an acknowledgment, the game bombs out with a null pointer. Same thing happens when I fire my weapons. This is happening with the saves from the both the DOS version, and ones I make myself. Also new games do it too so it doesn't seem to be a data load issue. I'm guessing that computers deal with null pointers differently nowadays and causing issues. In the 90s, nulling a pointer just set it to top of memory. I think in newer systems it's simply invalidated because moving a pointer outside protected memory will cause an exception fault.

Once I get things stable I will be making that enemy builder for the artist. I'm still eyeballing the new TTF system font too. Some of the lag is coming from rendering text. I want to move off of the legacy color stuff but I would like to have a stable platform first before I rip out another core Nermal function.

Shields up, and target acquired.

I can see ships now. This means I'll have to fire up Blender and remodel them in HD like I did the puzzle pieces. The good news is there are graphics that show the ships in different angles so I'll be using that as a template.  There are also a few icons that look a little USS Enterprise-ish I have to change too.

There is a lot of commented out and #ifdef'd debug code for comms, looks like it was a pain to implement when it was being developed. I've left the debug flags in the game, but been too scared to turn them on I'll chase down the null pointers first and if people still refuse to chat with each other I may have to get that old cranky code working too.

It Loads!

Tactical

I pulled and all-nighter. I do not recommended to do this on a Friday night. It's going to botch up my Sunday schedule, but I'll take that as a fair punishment. The game loaded it's first save file and I was able to get int the game proper. The loader is way broken and was hard-coded in parts to load a particular file. I do have the data blocks properly delineated so I just have to correct about 10 off-by-one errors. There are still curious number of sections I'm skipping, but most appear to be linked list pointers that were saved when the whole struct blob was written to disk. This data is really not needed because when the game loads the data, it rebuilds the linked lists anyway. I've been using these "blank" spots to check for hard drive errors during load. The good news is I can actually shim in data in these areas and keep things compatible.

So, now I'm in the game, How does it run?

Ship Status

Like pure unoptimized garbage. I expected this though. I'm using debug libs and I have nowhere near touched surface locking. To give you an idea of how things are, I'm running an 3.4Ghz i7-6700 with 16GB of ram. ROE is taking up 31% of my CPU resources when running. I'm pretty sure two of my 8 cores were at 100%. I could actually hear the cooling fans spin up. when it starts to run. The game is crutching on my gross and hacky legacy color management routines. This makes some of the screens take upwardly of 15 seconds to render.

Comms

The good news is I'm in, and I was able to tool around. I can't save the game quite yet, the clock is broken, and commands hang, but it didn't crash. Truth be told I didn't really push it too much. It was more a quick turn of the key to make sure everything at least functions.

I'm going to go to bed now, Later on this afternoon when I get up, I'm going to break up the game loader into different parts to better separate the data sections. The game already does this with solar system entities. With it all broken up I can then optimize and map each section properly. I would like to identify what I'm skipping over. I'm almost sure what they are so I'm not missing anything scary.

When the load map is complete, it will be easy to map that to the save function. I do have a tiny degree of leeway as, as I said above, I don't have to save pointers. I'll probably stuff in some data as a place holder so I can see it's nothing. ...maybe "DEC0DE" in hex. I feel so much better being productive again. I'm about 80% done with the filesystem purge now.

Fleets are loading! Timer's busted though.

So I'm Geordi La Forge apparently.

 I have learned a few things today :)

First thing... FwfStru and FwgStu are two different structures that have similar, but different members and are considerably different lengths. One holds fleet data as it pertains to the ships, and and the other holds fleet data as it pertains to the game. This wouldn't be bad, but the first 21 or so members have the same name and similar arrangement. One is declared as FwfPtr and the other FwsPtr.

When you are manually loading data from disk in byte order, make sure you are stuffing the data into the right object. least your data goes all over the place. I wasn't.

Well, at least it aligns now :)

I have gotten  to load lots of data now and I'm in the process of backing out and writing the loader with the proper object. I had to switch to a 9k save as opposed to a 6K one, but I can now see/mark out the data boundaries much better. I still have 39 bytes unaccounted for, but I can bump the read pointer up to the next block of known data. I was also missing some data members that I am filling in. (I didn't copy from the struct right). I was also originally using the "fleet load" code from mission builder. Turns out, that used a similar, but different stuct for fleets. The solar system data was fine, but I missed the letter change for the fleet data.

When using a function from another part of your code to do the same thing, it might behoove you to think why that code was sequestered off to another part of the application in the first place.

While working the the ship data, I honestly felt like Geordi La Forge on a task from Captain Picard.

"Geordi, why don't we have telemery data?"
"Sorry Captain, it seem to be corrupted due to isometric misalignment. I have temporally bypassed telemetry, and can get some of tactical, minus the photon torpedo inventory. The Misalignment is occurring again at personnel"
"Ok, keep me informed Geordi"

 I kid you not that is where I am right now. I'm back up to 100% and I'll be working though the weekend to make up for lost time.

My online backup provider went offline today. I had to get that fixed up too. I should be pushing my code off to an external git server, but the free ones are only for open source. I'll be shopping for that too.

Digging through the game

I don't think that's the captain's real name :/ (I'm off by about 190 bytes)

So yesterday I went MIA to help retrieve family members for an airport. While coming back my motivation was hampered because I can't seem to get a block of data loaded correctly. The problem I'm coming across is I have a struct with member that points to the struct. (Meaning it's circular). It's not a linked list. It appears to be just a pointer, but I'm getting all kinds of byte alignment issues manually unrolling it. It's getting super frustrating to see the wrong data being read from the wrong part of the file It wouldn't be so bad, but this file is 6K and some of the data inside has variable lengths, such as the planet data or the captain's dossiers. After my airport jaunt I didn't feel like pushing bytes around and today I got up late and felt like it even less. I gave it a shot, made my structs even worse,  I basically spend the day reorganizing my Japanese Magic: The Gathering collection from 1994.

Today was a bad day. I feel terrible I haven't been making any progress and it's creating a feedback loop of motivation. However after leaving my blog for two days, I had an uptick of people looking in on it. I guess looking for a post that didn't come.

I'm here. It's going.

This is a thing that needs to get fixed. I'm solving two problems at once. I feel the is really the final hurdle of core functionality before I go on to making things pretty and stable. (Not necessarily in that order)

I'm also thinking of extending the demo system to add commentary bubbles to give it a tutorial feel. Maybe. For now I'll concentrate more on trying not to load names from the missile inventory data.

Counting bytes and aligning them to the structs. I have 6K of this...

Reading and Writing

I made inroads into writing out a game file and got stuck on some iterators. The original game dumps the data in structs as one binary blob, I'm not sure of what data is in there, but I know I wound up off by 192 bytes. There was a substructure I wasn't quite finding and not matching up with my saved template. I put a demarcation where the data started going off the rails and moved to the routine that loads the game from disk instead. I'm borrowing data files from the original game and trying to load that save from 1991. So far it's progressing, but the fleet structure has about 4 sub-structures  and one sub-sub-struct member that I'm not iterating correctly though. When the game loads the data proper I should be placed into a spreadsheet-like fleet overview. From there the game proper should start.

When I have the game proper loaded, this should make it easier for me to see what loads to where and then reverse the process back on the disk.

Goals: Once I get the game proper to work, I'll be compiling the stand-alone race builder and will be sending that off to the artist. Then I'll be looking into getting a "configure" button for my game settings, and adding in bits and bobs in my growing todo list.