Jump to content
Ultra Engine Community

Flexman

Members
 View Profile  See their activity

  • Posts

    916

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by Flexman

  1. Flexman

    Drivers again

    By Flexman,

    Seem to be having performance issues with the new nVidia drivers 257.21
     
    I noticed the reported OpenGL version has done up from 3.2.0 to 3.3.0
    Repeated launching over an hour will sap the frame rate to around 1, yes one. No apparent memory leakage. But other games are fine. Also the editor will remain unaffected unless importing the Apache model where it will sometimes exhibit a black skin.
     
    So there's some combination of factors I need to understand, the current Apache model with it's recent material updates and animated wipers and the new nVidia drivers.
     
    I wouldn't mind so much except it's keeping me of adding new content right now.
     
    I also spawned an LE 2.32 build to test, which on a small map runs 50% faster, on the full sized Afghan theater it actually runs slower. I'm at the point where I'd like to take a shotgun to my PC. The laptop has almost double the performance of my desktop PC which makes no sense, same build, engine and 257.21 drivers.
     
    *sigh*
     
    Source
  3. Flexman
    While I'm spending hours pouring over interfacing the flight model, AD has been tinkering with billboards again, finding a blend of shadows. There's still more to do, I want a ground fog layer, multiple layers, realistic light scattering and a more dynamic LOD system which we can't do yet. AD is reducing the tree poly counts from 1,500 to 500 on the LOD1s. This should improve shadow performance a little.
     

    Looking at shadows again, I came across a GameDev.net post that I might look into. It's similar to the shadow system used in Brano's Outerra whole world engine. I'm not sure what it would do to a high bandwidth environment like a 3 monitor wide system. Probably no worse that using HDR or other post-processing effect.
     
    Source
  4. Flexman

    Internal views

    By Flexman,

    Added some fixed internal views for 'quick' look downs and drama shots.
     
    Wiper dash...this has a little vibration.

     
    Pilot displays...

     
    Over shoulder...

     
    Pilot engine controls (startup and lighting)...CP/G similar (not pictured)

     
    Co-pilot target panel (TEDAC)...

     
    I think a 'foot-well' cam will come when we get a pilot model in game so we can see the crew looking around. And I think we could use an ADI/Comms panel view. Feel free to suggest a few more.
     
    Source
  6. Flexman
    Actually the rotor brake system. I'm not really clear what would happen if the rotor brake is off when you move the power levers from the Idle to Fly position. Procedures say DONT, return the switch back to on until the engines are at flight speed (approx 100%). Once the engines are happily settled at flight speed flip the brake off and the rotors begin to turn. Watch the rotor RPM gauge on the MFD until it's in the yellow close to 100% then you're good to go.
     
    Conversely, I'm not too clear what damage might occur when then rotors are at 100% and the rotor brake switch is is turned on. A lot of heat and grinding metal noise? A nasty letter from the Boeing company? Currently I just have it decay the RPM to zero under a constant until I get a better answer.
     

     
    I added more realism options to the config.xml for control over individual items like startup, targetting, flight model.
     
    OOOH, I just remembered why I was really happy today. AD fixed the road physics problem by using displacement mapping in 3DS MAX. So no hacky hacks may be required for road driving afterall. Well done sir. I knew I was feeling buoyant for a reason. If you want to know what the hacky hack means, the road surface was aligned to the terrain with a vertex shader which moves each point on the model level with the ground (relatively) but physics engines don't know what vertex shaders do to geometry, as far as they are concerned the model is unchanged. So there's a disconnect between what the physics engine updates and what the 3D card renders on screen. Using displacement mapping with our heightmap as source, the road meshes are baked at the right elevations to fit, the physics model and visual model are now united and traffic may now use the roads without any problems.
     
    So, way to go AD. Another cracking solution.
     
    Source
  8. Flexman
    Fingers crossed the weather is not too bad tomorrow at Gilze-Rijen air force base. Our man in the Netherlands is prepared for a day of audio recording for the Apache and Chinook.
     
    Good luck Reck. Weather is pretty lousy here, high winds, low temps and rain, sat images and forecast is so-so. Expect wet weather and don't forget the 'dead cat'
     
    Source
  9. Flexman

    Command Tent - wip

    By Flexman,

    We're not trying to re-create Armed Assault, or even build some form of Helicopter MMO. Our plan is to take the old school 2D interfaces of military bases and create 3D analogues. Mission assignment and planning is done in the command tent. This is still exploritory, we have a number of office furniture elements planned, some of which we have tried in the editor to get a feel.
     
    There's more furniture to come. A mil-spec laptop/terminal, interactive map on a board (that's a copy of your personal map - will use the same buffer).
     
    And eventually we hope to have various AI pilots sitting in on briefings that you might want to converse with Wing Commander style. Romeo 1 from the intro mission will be hanging around. Along with WO J Petersan and others from time to time.
     
    I don't have much time to decorate, just placing these objects around my test-map to check how they look and function but it should give you an idea.
     
    With a couple of AI guys and a co-op friend there should be enough room to keep it looking busy. It's possible we might make AI crewman choices ala Gunship 2000 available in this manner if it works.
     
    We need some flooring I think. Hexmesh or some other plastic matting.
     
    Using a projected texture for mission briefings on the OHP. Interacting with a screen set 5 meters away is problematic, once at the projector you'll get to interface which will allow you to view available missions and annotated map, with a "close up" option (position a 3rd person cam up close to the screen).
     
    Like with other parts of the game, such as arming, the player interfacing with the projector will have their data shown to everyone else. Allowing you to give briefings. If there's time we might add a laser pointer for mouse control.
     
    We're using a 1024x1024 buffer for the projector which is a material assigned to a special spot_light entity parented to the OHP model. Objects/avatars walking in front of the projector have the image mapped over them in a realistic manner. So you too can act like a right tit in front of the C/O making shadow puppets with your head.
     
     
    Additional objects in the command tent will operate on a private level, mission planning and editing will work on a laptop type screen and a wall map will be copy of your pop-up map. There may also be a Sierra Hotel score board, I think that's required by tradition.
     
    So this the the start of the important ground office in Combat-Helo. We tend to have about three different project elements on the go at any one time, rather like making a series like Star Trek, planning, filming and pre-production.
     
     
    Finally a recent ETADS screen-shot, taking a peek at a sign through the trees some distance away (it's way off to the left out of sight so don't bother trying to spot it). Some folks will be well pleased with the corners. This coming week I'll be working on the event system (delayed due to PC technical problems, see earlier blog posts) and more of the TADS elements.
     

     
    Source
  10. Flexman
    Compounds, the Herat map contains approx 500 of them. Each one consisted of a number of walls and out buildings. Turns out, these sub objects chewed through a bit of processing time. In effect there were 7500 objects getting worked through. That's a lot and it was reflected in the performance in LE 2.31 on a fully dressed map.
     
    By collapsing the compound models into a single object for the lower LODs we saw a large increase in fps in LE 2.31. Although LE 2.32 shows not much difference (it's a better performer anyway) due to it's quad-tree culling system. Even so there lots of fine tuning to do, cockpit switches to be instanced, general code trimming. Entity view ranges, material combining and a dynamic detail function to add.
     
    Today I've been working on fixing the lighting buffer for the cockpit entity but I'm having problems copying the cockpit buffer into the main view buffer. Much strangeness, it's some alpha/blending issue I can't quite get a handle on but I'll get there.
     
    I spent some time looking at Open-flight as a specification for storing lots of scene data. It's not really designed for high efficiency 3D engines. And not surprising that other engines that use it have adopted some conversion process. Initially the idea was sound but on closer inspection it's just plain awful. Maybe I'm missing something in the organisation and construction of individual objects.
     
     
    Here are some random shots from today.
     
    Cockpit interior now moved to it's own world for rendering lighting. Materials are not happy but it's steady as a rock. You can see the GPU terrain mesh with it's 10 meter resolution rendering a DEM of mountains in the NW of Afghanistan.

     
    Not much to say about this. Pre optimisation and post debug slowdown. Not happy at all. It was just this slow on my dev machine. My laptop is much happier.

     
    The saturation and contrast levels adjusted on the "fly" can change the look of the game.
     

    I like heavily saturated games which is probably due to my first colour computer, a Sinclair ZX Spectrum which was a train-crash of colours, all eight of them. I still have one of the later models hanging around my desk (see photo I just took below). This one has an Interface 1 for Microdrives. If you don't know what they were, have a bit of fun and look them up. Strange to think that that kind of technology is still used as a backup system today. In the 80's my first games didn't get very good reviews, we had a laugh looking them up on the internet last week. They would make good mobile games today I think....hey I just found my keys.
     

     
    Source
  11. Flexman
    AD has been finishing more of the villages and green zones around the region. You can read more about it here...
     
    SimHQ Dev Diary update
     
    This is "Dara" in the Northern region (See map below)

     
    Source
  12. Flexman
    My wife reminds me that it takes typically two weeks after each engine upgrade to get things working as intended.
     
    There's the odd "caps sensitive" issue in some of the LUA source. And a quick change of fw.Main to fw.main in Renderer to get ll the helo/sky scripts working. Rebuilding the lua-gluefunctions and making sure not residue from the previous version was causing problems.
     
    All that's left is handling changes of appearance and shaders....and re-serialising all of the 3D work.
     
    Performance is fantastic almost doubling frame-rates in our vegetation heavy scenes. The vegetation rewrite has been well worth the effort, with collisions and lighting changes. More varied lighting does a lot to reduce the uniform appearance at range. At least I hope the lighting variations are intentional and not some shader problem. The evening skies came out purple in the new version for some reason, now I really like this colour. It reminded me right away of the
    . Nailed the colour palette. 
    The downside is the need to re-export all the 3D work. The cockpit simply doesn't work anymore except for a couple of buttons. Interestingly the weapon arming only 50% works too, that uses linepicks also. And the upfront controller material has a normal map smeared over it. I'll have to look at the materials for these, make sure it's not using one.
     
    And the occlusion culling is a little problematic. Half of the cockpit vanishes at certain angles and the helipad and radio towers vanish, and when they do other objects tend to go with them. Those are typically large objects, the helipad is often positioned so it intersects the terrain. It's all very strange and interesting doing these updates
     
    I'm hoping a lot of problems are just down to the need to fix up the 3D assets. Some behaviours have changed, Coronas, I used as hazard lights are so dim they are hard to see. Also the sun as represented by a Corona, now seems to have been flung from the heavens and lets you 'walk' around it. But is still rendered in the background world.
     
    In the mean-time while I go through those assets I'll continue work on the current 'stable' build. I've added config options to set the server and port address with an 'auto join' flag to start the client mode after game load. The 'radar' dish (pictured above) is another interactive object that gives access to multiplayer options. Start Server / Client Connect and an as yet unimplemented address-book.
     
    I'd like to thank AndyGFX for his posts on migration issues past and present that helped enormously, and also Macklebee, Red Ocktober and others that have also been posting their issues and solutions.
     
    Source
  13. Flexman
    The game world clock is now synced across network clients, time advance and day-night cycles locked. Accuracy is down to round-trip packet times plus a few milliseconds. More than enough to keep entity spawn times and waypoint navigation in close sync.
     
    I'm as yet unsure how often to send clock updates, currently it's every half-second which is quite aggressive, it's easy enough to tweak. Clocks run on client and frame-rate independent so they don't need to be updated often. They just need the occasional time sync from the host or when the host is changing the time-of-day.
     
    Chat channels work well, need to add the player name to the prefix. We have a player profile set in the game config but this carries no player name or any other data as yet.
     
    Almost ready to test that NAT punch-through.
     
    Source
  14. Flexman
    Another "gravy" feature which I wouldn't have spent time on had David (part man, part 3DSMax) hadn't made it so easy. He detached the existing low res wipers from the exterior model and created a single 100 frame animation cycle of both wipers complete with slight wobble. The two blades operate at different speed ratios too.
     

    The cockpit wiper control was set to send it's setting as a key to both the exterior and interior cockpit model. Allowing for dual speed wiper control and a park mode (turn off and wipers return to stop position at end of the next cycle).
     

    The ETADS display had it's round inner bevel reduced and is much more square, you can make that out as the bright green screen in the above image. Also the cockpit instrument normal maps were edited to remove raised lettering and other markings that were out of place.
     
    My project planner has me working on the generic event system (GEST) for the next four days. This is a new dependency for completing the start-up procedure and mob animation.
     
    Source
  15. Flexman
    The 3 active IR-LED head-tracker clip was never made of study stuff, constantly falling apart as soon as you put it down on the desk. Now it's finally disintegrated, I might have to resort to super-gluing the tattered remains.
     
     
     
    Microsoft Kinect apparently shoots out hundreds of IR beams in a grid pattern and uses that to build a set of data points from which the software can pull out a skeleton, track body motion. It's a motion capture studio in a box. Brilliant, for indie game production I like the idea of using it for creating motion capture files.
     
    Source
  16. Flexman
    Periodically I'll create a debug build to see if any OpenGL errors popup and sure enough one did. Tthe MFD buffer mip-maps are created after rendering the contents with a call to buffer.GetColorBuffer().GenMipMaps()
     
    Not much had changed except some additional meshes, animations, all the specular maps, actually quite a lot of material changes to the interior and exterior this past week. But the debug ran fine after building and running it on the laptop. My desktop wasn't having any of it.
     
    EF2000, EECH Enemy Engaged Comanche Hokum and others, not working right? Please update your drivers. So what did I fail to do on my desktop that I did recently on the laptop (due to installing a Windows 7 upgrade). Yup, update my drivers. And lo, all is now well and good.
     
    The moral is, always heed ones own advice. Check your drivers.
     
    Still a little curious as to what was wrong with mipmaps in those drivers. I wonder how well auto-generation of mipmaps are supported across cards and is there a safer way to test it?
     
    Source
  17. Flexman
    The HMD of the new MTADS Apache comes with a number of 'virtual' items displayed to the pilot. The currently selected waypoint is made virtual in cruise and tranistion modes, the waypoint position is marked with a flat bottomed diamond with a dot in the centre. See the take-off point (W00) on the image below.
     
    Flying with the flight path marker inside this symbol and you should head right to that spot.
     
    Waypoint marker
     

     
    Source
  18. Flexman
    At no point before have I felt so much under pressure as I do now. Hence the lack of blog updates. The new physics engine is still being problematic but these are issues relating to -ff-math and tracking down typos, the odd logic error and other errors that occur when programming.
     
    In a flight model, such errors result in numbers quickly blowing up, which they do. So I'm currently tracking down each issue, one at a time until, eventually, it should just all click into place.
     
    I finally configured my Combat-Helo input map for my Saitek X52 and apart from my shocking oversight of an inverse axis option it was a nice experience using the old mk1 flight model. It's frustratingly hard to get up to speed and it still flies in a nose down attitude. I may fix those points and retain it as a 'rookie' flight model.
     
    All this debugging and testing is taking up all my time, the goal is to have it in place for the show on the 28th. It's looking hit-and-miss atm. We're supposed to be working on some FSX stuff as well but that's had to take a back seat due to holidays and other things. Hopefully will be able to spend some time looking at that in two weeks time.
     
    AD did well finding an OK solution to paved roads. They work, efficient but they require a lot of work.
     
    To quote...


    Just to elaborate a bit. The key component is a vertex shader that takes the Z value (height) from the terrain and applies that to the Z value of the road vertices. The road itself is built in 3dsmax as a primitive mesh, a meter high and 20 meters wide. It's flat and the vertex shader sets the height at the end of each section of road.
     
    40960M's of road can be bought at the cost of about 2500 polys which is outstanding in comparison to the native road system which costs tens of thousands of polys for short distances, doesn't work most the time, creates massive slow-downs, and flickers like a 1950's TV in a washing machine.
     
    The only real down-side is the amount of work it takes creating the road mesh itself. It took me about an hour to lay down 10KM's, debug the path and smooth-out the ground underneath it. Therefore it probably won't be a suitable method for the dirt roads. I would add that the native road system is fine for small areas, it's perfect for small FPS style levels but non-instanced geometry will always have a huge performance hit if there's a lot of it.
     
    Using static meshes for the road system makes it easy for collision testing to flag "onRoad=True" and the model can use this value to adjust sound and emitter properties. For example, running across sand will sound different to running across a road surface. More dust will be kicked up. Those things are more complicated to do using texture splatting or a giant texture overlay to represent these kinds of features.
     
    Here are some pics of the roadworks.
     



     
    Source
  19. Flexman
    I'm putting together specifications on the mission side of the game. To me, the bit that you 'play' is every bit as important as the simulation side, and while it's taken a back seat for now, things are getting to the point where it's time to get on and make it all work. Going through some of my older material on this, it needs to play like Longbow 2, have the crew management elements from Gunship 2000 and strategy elements from tactical board games on guerilla warfare and a bit of a story element that wouldn't be out of place in a Chris Roberts game.
    So where do we start? Units, missions, events and triggers.
    Units perform missions, missions contain waypoints, events and triggers. So lets start at the top and work our way down.
    Missioneering
    Not many will remember the last iteration of my mission planning tool and generator, Missioneer Delta pictured below, circa 2000, seems like almost 10 years ago :/

    The plan is to put in something similar onto the command tent terminal you can operate to change waypoints and assign untasked airCREW to helos to carry out listed missions. In some ways this is not unlike Enemy Engaged. Missions are not necessarily assigned to aircraft (they can be), but we'll assign them to the player, AI pilot or crew. Like the arming system, it will be possible for a player to take the role of a commander and assign missions to aircraft that pilots execute.
    You can walk around and choose an aircraft that's not already assigned (see it's info plate when on foot for status). In future we hope to have a selection of helicopters/vehicles (CH-47) but we're focused on the Apache.
    When the player boards the aircraft, this is like loading a data cartridge with your mission detailed into the aircraft's avionics. The TSD will be updated with waypoints, times and mission page populated accordingly. First man in sets the mission.
    The mission ID# key is set in the vehicle entity. This is reset on one of two conditions, the player has exited the aircraft for 5 minutes or the master zeroise guarded switch in the cockpit is operated. In the case of the latter, a new mission profile can not be loaded until all crewmembers have exited the aircraft.
    Mission ID# is just a key reference to the hosts list of active missions which can be viewed on the command tent terminal (connected to the projector).
    But we're getting ahead of ourselves. Missions and units need a detailed specification which is the point of this blog entry and my current task.
    Running under the surface of the simulation will be the all important campaign engine which iterates through units. We'll take the term UNIT to mean a collection of vehicles, a "group entity". Lets look at an old user editable unit form, take from Missioneer. Nothing really remarkable about it, just happens to be handy.

     
    So we can see some of the basic parameters of a unit. There's a list of entities than make up the unit, a 'formation' which is a list of relative positions that each member of the group will attempt to follow (we'll have some behavioural exceptions to this). An orientation, direction to face when at rest. A name, something fancy and military. Skill level, agression and some factional information.
    There are also some timers, our game runs in a real-time 24 hour clock cycle (with time advancement). So unit timers might be relative to an absolute time (world time) or mission time (from dust-off). Timers have an enabled/active status too in case they need to be activated by triggers.
    For example, if we want a group of insurgents for player assigned patrol mission to spawn when a player has taken off, the mission engine will assign a MT (mission time) of "00:00:00mt Active", but we might want them 5 minutes into the mission, or not spawn at all except by some trigger, such as a player entering the engagement area.
    Or we can set the unit destruction time (just means the de-spawn time). For example, a rescue against the clock, get to them before they are discovered by encroaching insurgent forces. Once depawned, that would trigger a unit removal message which another event trigger can listen for, signalling a mission fail.
    So timers are simple unit level events that require no special handling by an event system. But for our game to handle recognition of a "win" or a "fail" situation we'll need to add a basic "cause and effect", a "cause" being destruction of unit "x" with the "effect" being "mission complete".
     
    Mission Events
    SpawnUnit (unitID) DestroyUnit (unitID) SetUnitWaypoint (unitID, waypointID) SetUnitFlag (unitID, active|weapons_free|godlike|formation|state, param) SetUnitFaction SetMissionResult SetWorldFaction( factionID, delta) SpawnObject (objectID, parameters) CreateWaypoint (unitID, waypointID, location, speed, altitude) Play Audioscript (script or audio filename)
    Mission Triggers (in any active combination)
    MissionRating (percent, win|loose|draw) MissionTime (+ - secs, MT|LT) UnitDistanceFrom (unitID, targetUnitID, distance_meters) UnitDamage (unitID, damage_percent) UnitWaypoint (unitID,at|before|after, waypointID) UnitStatus (not_in_combat|combat|flee|panic|landing|takeoff) UnitInZone (unitID, zoneID) FactionDelta (factionID1, factionID2, + -value) DiceRoll (percent)
    These are enough for the campaign and mission system to generate pretty much most situations.
    Now the tricky part is to build the logic to generate seemingly intelligent behavior and entertain missions using this small command set. And here is where we can have a lot of fun.
    We could extend the complexity of the logic further by adding a LUA Get/Set interface for the event system. Then user made missions can apply some complex logic. Even creating whole missions from a LUA script. This is not something we want to do at this time. But for the future, it could be done.
     

     
    Source
  20. Flexman
    Another little progress update but first a diversion. Yesterday I took some time-off to brush up on gaming skills and really enjoyed Disney Interactive's "Split Second", one of the few car games I keep going back to since I typically find racing games tedious (lack of skill and patience on my part). However this game is almost pure adrenaline and I find my self coming back to try and shave off 2 seconds while avoiding exploding aircraft and collapsing control towers. Split Second is actually the perfect arcade car game IMO and probably much overlooked in a busy genre. It screams for a post race replay option though.
     
    Enough digression. Not much to show yet as I've only spent an hour or two on it this morning, I hadn't put in the VR cockpit data for the TSD buttons so went and put that data in. Had some color issues down to a mix of LE and OpenGL and sorted out the MPD scale for rendering the currently loaded nav map image.
     
    TSD stands for Tactical Situation Display
     
    It is the most complicated system in the helicopter. Which I will strip down to the bone for the first release otherwise I'll be at it for months. The TSD presents a 'Gods eye' view of your helicopter and your environment. Downloaded target information, friendly unit sightings, route navigation and more is presented here. It is a moving map system that can be frozen, panned and scaled.
     
    I need to slim it down into something manageable. Also there are many functions that are desirable to use in the command HQ tent planner and also other helos in future.
     
    Our TSD will feature
     
     

    Fire zones (aka PFZs, old school but everyone will want them) Route editing Threat, target and hazard objects Nav and Attack mode (PHASE) Freeze, panning, zoom Crewman cursor acquisition, click on map and point will be made virtual in the helmet display.
     

    So there's a few things to do but also shared with the ground planning system on the HQ tent computer.
     
    For the base map, it's using the TTerrain() object on the loaded terrain entity (I needed to cast it to get access to the height and normal map data otherwise it's considered a TEntity). A shader converts the normal map into an intensity multiplier ( float intensity = dot( normal , lightdir ) ) for the colourmap, multiply the diffuse and intensity and voila you get a shaded relief map just like the one in the Leadwerks editor (except I don't need the realtime light position and colour that the editor uses).
     
    To this I'll add a colour lookup table from the heightmap and possible some contour lines. I've not used an "lut" function (look up table) in a shader yet so it will be a fun little exercise. Contour lines could be done by setting output colour if the heightmap value is a multiple of 10 (meters) or whatever value I pass to the shader. This just colours the pixel if the value is in that multiple, steep terrain might bypass that value so results will be a bit patchy depending on the source data. I'll look into a proper contour function.
     
    Keep in mind the heightmap in terrain doesn't have a flipped y axis.
     
    Source
  21. Flexman

    Mossie concept art

    By Flexman,

    Just a short post since I'm busy being pulled in a dozen different directions; I got roped into helping someone create a short health and safety film, drafting a project proposal, raising finances and even managed to fix a long standing bug in Combat-Helo. Now the sensors, line of sight and all that guff is now WORKING again, Hooray. A quick background on that, an engine update needed to fix some occlusion issues slightly changed the Model hierarchy in a subtle way that changed how actual filenames of models were retrieved, long story short, they no longer matched the ones in the vehicle database as they had "lod1" suffixed to everything . But hey it was a quick fix once traced, I digress as usual.
     
    Talented Paolo, creator of many a fine mascot has been working on some fictional nose-art and patches for the squad mascot in Combat-Helo. We knew we wanted it to feature a mosquito, the mosquito is the nickname allegedly given to the AH-64D by Taliban forces. Incidentally it was also the aircraft my father was attached to during World War II so I felt it had a double meaning.
     
    The character will be visible on squad patches and eventually be available as nose-art.
     
    "Mossie" copyright 2012 Paolo Pomes
    Below is an earlier draft of "Mossie" to help decide on nose style, the nose later became the Apache's signature Bushmaster cannon.
     
     



    Please post your thoughts and comments on "mossie", suggestions for what he can hold in his left hand are invited.

     
    Source
  22. Flexman
    Had a quick play with Saitek's DirectOutput SDK, results are mixed but not bad. The MFD resolution in Combat-Helo is a native 512x512 and the Saitek Flight Instrument Panel is VGA 320x240, there's a bit of difference.
     

    Sampling the buffer down to a smaller surface and then adding a suitable BMP header to send over to the device. Remarkably easy. I'll have three more please Saitek
     
    BUT please can you make an FIP version two with a 512x512 square ratio display? Or at least increase the vertical resolution to 256?
     

    Text is near impossible to read, but the general layout is recognisable. I don't know if we're going to support these devices in game, it's just one more thing to go wrong and support, and the default button locations don't match up so it would need code to move functions over to the left side, there are only 6 six buttons. But it's interesting to play around with.
     

     
    Source
  23. Flexman

    WEP page (advanced)

    By Flexman,

    This is OpenGL, vector based rendered to an offscreen buffer, now with added mipmaps. I'll try and detail the functions of these pages and sub-modes as I go and allow you to submit corrections early on.
     
    The WEP (weapons) MFD page
     
    Pictured below shoing the gun sub-mode. Main feature is the bust limit selector on the left side indicating the number of rounds fired when the pilot commands. The bottom MFD buttons marked GUN, MSL and RKT will switch the weapons and display rounds and options. Stores and gun rounds to add to the display. Will complete tomorrow. The only other notable feature is the ACQ option (R6) to switch the gun aiming between fixed and TADS.
     
    The buttons marked with and arrow above (see top row) are for navigating to different pages. The bottom right button indicates the current page (WEP boxed). Next to that the selected sub mode (GUN boxed).
     

     
    Source
  24. Flexman
    Dexsoft's Middle East City pack has been tweaked by the Dave-9000 supercomputer and has produced a low poly high density city block of 1038 polys. Requiring heavy edits of UV co-ordinates and placing all the textures onto a single surface for blinding performance.
     
    Perfect for iPhone and as a building block of the high-density city of Herat.
     

     
    Source
  25. Flexman
    We've been using the black and orange diamond logo for some time, it needed to reflect the game colour palette. As a 90's homage to sims of that era, a saturated colour scheme with the GUI elements using 90'-45' angles, black and orange. Two contrasting colours that are visible against most backgrounds.
     
    It wasn't until after I had designed and coded a number of elements that I noticed other military games using the same colours.
     
    Why bother with stuff like splash screens at this stage?
     
    They set a tone and expectation when showing demos, fix the colours and facilitate feedback on identity early on when things are still fluid. In our case, we have possible issues of copyright and licensing, issues that came about through the process of establishing identity. Matters that are hardly trivial.
     
    Plus the above vignette style works much better on multi-screen monitors when centred than the old one which was stretched. This has better overall presentation. Logo is still in flux but overall colours and shape are there and reflected through the whole game in every interface element.
     
    Source
Copyright © 2024 Ultra Software.
All rights reserved.
×
×
  • Create New...