A downloadable game for Windows

The game in it's current playable state. The updates are frequent, but I can't imagine the final release and content as of now (although you can get your fair bit of fun out of it even now).

As an (unwilling) prototype fighter pilot, you are trapped in an endless testing facility, bad for you. They don't know what you and the machine you pilot are capable of, bad for them. After your escape attempt the defense AI is ordered to destroy you, but can not break your shields - yet it's silicon brain thinks it deals damage as long as it can register a hit, forcing itself into a loop of trying over and over again... then break it by not taking a single hit! Wiping out waves after waves of never-ending drones while dodging the stream of projectiles, you make the AI logic advance further and further, and the enemies more fierce, - with a hope it fails at some point, granting your escape.

Ever wondered what a classic side-scroller would look and feel like as a detailed simulator? Now you'd probably know :)

  • Full 3D: no sprites, no overlays, particle-based pyrotechnical effects.
  • Infinity concept: no overflowing or accuracy-degrading variables, truly infinite environment, the death-restart approach replaced by the repeat-until-not-hit one.
  • In-depth simulation, including realistic (yet still sci-fi) and detailed weapon behavior, controllable and complex on-board computer and a "fun-realism" flightmodel with evasive dashes and alike.
  • Advanced custom graphics engine featuring true HDR, area lighting, raymarched displacement mapping, large-scale particle systems and realistic fully-procedural camera simulation.
  • High performance, very wide range of detail-level tweaking to suit most hardware configurations, from lower-end laptops with integrated GPUs to high-end gaming PCs.
  • Flexible gamepad and joystick support.
  • Optional cross-eyed on-screen SBS mode (using a special frame correction technique in order to make the image not appear blurry nor doubled on the larger screens).
  • Native stand-alone PS VR support, no additional software needed. Includes an option for adaptive reprojection to seamlessly switch between 120 and 60 internal-FPS modes (both with 120 Hz sensor-based image updates) depending on the hardware load.
  • Built-in support for the standard CUBE video and photo color grading lookup tables (LUTs) along with camera signal emulation (with various device emulation modes and custom device curve support) and post-process dithering.

Install instructions

Extract the archive and run the executable file you prefer, the names are self-explanatory. The files ending with "_32" are the builds meant for the 32-bit systems.

The "config" utility is mostly straightforward, although do not expect the values for the HDR passes to give the best image when all set to "max", as what they affect are the blur ranges. Be aware that the stereo builds ("_VR") all use a separate configuration file, "config_vr.cfg", whenever available, and non-default configuration files can be opened by the "config.exe" utility via the standard open-with mechanism or by drag-and-drop over the executable itself.

The on-board computer (accessed by a key bound as "Console" in the configuration utility) is a (skippable) part of the gameplay, and I recommend reading the command list using the 'CMDLIST' or 'HELP' commands (or type "DUMPHELP" to store the help file to the game's directory). The possibilities are wide, from toys like instrument cluster tests to customizing the HUD or the MFD, using a built-in music player (including a BASS-based one) and activating some other interesting features. If you don't like to type too much, the Tab key acts as an auto-completion trigger.

Any stereo mode has to be set up first, that is achieved using the "Display alignment" button in the config utility. The cross-eyed mode requires no special hardware, yet you should know how to watch the cross-eyed stereo images. The PS VR modes can be activated from the same window as well, in that case the values like the screen size will be ignored (but the interocular distance will not be). Be aware that for using the named headset you still need to install a WinUsb-based driver (with the easiest way being by using software like Zadig), and set the HMD into the 120 Hz mode (or the 90 Hz should you prefer it this way, yet be careful as the refresh rate must match the one you chose in the "Display alignment"). The named headset also needs an offset calibration which is automated, just leave it on a stable surface when starting the game (the splash screen will read "CALIBRATION DONE" when finished). If you feel like the old calibration became too off, you can always re-calibrate the sensors in the same manner, in this case the "HMD CAL.SAVE" should be input into the in-game console to overwrite the previous calibration. The other options are also accessed with the "HMD" commands, to store the reprojection thresholds, if used, the "HMD CAL.SAVE" is also used.

Download

Download
ProjectConstraintBuild080721_rev5.zip 111 MB
Download
ProjectConstraintBuild080721_rev3.zip 111 MB
Download
ProjectConstraintBuild080721_rev2.zip 111 MB
Download
ProjectConstraintBuild220221rev5.rar 108 MB
Download
HMD_PowerOff.rar 10 kB
Download
https://drive.google.com/file/d/1Hm09Ju7hI1qM9m_x8-rDisX0ENC5SUPx/view?usp=sharing

Development log

View all posts

Comments

Log in with itch.io to leave a comment.

Do you have a plan to support Directinput controllers, because many HOTAS joysticks or 6DOF joysticks are directinput.

I guess I should, although I need to get one first :) A little busy atm however, and first I badly want to do some tweaks to the particle system controller (almost finished in fact, will allow to fit things tighter by generating systems of a lower quality whenever the one requested does not fit into the buffer instead of skipping them altogether in this case - this is a neat touch for the lower-end GPUs where you would just limit the buffer without the need to set the effect quality that carefully).

(1 edit)

Well, slowly getting it to run (hope to finish till this weekend) and got a few questions. At the moment I got the enumerator and the binder running, able to attach basically whatever is in the DI-standard joystick structure. The actual control, response curves etc are ready as well, and I'm mostly cleaning the stuff up. Unlike the XInput support from the current build, the DInput will not be multiplexed, but will be additive instead (as, opposed to how a gamepad can be used to control a real-life drone, and can be used as a complete control device here therefore, a flightstick may lack the ability to do several things unless in conjunction with a keyboard). And, FIY, yes - the selected device can be registered for future use, where it will start automatically (not really portable tho I guess, as stores the device's GUID) - the layouts are portable however, as are stored in separate tiny files named after each device.

Now, for the questions. So far I made it select a single device (for which it loads the control map as well, which you can edit in-game) and run like that, e.g. the keyboard is always available, mouse available whenever the axis pair meant for the yaw and pitch is not bound completely (for an obvious reason), and discrete, axial and POV controls, should they overlap, will be properly combined (yes, you will be able to bind a button as, say, strafe left, an axis for horizontal strafe and a POV switch to both strafe and ascend/descend all at the same time, and any combination of those will be correctly parsed). Should I leave it like that, or do I have to (won't really take that long I guess) make a control stack as well, allowing to assign and use a few DI devices at once (in this case you'd have to assign devices like #0...#something, where the layout of device #1 overrides the one of #0 in case of a direct overlap - say, if both are bound as "axis X", the one from #1 will be used, but binding one to strafe_x, and the other to strafe_left button is still combined - and so on)?

Also, about the deadzones. Should I rely on the DI ones, or have an own dead-zoning in software instead (atm I only tried the latter, just like with XI)?

i think second examplel would be better so users can make a profile of multiple controllers easily. I use an arcade stick for strafing,l rudder pedals for moving forward/backward and anything else for flight stick.

many controllers offer third party software to configure deadzone, but it would be better to configure the deadzone in the game.

Guess should be fine by now - the current build runs a stack of 4 devices (guess the biggest sane setup would be two sticks, pedals and... don't know, some switch pad, maybe? - can't think up anything else so 4 feels just right) added by "DI INIT #". The binding mechanism is mostly the same as before, all four are saved for the later starts using CONF.STORE. Yeah, yeah, overlap priority, dynamic disconnects and manual pause included :)

Wauw this project has come far. I never noticed that there was a command screen haha. I like the arena tunnel. I would really like to see a targeting system much like in star citizen. Like when your cursor moves and the ship then follows :)

(+1)

Oh :) Although completely optional, the command system is a very immersive part of this one, mostly being like a configuration interface for your war machine. And yes, you can actually customize the heck out of it.

For Star Citizen, I actually never played it. Is the targeting feature there working like "you put the crosshair where you want to face, next the ship aligns with it (returning one to the center of the screen)"? I can try, by the way you can check the "MOUSEDELTA" on/off command which makes the mouse input become more FPS-style (still retaining some inertia because it would feel weird othrewize).

Yes, that was what I meant, I will give it a try :D

I really like where this is going, I can not wait for an actual game with the stuff that is implemented already :D

(+1)

Thanks, tho I feel somewhat lost at the moment :) I initially planned on a somewhat straightforward Space Invaders clone with a few environments and bosses (and pre-defined waves), yet after adding the random waves it felt... more fresh? Guess they should stay as they fit that "evil AI" plot, also clearing some of them gets pretty tricky at times (took me quite a few restarts to deal with some of them: as you have noticed, they reset if failed to clear damage-less) - yet the whole concept becomes less clear this way.

Not much gameplay so far, as you said, but absolutely awesome mechanics. And the laser machine gun! Damn some cool particle effects!

(+1)

Thanks, glad that glorious waste of time didn't turn out to be that much of a waste after all! Yeah, the gameplay is pretty much short at the moment, was too busy with the other stuff like improving the physics, maximizing the performance and, later, the PSVR support. Now, with those solved and finished the next step will be adding a new enemy type and a few new waves, later some more environment options will likely be added. However even now it still may be pretty fun and relaxing if added a "-hardcore" switch to the calling shortcut (or by the same-named option in Config), making to the last wave becomes pretty challenging this way. Another fun thing is to type "L OFF" in the in-game console (after all the lights start up), or "AUDIO ON" (for the latter I'll soon post the tweaking program as well, one syncs with your currently playing audio for some cute lighting effects).

Any chance you can upload a direct download?

(+1)

No problem, also GD seems a little laggy today :)