Jump to content

Turbo Game Engine Design Document

Josh

438 views

Subscribers can now download my current revision of the Turbo Game Engine design document in the private forum here:

Here are a few excerpts:

Quote

The scene tree will add a search box to quickly locate an object by name. It will feature improved drag-and-drop functionality for modifying the scene hierarchy.

Quote

Clustered Forward Rendering will replace the deferred renderer from Leadwerks. PBR materials will be used by default, with additional support for Blinn-phong materials. A voxel GI technique will be used for indirect lighting.

Vulkan will be used for the final renderer, as this is most consistent with the consumer’s expectations of a modern game engine. The MoltenVK SDK will be used to port this code to Metal for MacOS.

Quote

An infinite terrain system is planned. This works by displaying a grid of tiles around the camera at any position. If a terrain tile file is available, it will be opened and read as it is encountered by either the renderer or a physics object that intersects the bounds for that sector of the universe.

The document is still evolving so expect changes and updates.

  • Like 4
  • Thanks 1
  • Sad 1


9 Comments


Recommended Comments

Did you already figure out how the infinite terrain will work with navmesh generation and navigation?  I'm guessing for generation you'll have to load all the terrain at once.  I assume it's not a problem to have character controllers navigate on a navmesh when a terrain isn't loaded (they're independent of each other?).

Share this comment


Link to comment

That is a difficult question to answer. I don't know if I will have a solution to that when 1.0 comes out.

Share this comment


Link to comment

That's fair.  Keep taking those steps forward and try to make the official release as complete as possible (in a reasonable time frame).  I don't envy the pressure you might feel sometimes.

Share this comment


Link to comment

I want to support the project, but the only possible means of payment I have, is by steam. Is it possible to put a product, for example a Turbo card to be sold by steam?

Share this comment


Link to comment

Seriously, how the heck would you plot a path from San Diego to Orlando? It can't be done without loading data for the entire route in between. Perhaps the navmesh should have a distance limit for pathfinding.

@Iris3D Games Thank you but the beta will not be on Steam.

  • Sad 1

Share this comment


Link to comment

The good news is that it's been done elsewhere so there is at least one working solution.  I suspect the path is broken up into multiple points and all an engine calculates is the path between the current point and the next point.  When you get to the next point, you calculate the path to the next one after that, etc.  But there's gotta be information out there on this.

Share this comment


Link to comment

I think the only possible solution is to have local nav meshes with a limited area connected by a hand-placed “highway” type of system.

Share this comment


Link to comment

When I was playing with this idea I was doing a treadmill system. A 3x3 grid where the player always stays in the middle tile. When they move "left" for example and get close to the edge of that middle tile it would load in the 3 new tiles to the left of the most left 3 tiles and then when they actually crossed the line it would swap the entire grid position wise and then move the player back. Since everything moved relative in 1 go the player would never tell the difference. It would then unload the right most 3 tiles that aren't needed anymore. In my case it wasn't real terrain but modeled terrain and it was all flat. Given LE didn't have multithreaded loading of assets all assets had to be loaded up front so instances could just be created which was more instant.

 

 

Share this comment


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 5
      I did a little experiment with FPS Creator Pack #75 by upsampling the images with Gigapixel, which uses deep learning to upsample images and infer details that don't appear in the original pixels. The AI neural network does a pretty impressive job, generating results that are look better than a simple sharpen filter: I doubled the size of the textures to 1024x1024. Then I generated normal maps from the high-res images using AMD's TGA to DOT3 tool, and saved the normal maps with BC5 DDS compression. The diffuse textures were saved with BC7 DDS compression. The images below are using a 4x magnification to demonstrate the difference.


      As you can see, the image that is upsampled with deep learning looks normal and the resized image looks like there is butter on the lens! It's hard to believe the above images came from a 256x128 section of an image.
      The workflow was pretty tedious, as I had to convert images to TGA, then to uncompressed or BC5 DDS, and then to BC7 in Visual Studio. Each BC7 texture took maybe 5-10 minutes to compress! So while this set represents the optimum quality for 2019 game tech, and the format for assets we want to use in LE5, the workflow has a lot of room for improvement.
      You can download the full package here:
      FPSCPack75TexturesHD.zip
    • By Josh in Josh's Dev Blog 0
      A new beta is available with the following changes:
      Script prefixes are now changed to lowercase entity:Update(), entity:Start(), etc., as well as widget:Draw(), etc. This is because Entity() and Widget() are going to be functions to cast an object to that type. Sprites are now created on a sprite layer object. A sprite layer is created in a world and added to a camera. This allows control over what camera sees what set of sprites. See the examples for details. GUI system is partially working. Resizing the window won't reposition items correctly. Only four widget types are supported, panel, button, hyperlink, and label. Example in the FPSGame demo. The game menu system is packed into an entity script and works really nicely. Widget scripts are a little harder to develop now since they use a system of persistent objects, but performance is very much better than LE4. An interesting detail is that you get free interpolation of position and color at a rate of 60 hz. A lot of work was done to improve the Lua binding system. See details here. Error reporting and handling is much improved. No work was done on sound. No work has been done to the multicam demo, which some people had trouble with. Actors crashing / Lua stack error bug fixed. Changed .bat files to use release version of EXE instead of debug. New commands EmitEvent() and GetEvent(). If the returned event type is EVENT_NONE, there is no event. EVENT_QUIT can be emitted anywhere in the program to signal the main loop to exit. Typical usage is like this: while window:Closed() == false do while true do local event = GetEvent() if event.id == EVENT_QUIT then return end if event.id == EVENT_NONE then break end if event.id == EVENT_WINDOW_CLOSE and Window(event.source) == window then return end--you don't need this when Window:Closed() is being checked for already end world:Update() world:Render(framebuffer) end  
    • By Josh in Josh's Dev Blog 2
      DPI scaling and the 2D drawing and GUI system were an issue I was a bit concerned about, but I think I have it worked out. This all goes back to the multi-monitor support that I designed back in September. Part of that system allows you to retrieve the DPI scale for each display. This gives you another piece of information in addition to the raw screen resolution. The display scale gives you a percentage value the user expects to see vector graphics at, with 100% being what you would expect with a regular HD monitor. If we scale our GUI elements and font sizes by the display scale we can adjust for screens with any pixel density.
      This shot shows 1920x1080 fullscreen with DPI scaling set to 100%:

      Here we see the same resolution, with scaling set to 125%:

      And this is with scaling set to 150%:

      The effect of this is that if the player is using a 4K, 8K, or any other type of monitor, your game can display finely detailed text at the correct size the user expects to see. It also means that user interfaces can be rendered at any resolution for VR.
      Rather than trying to automatically scale GUI elements I am giving you full control over the raw pixels. That means you have to decide how your widgets will be scaled yourself, and program it into the game interface, but there is nothing hidden from the developer. Here is my code I am working with now to create a simple game menu. Also notice there is no CreatePanel(), CreateButton(), etc. anymore, there is just one widget you create and set the script for. I might add an option for C++ actors as well, but since these are operating on the main logic thread there's not really a downside to running the code in Lua.
      local window = ActiveWindow() if window == nullptr then return end local framebuffer = window:GetFramebuffer() if framebuffer == nil then return end self.gui = CreateGUI(self.guispritelayer) --Main background panel self.mainpanel = CreateWidget(self.gui,"",0,0,framebuffer.size.x,framebuffer.size.y) self.mainpanel:SetScript("Scripts/GUI/Panel.lua", true) local scale = window.display.scale.y local w = 120 local h = 24 local sep = 36 local x = framebuffer.size.x / 6 local y = framebuffer.size.y / 2 - sep * 3 self.resumebutton = CreateWidget(self.mainpanel,"RESUME GAME",x,y,w,h) self.resumebutton:SetScript("Scripts/GUI/Hyperlink.lua", true) self.resumebutton:SetFontSize(14 * window.display.scale.y) y=y+sep*2 self.label2 = CreateWidget(self.mainpanel,"OPTIONS",x,y,w,h) self.label2:SetScript("Scripts/GUI/Hyperlink.lua", true) self.label2:SetFontSize(14 * window.display.scale.y) y=y+sep*2 self.quitbutton = CreateWidget(self.mainpanel,"QUIT", x,y, w,h) self.quitbutton:SetScript("Scripts/GUI/Hyperlink.lua", true) self.quitbutton:SetFontSize(14 * window.display.scale.y) w = 400 * scale h = 550 * scale self.optionspanel = CreateWidget(self.mainpanel,"QUIT", (framebuffer.size.x- w) * 0.5, (framebuffer.size.y - h) * 0.5, w, h) self.optionspanel:SetScript("Scripts/GUI/Panel.lua", true) self.optionspanel.color = Vec4(0.2,0.2,0.2,1) self.optionspanel.border = true self.optionspanel.radius = 8 * scale self.optionspanel.hidden = true  
×
×
  • Create New...