Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

999542 Posts in 39231 Topics- by 30638 Members - Latest Member: AlonGibbs

April 24, 2014, 05:14:21 AM
TIGSource ForumsFeedbackDevLogsRobGetOut - 3D environmental puzzle platformer
Pages: 1 2 [3] 4
Print
Author Topic: RobGetOut - 3D environmental puzzle platformer  (Read 4156 times)
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #30 on: October 21, 2012, 09:14:21 AM »



I got an android tablet this friday after work and yesterday after trying everything i could on the device, i decided to port Runtime Engine and RobGetOut on it.

I've just managed to have a controllable robot there with proper rendering and lighting :-).

The controls are really temporary (you use the left bottom side to turn left/right and right side to go forward/backward). I'll do a more point-and-click (or in this case, tap :-P) scheme at some point and add "native" support to the engine for tap/gesture stuff. Currently the touchscreen events are simply translated to key events before passed to the system-independent part of the engine - tapping at the bottom center of the screen is translated to "space" which toggles between third and first person view for example :-P
Logged

~bs~
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #31 on: November 03, 2012, 08:12:58 AM »



Added a new version to try out.

It adds GLSL-based rendering (currently required and it'll crash if your OpenGL drivers do not provide GLSL... but any driver released by ATI/AMD and NVIDIA the last few years should support it and it is only Intel's drivers that seem to lack GLSL support, at least in older chips). The output is almost the same, just more vibrant (like the original C#/XNA version). I'll probably need to add optional shader-based rendering in the editor to match the colors since it can easily get saturated in high brightness areas.

Also it adds "inter-update interpolation" (i'm not sure how else to call that :-P). It basically interpolates the graphics state between game updates (the game is updated at roughly 60 times per second) so if you have -say- 120fps you'll still get smooth animations. Also (and more importantly) this gets rid of the microstuttering that a fixed game update causes and as an unexpected side effect it makes tearing less visible when you have vsync disabled (although that probably requires a very high framerate :-p).
Logged

~bs~
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #32 on: November 18, 2012, 12:25:40 PM »

I added support for multiple floating point rendering targets (it could be used for deferred shading, although i do not have dynamic lights at the moment) where i render the color, normal, position and depth separately in each one and then merge them in another pass with a different shader.

The result is almost the same (the color contrast is now done as a final step in merge instead of when rendering world/models) though, but i also added some SSAO:



It has been a while (actually since i worked at Track7 some years ago) since i did SSAO and i basically had forgotten most of it. It isn't anything special - in fact it is noisy (like my original implementation in T7 :-P) and slow (27fps in my 660M at 1920x1080). I think these days SSAO is usually calculated in half or quarter resolution (i did it in full) and blurred to get rid of the noise. I might try this at some point later.

The new rendering code is currently mixed with the previous but inside "#ifdef NEWOPENGL ... #endif" marks (this means that i have to recompile the engine to use the new code). The "NEWOPENGL" name comes from my initial attempt to write a new renderer from scratch using the new OpenGL 4.x Core APIs, but soon i got bored of redoing everything and switched to simple GL3.2 + compatibility profile that allows me to reuse most of the older stuff :-P. I'll make it possible at some point to switch to the new rendering code at runtime instead of relying on preprocessor marks.

EDIT: Added a video

http://www.youtube.com/watch?v=NUAaRFITGw8

EDIT2: Uploaded the new version. Includes only the new renderer and since it is compiled under VS2012 it'll probably run only under Vista and later (i have downloaded the XP compatibility pack but i'm not sure if it is enabled by default or not). I'll make a build with OpenWatcom at some point later though so it'll run even under Win2K (with the old renderer at least) :-P.

Try it from here:
http://runtimelegend.com/games/robgetout/

EDIT3: With and without SSAO (imgur album with two images).
« Last Edit: November 18, 2012, 04:54:13 PM by Bad Sector » Logged

~bs~
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #33 on: December 23, 2012, 02:25:59 PM »



It has been a while since i made an update. Here is a new feature for the editor: the ability to specify custom shade modes in the viewport using GLSL shaders. The idea is that an engine or game will have its own shaders since Runtime World's default shading doesn't help much for shader-using games (this is a problem for me with RobGetOut, for example, which saturates the colors and what seems slightly bright in the editor has overblown brightness in the engine).

Of course the rendering won't be WYSIWYG (after all the editor has no idea about what kind of engines it might be used with) but the GLSL shaders will help to make things look closer to the in-game renders.

In the image above i'm using a shader that provides some sort of cel shading by mixing stuff around to create the two levels (f.e. it tries to saturate the dark part more than the bright part). It is just a quick test, it won't be used for anything - despite the RobGetOut name there.

Currently the "Custom Shade Editor" window only allows editing existing custom shades and to add new one needs to create (or copy/paste) a shade script. At some point i'll put some code behind the other buttons too - but for now i think i need to take some rest :-P.

EDIT: Here is how a custom shade script looks like. Each of the shade <name> code <program> <type> <code> set the GLSL <type> code (can be fs for fragment shader or vs for vertex shader) code for the "<program>" GLSL program (pair of shaders combined to be applied to geometry) of the "<name>" shade (in this case RobGetOut).

This is actually the proper custom shade script for RobGetOut (the source code is copy/pasted from the RobGetOut shaders).
« Last Edit: December 23, 2012, 02:37:02 PM by Bad Sector » Logged

~bs~
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #34 on: December 23, 2012, 07:08:24 PM »



Added floating point lightmaps in the editor so i wrote some shader to put saturation using RGB->HSL and HSL->RGB conversion and apply some tone mapping. My intention was to make some rooms like in Mirror's Edge - i think that is as far as it can go with the current shaders :-P.

(no this wont be part of RobGetOut, i was just messing around :-P)
Logged

~bs~
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #35 on: December 24, 2012, 04:01:19 PM »

Added support for floating point lightmaps in the engine. Here is a video with the robot running on the above map (with slightly different saturation settings).

Also after a long time i fixed the bug in the lightmapper that added dark edges everywhere (yes they look good in some cases, like in moody dark environments, but they are out of place in anything non-dark non-boxy). In the previous screenshot the bug still exists and this is why the corners are dark. In the video there isn't as much darkening (normally there is a little of it, it isn't fully flat, but also in the video there is a bit of SSAO).
Logged

~bs~
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #36 on: December 25, 2012, 06:45:49 AM »



Here is a shot with the tweaked shaders and fixed lightmaps. Also added an extra hallway :-P
Logged

~bs~
rivon
Level 10
*****



View Profile
« Reply #37 on: December 25, 2012, 06:58:00 AM »

Oh yeah, global illumination is a great thing :D
Logged
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #38 on: January 22, 2013, 04:22:49 PM »

I added some initial dynamic shadows in the engine:



This is a very simple implementation (just plain shadow mapping with some PCF to avoid the blocky look) and the light is a constant color. It was made in ~2h (at least half of it battling with the transformation matrices :-P).

Since i want the game to be playable even in portable devices and low-end machines (think OUYA, GameStick, tablets, etc) i'll only use dynamic shadows as an extra effect. Most of the game will use regular baked lightmaps.
Logged

~bs~
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #39 on: January 23, 2013, 01:54:52 AM »

Captured a short video with the shadows.
Logged

~bs~
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #40 on: January 23, 2013, 01:22:16 PM »

Dynamic Soft Shadows:

http://www.youtube.com/watch?v=LjHcS_naeLQ

Here is another video, this time using soft shadows with varying penumbra sizes. The algorithm is an improvement of one that i came up a few years ago when i worked at Track7 games for the Theseis game and is almost identical to Percentage Closer Soft Shadows (with a few differences since i didn't exactly implemented PCSS). Since i had implemented something similar at the past it took me only a little time to modify yesterday's code to that algorithm.
Logged

~bs~
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #41 on: January 26, 2013, 08:14:20 AM »

New video with shadows and lights:


I de-hacked (mostly :-P) the light stuff and made proper dynamic lights in the world which are culled away from portals and cameras when they aren't visible (there still is room for a lot of optimization though). Also the lights are now created, destroyed and manipulated via the game scripts.

In the video above i show a few overcasting lightsources which were placed as entities in the world editor. These entities simply create dynamic lights at their own position using this script:

Code:
func Lightbot:constructor {ent type} {
    local light
    set light [dlight-new spot]
    dlight-position $light [entity-position $ent]
    dlight-direction $light {0 -1 0}
    dlight-radius $light 512
    dlight-inner-radius $light 480
    dlight-shadow $light 1
    dlight-color $light {0.75 0.85 0.9}
}

(the lightbot name is because i want to add at some point a small flying robot that follows you around and illuminates the path towards your way :-P)

Here are two images with the new lighting and shadows. The first one points out the varying penumbra sizes:



And the second one... does the same, just using a flashlight :-P



The lighting and shadow filtering still needs some tweaking (and optimization) but i think that the hardest (and most interesting :-P) are is already done. Although i still need to implement fallback dynamic lights for the "simple glsl" and "fixed function" render paths of the OpenGL backend (and of course update the OpenGL ES backend at some point for Android).
Logged

~bs~
PythonBlue
Level 2
**



View Profile WWW
« Reply #42 on: January 26, 2013, 12:06:30 PM »

Looks pretty good!

You said in the first post that you're looking for a composer. Are you interested in my services, or have you found someone since?
Logged

Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #43 on: January 26, 2013, 02:14:49 PM »

I haven't found anyone, but (as the meter that says "20%" implies :-P) the game isn't really near a point that i should start looking for a composer. Thanks for the interest though :-)
Logged

~bs~
Bad Sector
Level 3
***


96923809 michalopoylos@hotmail.com
View Profile WWW Email
« Reply #44 on: May 02, 2013, 05:11:28 PM »

So, i found this blogpost about Doom 3's "volumetric" (not really) lights and decided to do something similar in RobGetOut.

Here it is in the forward rendering path:


And here it is in the deferred rendering path:


(as a side note you'll notice that i *still* haven't implemented dynamic lights in the forward path :-P)

The forward path looks more like Doom 3's lights (actually, they're called flares in Doom 3 and this is the name i used too) while the deferred looks more like the light "bleeds" out of the surface (this is because of the contrast filter that is applied in the whole scene).

The way this is implemented is simple: the silhouette of the bright surface is extracted to create a "light strip" where the vertices that touch the surface are 100% opaque white and the vertices on the extruded silhouette are transparent (this basically fades out the strip). In the deferred render path, the silhouette is rendered in both the color and light buffers so it becomes part of the full render.

The light surfaces are marked with a special "light" texture. Any sort of surface can be used, as long as it is convex.
Logged

~bs~
Pages: 1 2 [3] 4
Print
Jump to:  

Theme orange-lt created by panic