So I started this new job a month ago and I have been working 48+ hours a week, fortunately and unfortunately. I am making lots of money towards the purchase of a new car because my other one broke and I had to sell it for scrap. The downside to this is I have no time for my hobbies that I enjoy. I do manual labor and each night I get home I am tired and sore so I just eat and go to bed and wake up doing the same routine. It really sucks but I gotta do what I gotta do right now. All my programming projects including Forge I am putting on hold for a while. At least until the season is over and I have enough time to sit down and do some meaty coding. In the meanwhile I went to the library and picked up a few good books about programming and math to read in my down time when I'm not working to stretch my brain and to get more knowledgeable in the subjects I love.

Before I started this job, I started researching project management and organization and came to realize that my development process of Forge and other projects are completely scrambled and follow no organization or planning whatsoever. I feel like this is what is taking me so long to develop shit and is slowing me down to a grind. I really think planning my Forge project out by setting goals and dates and organizing a list of things that need done will keep me in focus to what's going on. I work on random things here and there but in my mind there is no end to anything. So I think instead of working on coding I will rewind the tape and work on the planning process until I have something I can follow through with and improve on throughout the entire project development.

If anyone has experience in project planning, hit me up! I am open to any and all advice.

Uhhhhhhh Hi! Just got home from work and boy are my dogs barking! I wasn't planning on doing a blog tonight but what the hell. I haven't really had time to work on Forge the last week but there are some new stuff going on in my code and in my brain.

Ray Intersection with Geometry
So in Forge when the mouse cursor ( center of the screen ) rolls over an object model, it changes the menu to include object options exactly how it is done in Reach Forge World. How is this done? Well, in Reach I believe they use ray-plane intersection determination with the object geometry. Imagine a ray that starts from the center of the camera and points forward into the game world. Through mathematics you can determine if this ray is intersecting certain things like bsp or object geometry so you can know whether or not you are looking at a certain something and/or if this certain something is visible to the camera. This type of method may also be used for collision among other things.

In my Forge code for CE, I was originally converting object world space coordinates to screen space coordinates and determining closest object that way (thanks to Abyll). The problem however is even though objects may be closer to the center of the screen than other objects angle wise, that object may or may not be closer distance wise. I would accidentally grab hold of objects that were way across the map because they were closer in screen space, not so much in world space in distance. I thought writing functions to calculate closest object by distance and closest object by angle would solve this, but it was a waste of hours of time and is very slow.

Now in my code, I am currently using a ray-sphere intersection method. In the s_object_data struct in OpenSauce, there are variables for bounding position and bounding radius. The bounding sphere radius is just enough to encapsulate the entire object and nothing more. So since each object has unique bounding information, I can more efficiently and easily determine what objects I am looking at. In my intersection function when I iterate objects, I also determine which object is at a closer distance out of the object spheres my ray is intersecting with. (The ray origin and direction is the camera position and forward vector by the way.) This is very fast and works so much better. I am happy with it. Eventually I will move onto something even better: ray-plane intersection - to be even more accurate and so I can do visibility determination and eliminate objects that aren't in view through the bsp geometry! Halo has all this data, but I have no idea how to make use of it yet.

Bounding Boxes & Markers

I recently saw a video tutorial by Siliconmaster about how to fix phantom bsp errors. In Sapien I thought it was REALLY cool that they had (pft, pink) bounding boxes to show the phantom bsp. I believe in Spark Edit, they used these also but I can't remember exactly. I want to include this feature just for the coolness factor and also it will help me learn how to draw my own 3d markers in the game world. The markers I am talking about will 'mark' where the object spawn points and game flags (koth, race, ctf, oddball, etc) are. Years ago when I first started this project I was doing this in 2D and it was a terrible idea and it's very ugly. To see what I am talking about, here are screen shots from a few years ago:





See those ugly ass boxes? Of course they aren't scaled and to size so they looked terrible anyway. Making them 3d to surround the objects / spawns so they appear in the game world would be epic. So over the next few nights after work I am going to be researching this phantom bsp function. So far I have seen they are drawing 12 separate lines for the edge but haven't really looked further than that code or deeper into it yet. If I knew more about rendering in d3d, this wouldn't be so hard, but I don't really want to be a d3d master just to draw some markers in the game, although I really want to be a game dev in my future. I need to go back to school, soon.

The spawn point models in Reach are sweet. I. want. that. bad. It'll get there.

My other idea was to just create custom model markers and their tags, then include these tags in the model rendering process in the engine without actually creating the object in game so it doesn't have any attributes other than geometry so it doesn't interact with the world. This seems easier and I might try it out but first I gotta figure out more of the rendering code and I how I can accomplish this. This calls for a talk with FireScythe if he even cares. I don't think anyone even cares at this point, I haven't received any feedback other than from dwood -- shoutout by the way, I call him DWORD LOL!

What do you guys think?

Anyway I am tired and done writing for now until next time. See you soon.

I don't have an Xbox 360 or Halo Reach, so I am blogging to see if anyone can give me some information about how some things work. That is if anyone is actually following my blog, ha.

I can successfully grab and drop objects through the menu options, but there are some changes that need to be made. First of all, I am checking if my camera angle is closest to an object using a constant value, sort of like a FOV. I am going to change this constant to the bounding radius of the closest object, because some objects are larger than others and it will work better overall. The IDEAL situation would be to do ray tracing. Pretend a line is being projected from the center of my screen into the game world. I want be able to tell if that line is intersecting with any triangles / vertices in that object model. That would be really accurate and just sick.

In Forge World in Reach, I know they do some sort of ray / line tracing from what I could see in videos, because it was very accurate. But how about distance in world position? Can you be half way across Forge World and still grab an object that is thousands of game units away? How close to you have to be to an object to do anything with it? I need to add a distance check, because sometimes I accidentally grab an object that is far away and get confused.

I have seen the Object Tools and Object Options differences..but in all the videos I have watched, not one person opened just the Tools menu. What is in that? Like if you're not editing an object, what do the Tools do? If anyone could go through the menus and write down all this information, that would be great! I'm not TRYING to copy pasta Reach, but it's pretty awesome from what I seen and want to follow it as a guideline for now.

Thanks guys and leave me some COMMENTS!! <-- It's bold, italic, underline, and red so it catches your eye and maybe... just MAYBE you will feel the need to leave one below. PEACE

Sorry about the sound volume, that's the loudest I could get it without being extremely up close to the laptop mic.

This is my first video blog and I wanted to talk a bit about Forge and get comfortable in front of the camera because I will be making more of these soon.

The video is quite boring, so bare with me lol! Full screen that shiz. :haw:

I was going to wait to blog again, but oh well. I have been having this random crash happen when I am holding an object in Forge when it respawns. The object is destroyed and recreated while I am still trying to modify the invalid data. Even though I have null pointer checks properly in place, my code is not syncing up to the engine to where my code knows exactly when this respawn happens. So, I messaged Kornman and had a very brief conversation before he logged offline. I asked him about the object update hook in Objects.cpp, because he had the code hook commented out. I ask him if it worked and if this would be the ideal place to update my object pointers, but he said he will only help if I update to the latest code base in the Google Code project. I can understand that since he is not working on previous versions any longer, but the hook is the same thing and in the latest code base, it's also commented out. I guess I didn't understand why I had to update for him to answer such a generic question. Anyway, I downloaded the latest copy of OpenSauce (that is not even officially released yet) and added all my Forge code properly. I really do like the way the tree is setup and how the components system has changed. Lots of little updates I noticed that make a major difference. It's great!

Bad news -- my code is crashing after porting it over to the new OpenSauce. Sigh. The ONLY change I made was adding the new Release() function to the Forge DX Component. Everything is setup properly and it is crashing in the IDirect3DDevice9::Reset() function call in the engine before the main menu even loads. I haven't yet tried a build without the Forge components. I guess I should try that and see if it's actually my code that is crashing, which most likely it is, but who knows right now.

Edit: A clean release build of the latest OpenSauce is still crashing. I will have to continue development of the last released version until I can get them to fix this.

Once I get this crash taken care of, I will be continuing work on the menu and getting it's basis done and then work on the object respawn crash.

Keep checking back for updates guys and leave me some fudgin' comments already!! :haw:

The OpenSauce project I was using for Forge CE was a TRAIN WRECK. I had all my reverse engineering work in this project as well and random stuff was everywhere that was not needed. It wasn't causing the crash, however it feels good to start a clean slate and know where everything is.

I started with a fresh download of OpenSauce and recoded the initial framework today. I reworked a few things so that I only had a few minor edits in original OS files. The D3DXCreateFont bug is fixed with the code reworking, whew! I have gotten a lot of the basic menu system done using TextBlock and using the _menu_globals struct as an outline for my menu key functions. I was just going to create a new instance of menu globals, but the file is inline and it kept saying it wasn't a part of the Menu namespace, plus I wanted to customize the functions more to my own menu's needs instead of just extending the struct.

One of the things I had to change in the original OS files was in the GameUI_Menu.inl file. At line 40, in the GetSelection function, I added a check to see if GetKeyState of the menu selection was equal to 1. Since I added a 'Forge Mode' option to the Yelo menu and always returned true in my AdjustSettings function, Forge Mode would flash on and off when I toggled it in the menu. If you hold a key down, it's state will iterate from 0, all the way to 255 and stay at 255 as long as the key is still being held down and 0 when it is let go. So if the GetKeyState function is checking if ANY number greater than 0 is returning, then my AdjustSettings function is constantly called even if I just quickly TAP the key. Checking if the key state is equal to 1 will guaruntee my AdjustSettings function is only run once per key press.

As well as the menu framework, I added the basic functions to move objects and it works exactly like the gravity gun that Kornman00 had created. It's pretty sick. I have intentions on making Forge in monitor / camera mode only, but it sure is fun carrying objects around in vehicles. :downs:

The rest of the night I am going to be working on the menu and hopefully have the Grab Object and Drop Object options done for starters.

Check back tomorrow night for another update!!

This is my first blog post and there will be many after this to come with my progress on Forge CE. I decided this is a more simple way of updating users of my work without having to sort through pages and pages upon pages of forum posts. Plus I am excited to keep a record of everything I have accomplished and it keeps me motivated to keep chugging along.

I am sick of not getting much done with this project over the amount of time I have had. I bet most users here have already given up hopes and they shouldn't. I just have had no motivation or I get distracted doing something else. I am a Halo engine reversing nut case and when I figure out something new in the engine, I buckle down on it for a few days or even weeks and lose track of what I was focusing on before. I need to set focus on one thing and one thing only right now -- Forge CE!!

As of right now, things are still in primitive stages. I am setting up the framework for the basic things necessary for Forge to function like the menu system. I am using the TextBlock class in OpenSauce as a basis for the menu. Through inheritance, I can extend this class to do a lot more and customize it to my needs without actually modifying or adding to the TextBlock. It's been crashing in the D3DXCreateFontA function and right now I am baffled as to why. I stepped through the code with a debugger and it seems like the device pointer is null, which makes no sense. The device is passed through the Initialize3D function which is used to create the new TextBlock class in the constructor. I even recoded the whole thing to match exactly how it was used in the Yelo menu and no go. I'll figure it out tonight, I have plenty of Mountain Dew to keep me happy haha! Beer sounds good right now, but I will get absolutely nothing accomplished.

:saggy:
Back to work.