NOTE TO JON: Fix the avatar and personal pic upload problem please!
Hey there, I’ve finally managed to completely implement skydomes into our game engine. It took me a while to finally get rid of all the kinks that were slowing the final product from being finished but now its all working! The visual display is quite good, but theres a bit of re-working to be done on making it look good a long with any scene we wish to use. The hard-coded scene we have now isnt really going to be used if I can do anything about it in the coming weeks. I’ll give you a summary on what I’ve done to finally get it working in the last couple of days:
Outlining the changes made to the project…
1) Modified AppModel considerably to reflect the changes made with SkyDome and how its handled. Also got rid of a lot of misc crap that was unnecessary.
2) Modified WinMain to reflect changes made when shutting down game content.
3) Made some changes to Vector3 in regards to how its public variables are handles and so forth. Also added in a bunch of new methods and operator functions I thought were necessary for future works.
4) Made minute changes to RendererOpenGL.
5) Changed the formatting and handling of if statements in ColourStructs.h
6) Made some considerable changes to SkyDome as necessary to stop the buggyness of the code it was before.
7) Made a minor change with SkyShader and the handling of if functions
8 ) Made a minor change in TGALoader which now allows the user to specify whether or not they want a texture (rather than just the file) flipped when loading content.
9) Updated vertexSkyBox since I thought the use of glDrawRangedElements() was unnecessary and I think I was doing it wrong anyway.
10) Updated the project exec.
NOTE: Sky domes now work in our game engine! This is quite a step forth in the production in our game and the look we’re looking to go for when dealing with out door environments. I for one really wanted this thing working and so spent a lot of time slowly (very slowly) debugging through code and finding every single problem there is with the code and rectifying it.
It took a fair while, but I’ve finally managed to get it done. Hooray!
Yeah, I’m quite pleased with the result although when the stars are generated the do something weird, I’ll figure that out later after I’ve fixed other things.
Onto another cool feature that I’ve managed to successfully implement into the game engine. FINITE STATE MACHINES (FSM)!
Yeah this one was a bit of a bitch to get going but it all worked out nicely. It was also for an assessed workshop we had in our class and so that mostly motivated me to get things done. It took a while and I practically spent an all nighter to get it done since I had to do it my way and my way is the best way (in my opinion =p). Overall it was a success but the logic was shit since I couldnt be bothered making it any better, we just had to demonstrate its usefulness, theres no way I’m going to be spending a lot of time on workshops and so forth overdoing them when all you need to do is just demonstrate the basic principles and get full marks anyway. Thats one thing I learned the hard way last year. Do things, do them right, meet the assessment criteria, don’t do anything more or unnecessary and think you can scab more marks. It doesn’t work that way and you’ll just end up burning yourself out…
Anyway a summary of what I did in order to get the FSM working!
outlining the following changes to the engine…
1) Updated GuiManager, it was linking RendererOpenGL when it clearly didnt need to.
2) Ditto with MainMenu
3) Updated RendererOpenGL.h it had some minor errors.
4) Added the LUA dlls to the project
5) Updated the debug version of the LUA libraries again. It still was giving me build errors, hopefully this one wont!
6) Added two new classes which will be helpful in determining the usefulness of LUA in our game engine (taken from the week 5 workshop)
7) Updated the project exec.
Outlining changes to the project…
1) Updated several classes (formatting was incorrect in some parts and other things….)
2) Still developing a FSM (Finite State Machine) that will incorperate LUA into the game engine. This involves a lot of work and there is still much to be done. There have been an abundant amount of classes created with more to be included soon. After all is done, the FSM should run fine….
Outlining the changes made to the project….
1) Made MASSIVE / EXTENSIVE / INSANE changes to the Project.
Everything now compiles fine without link errors but I have still yet to test the bloody thing! Hopefully it will work! and no run time errors will occur! HERES HOPING!
2) Made changes to several files. Basically changed every LUA file I’d created and then some.
3) Updated the GameTimerHighPerformance class to be the one and only timing instance.
And thats about it! A LOT OF FUCKING CHANGES HAPPENED, NOT TO BE UNDERESTIMATED!
Outlining changes to the project…
1) Modified everything so that there are no problems with the finite state machine, only logic errors….
Works well and suffices for the workshop, when implementing the proper stuff, logic will need to be changed completely.
I wont bother listing the amount of classes I wrote, but overall I wrote around 20 classes and somewhere close to 2700 lines of code to get this thing working.
This marks another step towards my game engine and the usefulness it will offer when we start making our game. I’ll be endeavoring to actually getting the scene graph working as well as fixing up a lot of the rendering problems associated with it. I think that once I’ve successfully implemented the scene graph it will help solve a lot of problems that I’m currently facing and allow for a more robust engine.
I’m also thinking of getting spherical frustum going in order to blot out any other geometry that I’m rendering to the screen since the game is still quite slow on other computers. I’m also going to be spending time on finding out the reason why my game runs so poorly on lower spec computers. There is a tremendous bottleneck somewhere and I’m going to find it out.
I’m also going to switch my view on a lot of things and how aspects of the game are currently handled. I’m going to be switching some of the stuff which can be considered as ‘environment’ variables and change them to singletons if feasible. This is because singletons are useful depending on what you need to do and are better for lower spec machines as they don’t create the need to re-create objects, its not a design that I favour but its useful in games programming.
Heres a screenie of the game so far (NOTE: It looks kinda crappy since I have all the debug stuff going and the floor is black at the moment, real-time viewing is a must since its animated and so forth).