[Striker]

Welp, the project's dead for now. I'm unable to continue without being able to decode the assembly. I spoke to Mark himself and Hendricks... no dice.

[Daedolon]

You should ask our resident asm genius.

[Lunick]

Daedolon, on 18 July 2015 - 03:01 AM, said:

You should ask our resident asm genius.

Last Active: Nov 29 2014 02:19 PM

I think we need to get his butt online

[Striker]

Aye. Basically, the code I'm working on is the renderer from Hellbender. I want to make a Multi-Platform port that can run all 3 games in one application. However, while the code has a C-based renderer as an option, it's incredibly out of date, missing functions, and is incompatible with the game itself. (Polygons go nuts, the game crashes, etc.).

I want to get it working, because it's far superior to Fury3's renderer, as it has better texture precision, Goraud shading, dynamic lighting, and more. However, since it's x86 Assembly written for MASM, not only will it not work with other processor architectures, it'll never work on anything but Windows, meaning no Linux or OSX support. (WINE will do no good, as it doesn't support the latest VC2015 runtimes as far as I'm aware. Besides, doesn't beat a native port.)

[Smoke Fumus]

Everyone stay calm. we're migrating renderer to ogre.

[Hendricks266]

Smoke Fumus, on 18 July 2015 - 02:01 PM, said:

Everyone stay calm. we're migrating renderer to ogre.

OGRE (Object-Oriented Graphics Rendering Engine) is a scene-oriented, real-time, 3D rendering engine (as opposed to a game engine).

So you're curing the disease by killing the patient.

[Smoke Fumus]

Hendricks266, on 18 July 2015 - 02:30 PM, said:

OGRE (Object-Oriented Graphics Rendering Engine) is a scene-oriented, real-time, 3D rendering engine (as opposed to a game engine).

So you're curing the disease by killing the patient.

Nope, we're replacing patient's face with an appropriate one, instead of hackjob which looks like mix between scarecrow and michael bay's decepticon.

At this point - there is no point in keeping old renderer at all - it is slow, not precise (texture warping along edges because of the low precision), doesn't support even simplest Lambert lighting model (which has been around since unreal tournament), and just cannot be restored from ASM mess in hellbender's code. Best solution right now is to scuttle the obsolete software renderer, and switch to OGRE.

On top of that - Striker found a way to forward-combine hellbender pieces of sourcecode up to the point where resulting executable will be able to support all 3 games at once with possiblity to, say - play terminal velocity campaign via hellbender gameplay. (proper energy system, ability to hang in place, better arsenal (although that will require to partially re-map bonuses on maps to encompass all hellbender's ones)

[Striker]

Smoke, don't speak for me, not everything is set in stone yet.

My current plan is to keep the the software render from Fury3 (for now, and for reference) until I can get everything rendering fully and correctly in OGRE (which actually is quite suitable for games, and has a good backend for setting up UIs, which I'm gonna need to do if I'm going to strip out MFC and make it cross-platform.) It'll still be running off of the original game engine. The reason for using OGRE is because I have zero experience in OpenGL coding, and I'm not about to waltz into that nightmare until I gain more experience in general. (I'm just learning C, myself. I've managed to pull off a lot, but I'm still learning.)

[Hendricks266]

Polymer is pretty neat, but I still play on Classic sometimes.

[Striker]

One thing I plan for this is to allow players to disable filtering and lighting effects to make it look as close to the software renderer as possible. If I can help it, I'll still keep the soft renderer, but that may become impossible when I start backporting Hellbender (Which is my favorite game in the series).

Oh, and just as a treat, if I can get Hellbender backported, I'll be able to backport Monster Truck Madness 1. The full game's source is in Hellbender's source, which can be enabled via a toggleable define.

I know dumping the software renderer may be akin to dumping the baby out with the bathwater, but... in this case that baby is the one from Eraserhead. It's probably for the best.

If only I had someone like Plagman...

[Smoke Fumus]

Juris3D, on 18 July 2015 - 11:16 PM, said:

Sorry that I will say some probably bad words for programmers ears, but that will be from my (as ordinary gamer) perspective: why not keep in distributed package separate simple "Terminal Fury" in its current existing state that we have and play right now (I know I do)? That would be for purists, no bells and whistles. Is it because it is Windows only? Or, just because it is not pretty to have separate executables etc.? My (simple man's) thoughts are, there can be separate "old school" version, with minimal enhancements (screen resolution), and then nothing holds back to do whatever modern and cool are needed in new versions, remakes.

Here's the deal - if you want 100% pure experience - you can always play the original. That's the way it goes.
We are trying to create a package which would work properly in better conditions, and yes, look just like the original. Think about it like GL_Quake version of Quake 1 - same thing but hardware accelerated.

[Daedolon]

I doubt this has any relevancy, but the visuals are strikingly similar (in my eyes anyway): http://www.virtuadv....tar_quest_1.php

[Striker]

This isn't the enhanced version Juris. This is the project I've been taking screenshots of, TerminalFury. I'm ditching the software renderer in it because it'll hold back development.

[Smoke Fumus]

 Juris3D, on 19 July 2015 - 10:11 PM, said:

Thanks for reminding this one. Sad that they didn't reach Kickstarter for "Star Quest 2"
While on topic about old games in "our" style, when I was writing here about my favorites next to "Terminal Velocity" (i mentioned "Crimson Skies", "Rogue Squadron 3D"), I forgot one important title: "Archimedean Dynasty" (original german "Schleichfahrt"). Later kind-of sequels (Aquanox) sucked. At one point there was remake project "Silent Depth", but I think it died (http://www.irrlicht3...ntry.php?id=229). Also there is this attempt: http://sourceforge.n.../schleichfahrt/

And here also somebody loved "Terminal Velocity" a lot:
http://www.phatcode....oads.php?id=132

On semi-related note - Microsoft's Deadly Tide was kinda made in same key, and as FMV games go - not that bad.

[Striker]

Well, it was decided that OGRE wasn't fitting for the way TV's internals work. So, now I'm writing an OpenGL renderer from scratch. However, I have no fucking clue what I'm doing, is there anyone on this forum who has written a OpenGL renderer before?

[filipetolhuizen]

Can you fit TRI's D3D renderer? I know it's way too outdated, but it could be a start.

[Striker]

I managed to find the original S3 ViRGE toolkit thanks to VOGONS. It should shed some light on things.

Hellbender had the code to the Terminal Velocity S3 ViRGE version still in it, but I didn't have the ViRGE SDK until now.

The old S3 Renderer is closer to OpenGL's syntax than Direct3D's. MUCH closer. The D3D Renderer is a nearly undecipherable mess (to me, at least).

Now, I should be able to translate things much easier.

[Striker]

Nope. Hellbender never had any re-releases, opening of the source, or anything. It was 640x480 Software or D3D only.

If you haven't played it though, I suggest you pick up a copy from eBay or Amazon. It's a fantastic game.

[Striker]

Hellbender has much bigger emphasis on story, exploration, objectives, and tactics. It's deeper than TV. Atmosphere-wise, it was a lot more serious and gritty, in the way that it doesn't have the camp of the previous games. It really takes on an atmosphere akin to Star Wars.

Speaking of Hellbender, when I get to the point of porting it to this engine, I plan on adding some enhancements (hopefully to accommodate for some of the game's issues).

I'm a little further along with writing the renderer. I'm almost to the state where I'm able to start drawing polygons. Once I get it going I'll post screenshots.

By the way, Hellbender had a particle system, which I backported to Terminal Velocity (as seen in earlier screenshots of mine). Once I move to OpenGL, I'll be using this particle system: http://sourceforge.n...ts/sparkengine/

[Striker]

Patience. It'll probably be a few weeks to a month or more before I get a build out to everyone. There's still a lot of work to do.

When it's ready, it'll look no different than the software renderer at first. Albeit with much better fog and texture precision. (Ie. No PSX-esque jittering texture coordinates.)

[Striker]

I can't say this enough, I need someone on the team whom I can consult when it comes to OpenGL. I got the code written, and while it looks fine, it's crashing in the nvoglv32.dll file.

[Striker]

Got wireframes rendering:

[filipetolhuizen]

Nice!

[Smoke Fumus]

Alright here's a footage from early test of TVHD


As you can see it's not that great. UI is in its infancy, i still have no sound. But there are some things to look at.
First of all - dynamics. New dynamics include a bit of momentum for the craft. Not a whole lot, to not distract original model but some.
Also new daytime Ymir up-close.

[Striker]

Got some shading going. Some light intensity values are clipping.

[Striker]

Fixed the lighting issues.

[filipetolhuizen]

That's impressive! So little time and so much progress.
StrikerMan780, interesting you mentioned S3 API is similar to OpenGL. People at Vogons will be very interested in your findings. We are looking forward to play Destruction Derby optimized for S3 in different cards. Someone there already made alternate versions that can bypass faulty CD and Diamond Stealth 2000 3D card detection.

[Striker]

Just to show how similar, here are the functions for drawing vertex arrays:

S3:
pS3DTK_Funct->S3DTK_TriangleSet( pS3DTK_Funct, (ULONG*)vlistPtr, n, S3DTK_TRIFAN );

OpenGL:
glDrawArrays(GL_TRIANGLE_FAN, 0, n);

[Smoke Fumus]

 Juris3D, on 22 July 2015 - 08:15 PM, said:

Ho hoooo! Some action!! Very heart warming to see such progress. Are those mountains random fantasy, or somehow regenerated from original level heights? About view, I almost always play "from cockpit", first person view. In outside view, 3rd person view, like in this video, in many games is one problem, but probably hard to explain with my poor english. I am talking about some "stiffness", very unnatural stuck camera position. I think that virtual camera behind ship needs some kind of delay when ship turns, climbs, dives. So, on the screen we see ship manouver and then camera "catches up" to be behind ship again. Then, I think, 3rd person play can be enjoyable. About cockpit, any plans to add some, well, cockpit? I know "TV" doesn't have such view (probably no glass windows on that fighter at all, just some camera/monitor system), but in planes sim/action games I totally love cockpit view, even if that might be just couple of pieces of metal that holds cockpit glass (like I said - my poor english, sorry).

Right now camera is already at delay, but at a very subtle one. On top of that - it also picks up ship rotation.
Cockpit is in works, i need to figure out how to make it look suitable.

I took original heightmap as basis, stretched it out, and then applied a long chain of adjustments to it namely erosion, thermal weathering, then erosion again.

[Smoke Fumus]

 Juris3D, on 23 July 2015 - 10:45 PM, said:

About cockpit inside view, for me, even couple of polygons like in this picture adds immersion feeling, illusion of being inside some machine:
http://www.mobygames...-enemy-mech.png
Of course, just like in real planes, view obstruction should be as minimal as possible. And there should be also some trick that imitates head motion (in reality i guess just those cockpit pillars slightly shaking, being not static in reference to "head").

Yea, but the problem is that you, personally, is a dedicated fan - you have a high tolerance for lower grade graphics and lower quality. General public however (even mid-core level) are gonna be much more ferocious towards it.

Do not worry about head motion imitation - i already have slight delay figured out for camera head position. Only thing left is to figure out just what the hell is cockpit gonna be.
Right now i am gonna go with mechwarrior online type of cockpit where yes cockpit is detailed, but you only see most of detail at startup sequence, and then you're mostly strapped closer to the window view with 3 pop-up holographic panels.