Advanced Tutorial on DPI and UI Scaling in Leadwerks 5

🧩 Technical Context

You're developing your game in Leadwerks 5, you create a windowed mode with beautiful dimensions like 1280 x 720, and you decide to center it stylishly using:

 

local displaySize = display:GetSize()
local posX = displaySize.x / 2 - width / 2
local posY = displaySize.y / 2 - height / 2

So far, so good...
BUT...

🧨 When you decide to switch to fullscreen mode, everything goes haywire.
 

💥 What Happened Here?

When you activate fullscreen, you're not just removing the window border and maximizing the visible area.
No, sir.

In many engines (and Leadwerks is no exception), the operating system completely changes the monitor's resolution to match that of the game window.

Yes, you read that right:

“The entire system lowers its resolution to accommodate your game.”

For example:
If your desktop was 1920x1080 and your window is 1280x720, then upon going fullscreen, your entire operating system is now at 1280x720.

🕳️ What Does This Imply?

Upon returning to windowed mode, if you call display:GetSize() again, what you get is no longer the real desktop resolution, but the last forced monitor size.

Result:
🔄 Your window is created mispositioned, miscentered, everything's wrong.
 

🧪 Is This a Bug?

No, it's “expected behavior with dark side effects.”
Engines like SDL, Unity, or Unreal Engine also have to deal with this.

• SDL recommends using SDL_GetDisplayBounds() to get the real resolution.

• Unity has separate APIs for “render resolution” and “display resolution”.

• Unreal uses GetDesktopResolution() only at startup, never after fullscreen.

✅ The Solution: Cache It Like It's Gold!

We created a system that:

1. Detects the real desktop resolution the first time the game starts in windowed mode.

2. Saves it in the configuration file as:
   
    

   desktop_resolution=1920x1080

   3. Uses that value whenever we need to center the window, and never touches it again.

   Additionally, we made a small local cache in Lua to avoid reading the file all the time.

   ---

   💾 BONUS: Temporary Backup in Case Everything Explodes

   We also created a system to save the current resolution in a temporary file before applying any screen changes.
   So, if the player presses "CANCEL", we simply restore from the backup, and the universe is back in balance.

   ---

   💙 Conclusion

3. ⚠️ Don't trust display:GetSize() after fullscreen.

4. 🛡️ Save the real desktop resolution once, and protect it like it's your HUD's lifeline.

5. 🤓 Understanding how graphics engines work at a low level saves you hours of yelling at the monitor.

6. 😂 And remember: sometimes, the real bug... is the implicit logic the system didn't tell you about
   
    

   -- Last Update 5 de Abril 2025
   
   Window = {}
   Window.__index = Window
   
   -- Variable local para almacenar la resolución de escritorio de forma persistente
   local cachedDesktopResolution = nil
   
   function Window:New(title, x, y, width, height, display, style)
       local this = setmetatable({}, Window)
   
       local title = title or "Ventana"
       local x = x or 0
       local y = y or 0
       local display = display or GetDisplays()[1]
   
       -- Cargar configuración
       local settingsManager = SettingsManager:New()
       local settings = settingsManager:Load()
   
       -- Guardar backup temporal de resolución y fullscreen antes de crear la nueva ventana
       local tempSettings = {
           resolution = tostring(width) .. " x " .. tostring(height),
           fullscreen = settings["fullscreen"] or "0"
       }
       settingsManager:SaveTemporary(tempSettings)
       Print("📝 Backup temporal guardado: " .. tempSettings.resolution)
   
       -- Inicializar la resolución de escritorio solo una vez y guardarla en un caché local
       if not cachedDesktopResolution then
           local storedDesktopRes = settings["desktop_resolution"]
           if storedDesktopRes and storedDesktopRes:match("^(%d+)x(%d+)$") then
               local w, h = storedDesktopRes:match("(%d+)x(%d+)")
               cachedDesktopResolution = { x = tonumber(w), y = tonumber(h) }
               Print("🖥️ Resolución de escritorio cargada desde config: " .. storedDesktopRes)
           else
               local size = display:GetSize()
               cachedDesktopResolution = { x = size.x, y = size.y }
               settings["desktop_resolution"] = tostring(size.x) .. "x" .. tostring(size.y)
               settingsManager:Save(settings)
               Print("🖥️ Resolución de escritorio guardada por primera vez: " .. settings["desktop_resolution"])
           end
       else
           Print("🖥️ Usando resolución de escritorio en caché: " .. tostring(cachedDesktopResolution.x) .. "x" .. tostring(cachedDesktopResolution.y))
       end
   
       local savedDesktopW = cachedDesktopResolution.x
       local savedDesktopH = cachedDesktopResolution.y
   
       -- Cargar o asignar resolución de ventana
       if settings["resolution"] then
           local w, h = settings["resolution"]:match("(%d+)%s*x%s*(%d+)")
           if w and h then
               width = tonumber(w)
               height = tonumber(h)
               Print("📐 Resolución de ventana cargada desde config: " .. width .. "x" .. height)
           else
               width = width or 800
               height = height or 600
           end
       else
           width = width or 800
           height = height or 600
       end
   
       -- Determinar modo ventana o fullscreen
       local fullscreen = false
       local fs = settings["fullscreen"]
       if fs then
           fs = fs:lower()
           if fs == "true" or fs == "1" or fs == "yes" then
               fullscreen = true
           end
       end
   
       if fullscreen then
           style = WINDOW_FULLSCREEN 
           Print("🖥️ Modo pantalla completa activado.")
       else
           style = WINDOW_TITLEBAR
           Print("🪟 Modo ventana activado.")
       end
   
       -- Calcular posición centrada
       local posX = savedDesktopW / 2 - (width / 2)
       local posY = savedDesktopH / 2 - (height / 2)
   
       local window = CreateWindow(title, posX, posY, width, height, display, style)
       local framebuffer = CreateFramebuffer(window)
   
       Print("[Window] Ventana creada con éxito: " .. title)
   
       -- Métodos públicos
       function this:Closed() return window:Closed() end
       function this:GetWindow() return window end
       function this:GetFramebuffer() return framebuffer end
       function this:KeyDown(key) return window:KeyDown(key) end
       function this:GetWidth() return width end
       function this:GetHeight() return height end
       function this:GetTitle() return title end
       function this:SetTitle(newTitle)
           title = newTitle
           window:SetTitle(newTitle)
       end
       function this:Destroy()
           window = nil
           framebuffer = nil
           if self.settings then
               self.settings:Destroy()
               self.settings = nil
           end
           Print("[Window] 🧹 Recursos liberados correctamente.")
       end
   
       return this
   end
   
   -- 💾 Método estático para restaurar resolución desde el archivo temporal
   function Window.RestoreFromTemp()
       local sm = SettingsManager:New()
       local temp = sm:LoadTemporary()
   
       if temp and temp["resolution"] then
           local w, h = temp["resolution"]:match("(%d+)%s*x%s*(%d+)")
           if w and h then
               local fs = temp["fullscreen"]
               if fs == "1" or fs == "true" or fs == "yes" then
                   fs = true
               else
                   fs = false
               end
               Print("🔁 Restaurando resolución temporal: " .. w .. "x" .. h .. " | fullscreen: " .. tostring(fs))
               return tonumber(w), tonumber(h), fs
           end
       end
   
       Print("⚠️ No se pudo restaurar resolución: archivo temporal no encontrado o malformado.")
       return nil
   end
   
   return Window

    

In the thrilling world of game development, I've had the incredible opportunity to work with Ultra Engine, a platform in early access that has opened up countless possibilities for creating impressive worlds. My latest project focuses on mapping, a process that has allowed me not only to explore the capabilities of Ultra Engine's map editor but also to actively contribute to its development by identifying and reporting bugs.

From the start, I have created numerous prototypes, experimenting with brushes, adjusting scales, applying textures, and gaining a better understanding of PBR (Physically Based Rendering) materials and PBR lighting. This learning journey has been incredibly enriching, allowing me to understand how diffuse textures, cubemaps, and specular textures work together to create a visually appealing environment.

One of the most fascinating aspects of this process has been lighting. Learning to use light probes to make lighting more realistic and understanding light bounce has been a rewarding challenge. Light probes not only simulate reflection at a local level but also add a level of realism that brings the environment to life. Every time I use a probe, I can see how the lighting changes and reflects on the textures and surfaces of the map, creating a visually coherent and immersive experience.

Despite the challenges, such as issues with prefabs and the precision of the editor's grid, each obstacle has been an opportunity to learn and improve. Prefabs, although still in development, have been a crucial piece in constructing my base on Mars. The editor's grid, while not always precise when scaling, has been fundamental in structuring and organizing the elements of my map.

My approach has been learning by doing, repeating processes over and over until I perfect my skills. This methodology has not only improved my proficiency in using the map editor but also allowed me to better understand the limitations and potential of Ultra Engine.

I hope that future updates will resolve the issues with prefabs and enhance the precision of the editor's grid. This will enable me to focus even more on developing my base on Mars, taking the project to new heights.

Working with Ultra Engine has been a transformative experience, and I am excited to continue exploring and creating on this platform. If you are interested in game development and want to be part of a growing community, I encourage you to join us on this adventure. Creating and exploring new worlds awaits you!

To date, Astrocuco is the result of many intermittent years of learning where the challenge is always the same, to create prototypes of how programming works.

What I have learned, I have managed to master to an acceptable degree the subject of programming, understand concepts of classes, objects and most importantly apply them when writing code, in this case Lua Script. This has helped me a lot to focus my efforts in writing readable, reusable code, where I can understand what it does, why it is done and how to use it.

At this point the future game is about a teenage girl who lands in emergency on the red planet and her mission is to stay alive, initially pending her health, stamina and oxygen. About the character I can say that it represents a very personal aspect of my life with my daughter who today is 18 years old, and somehow I want to capture in the game a very personal situation.

The character initially has two accessories, a helmet and a backpack.  And his life, stamina and oxygen are measured with a Hud system that is positioned in the upper right corner.

The character initially has two accessories, a helmet and a backpack.  And his life, stamina and oxygen are measured with a Hud system that is positioned in the upper right corner.

Although I can model characters and animate them, they would never look professional, so I resort to external tools like Mixamo to animate biped characters and to create them I use tools like Fuse, both systems are currently free.

In this case the head of the character is created with Fuse, and the body of the character has its own story.

The initial character 

The initial character was purchased from an art store and looked very different from what he is now.  The changes arose due to the family situation we are going through and I decided to give her a more human aspect where the model pretends to be my daughter on the red planet (cancer). Then as the model underwent these changes to with the Fragmotion program which is for 3D modeling and where he received a successful head transplant.  The rigging is created automatically by Mixamo and in the process the character is what it is today.

I have to mention that I am not an expert in 3D art and the only tool I use is Fragmotion, where I can create basic architectural and organic models and give them an animation, but I would not have professional results like Mixamo and Fuse (free tools).

The creation process

I am not an expert in this, I have gone through a lot of engines, each one with its pros and cons, however I highlight that Leadwerks engine is just what I need from a technical aspect where my computer runs it very well. ( Hardware from a decade ago ). I love writing scripts compared to visual systems that offer other environments, so this is more for personal taste and circumstances. 

The most difficult thing at this point is to learn something and then put it into practice, for me this is a great achievement because I do not speak English and my learning process is usually complex. For some reason I am going a little slower but consolidating knowledge, making me skilled in this tool.

So it is where for several years I have been trying to make the ragdoll effect, and evidently it could be done, not that it is perfect, but in the end it is a game and I am not creating a simulator of life. But I'm happy with the result, although partly because I would have liked the character to stand up.  I am convinced that it can be done, however I don't want to invest more time in this and rather as soon as possible to have a playable demo.  The problem to make the character stand up has to do with bones, rigid bodies and currently I use SetParent to hook the bones to those rigid bodies, but this prevents to free the skeleton to use it in an animation, the most reasonable would be to use SetPosition, SetRotation, but you see strange effects that surely have a solution, but would involve a process of learning and understanding to achieve the goal to stand up, such as detecting that the character is with his chest against the ground or back and unleash an animation to stand up. But possibly in the future it could be done. 

Doing this part of the ragdoll involves being aware of many things, the most complicated thing for me to make a game is to unite several systems and that all work as a gear in a harmonious way, I always emphasize I am not an expert in this, but I get by with the way I have learned, and something that happens is that when we learn by our means, what will happen is that we learn wrong in a high degree of percentage. 

For example when the character dies, it was a tremendous problem because I could not return it to its initial position, like a checkpoint, and what happened was that I loaded the character on the map. The solution was to load the character by means of script in a global variable, to later eliminate it of the memory but not if before loading it again, apparently what it does is not to load it from the hard disk, but from the memory where the other one was. 

But at the moment for me this is a feat, this works and all my experience is based as a player. 

User-facing parts of the project

When the user launches the application, he will initially see a representative drawing of Mars, with a sign that reads the name of the game. ( Astrocuco).

The interesting thing about this is that I have put a fade in and fade out effect on each scene like this. For example when entering the menu it appears little by little and when leaving it happens the same way.

Subsequently, the menu is passed in 3D, a scene of a place that is intended to simulate a spatial environment of loading and unloading of resources. 

This menu is a prototype of what should be in the future, more specifically in the options section, where initially the player can change the screen resolution, or switch from windows windowed mode to full screen ( It works )

I have to comment that creating the resolution change and all this was a kick in the balls as well as the ragdoll. But in the end it works and that is gratifying from a developer's point of view.

To finish I have to work on gameplay aspects, in the future I need a radar or a compass, also a simple inventory GUI. The idea is to collect certain elements (scrap, Polymer and other things to make things and repair them. I am aware that this prototype is very basic, and I don't know if I really make a game of this, but I have an 18 year old girl who tells me which looks very good, and it usually happens that over the years in my case we lose our ingenuity and see the world as children do not see it.

So my daughter wants to see the game on Steam, would it be possible? I'm very pessimistic, but my daughter thinks so.

So without further ado, we'll see you later.

I would like to know your opinion, constructive and realistic criticism, you do not have to hurt my feelings, I highly value sincerity.

When programming, it is extremely necessary to plan what you want to do, a coding project should be divided into blocks, function files. 

It is like writing a book, by pages, by chapters, I speak of a book of modern times, those books that you can touch and pass its pages with a finger wet in saliva, of course because of the pandemic I think that is a danger to do.

Well, it is another thing to make a codification as if we were in the first century of our era writing the history of Egypt on a parchment.

What I mean by these two examples of the book and the papyrus is that it is good to break the whole code into parts, as when you create a wall, which is made up of much smaller blocks. Unless you are a machine, you will surely put all the code of the player entity in a single script (scroll), but as I have found it easier and more comfortable to simulate a development environment focused on object programming in Lua Script. 

And how do I do this, through the use of tables. 

function Script:Start()


end

This is the Start function of a file attached to a player entity. Inside it I can put everything I can think of for the player entity, ragdoll effect, movement, hud system for life indicators, oxygen, animations, etc.  But I feel more comfortable splitting this into files, let's see an example.

import("Scripts/Objects/Player/Classes/CPlayer.lua")

function Script:Start()


		self.player = CPlayer:New()

end

With the Import command, I link another file called CPlayer ( Player Class ), remember this is a kind of simulation of classes and objects. 

And in that file I have the following. 

import("Scripts/Objects/Player/Classes/CRagDoll.lua")

CPlayer={}
	function CPlayer:New()

		local this={}
			this.ragDoll = CRagDoll:Start()
			
			

			
			
			

			function this:Start()

		
			end

			this:Start()

		return( this )
	end

As you can see, inside that CPlayer file, I import another file called CRagdoll, and the principle is totally the same, I repeat this is the way I have found this is more comfortable for me, possibly you feel better putting everything in one file.


What is a class?
 

The best way to understand what a class is, is to think of a cookie mold, from which many cookie objects come out, these objects differ from each other in the flavor of the cookie, its color, its texture. That is to say, from a House class, we can create many houses, where their properties such as color and materials vary a little, making each house different. 

So let's create a Globe class in Lua Script.

 

CGlobe={}
	
	function CGlobe:Start()




	end

That's how simple we create our mock class in Lua, a balloon class, where we create balloon objects. The next step is to define the properties of the balloon object, for example its color.

CGlobe={}
	
	function CGlobe:New()

			local this={}
  
  				this.color = "Red"
  
  			function this:Create()
				System:Print("Create Globe... OK!)
			end
    		this:Create()

			function this:SetColor(color)
      				this.color = color
      		end
    
    		function this:GetColor()
      				return ( this.color )
      		end
      		
			return ( this )

	end

At this point I create the constructor of the object, it is simply the New function, which returns me the table this, and this calls the start function, creating a default object of red color. 

We have two methods or functions, SetColor, to give a new color to the balloon, and one called GetColor to retrieve the color of the balloon

It should be noted that by handling this file system, you can have a large number of well-organized "objects" on your project that do something. In this case you can create different balloons of different colors.

import("Scripts/Objects/Player/Classes/CGlobe.lua")

function Script:Start()
	self.myGlobeRed = CGlobe:Create()
	
	System:Print(self.myGlobeRed:GetColor())

	self.myGlobeOrange = CGlobe:Create()
	self.myGlobeOrange:SetColor("Orange")


end

This is the idea I want to convey, dividing a project into smaller parts will make your life much easier. 

At this point of learning there is a glimpse of a low idea of creating a game, but the secret of all this is to keep it simple and to be very clear that a game is a game, and not an exact simulation of the real world. For example anyone who has a low idea of the red planet, will understand no matter the colors of the scene that is a terrain of Mars, even if it is not very real what is transmitted, a game, that's just it.

At this point I already have an astronaut character who runs from one place to another on a very large 4096 x 4046 terrain that would surely take a long walk. My previous prototype projects involve a vehicle, but I didn't get the best implementation prospect in that time and I always found performance problems in my machine, something that isn't happening with the character controller for a third person player. 

As always, I think I'm a scavenger looking for game resources, that's where this community exposes links to websites with interesting hd textures, and one or another model searched on the net, but what I've greatly improved is learning to write code, I have a better workflow, writing Lua code focused on the paradigm of object programming.

Something interesting is the system of putting rocks, all very nice from the point of implementing them. And it works very well with the character controller if you put collision in cube form.

I've been thinking about implementing a car system, I think it would be necessary in such a large terrain, but I think it's not the time, my previous experience, involves deterioration in performance and something I think is the physics of the car with respect to the terrain and rocks that in the previous project involve deterioration in the fps. Although if you implement a car would have an option would be to remove the rocks, but I prefer not to have a car and if you have rocks. 

Rather, the effort and dedication immeasurably, was to improve on something learned. And here I was with the powerful leadwerks engine, where his greatest power lay in making everything very easy.  

About the project

The prototype is very simple, a third person character goes through a stage, an orbital camera that follows him with many interesting things when scripting.  A character who runs, walks, ducks, jumps, and suffers damage when he falls from different heights. 

The interesting thing about all this is that just like when you're little and learn to write, repetition is key to learning to program, understand concepts and improve.  So as I've always said, you learn to program by programming, although I sincerely think that lua script is not programming, but the experts say it is, so I go into that elitism of those of us who think we are programmers. 

The final part of the project consists of creating a death animation, this will be activated when the player falls from a high part and separates the legs (that is very cruel). 

But that feeling of improvement is the same that I feel when in the mornings when I have a coffee I solve a riddle of the newspaper, but I don't know when I'm going to stop, it turns out and it happens that technology advances very fast and this continues and continues without stopping. Starting with LE 5, and the only thing that can happen is that I die or that my old computer doesn't work anymore. 

Translated with www.DeepL.com/Translator

Today I had a kind of Eureka, I actually discovered how to properly implement the sliding joints to create springs for a vehicle, the point here is to get to understand how this should work and I think I've achieved it. In the end I'm left with the doubt of whether I have a learning disability, because torture is the same as always, trial and error. 

Translated with www.DeepL.com/Translator

So I expose the code to recreate the shock absorbers, it should be noted that only I understand this, because I do not give any explanation regarding the case, but it works.

 

cVehicle={}

	function cVehicle:New()
		
		local this = {}
	

		this.mesh = {}
		
		this.mesh.chassis     = nil
	
		
		--## pivots Springs. 
		this.mesh.SpringFL    = nil
		this.mesh.SpringFR    = nil
		this.mesh.SpringBL    = nil
		this.mesh.SpringBR    = nil
		
		--## Meshs Wheels.
		this.mesh.WheelFL    = nil
		this.mesh.WheelFR    = nil
		this.mesh.WheelBL    = nil
		this.mesh.WheelBR    = nil
		
		--## Meshs Axles Dir.
		this.mesh.AxleL      = nil 
		this.mesh.AxleR      = nil
		
		--## Motor Springs.
		this.motorSprings={}
		this.motorSprings.force = 300
		this.motorSprings.limits={}
		this.motorSprings.limits.Down = -0.5
		this.motorSprings.limits.Up = 0.5
		this.posSprings={}


		
		function this:StartSystem( springs, wheels, axles, chassis)

			self.mesh.chassis   = chassis
			
			self.mesh.SpringFL 	= springs[0]
			self.mesh.SpringFR 	= springs[1]
			self.mesh.SpringBL 	= springs[2]
			self.mesh.SpringBR 	= springs[3]

			self.mesh.WheelFL  	= wheels[0]
			self.mesh.WheelFR  	= wheels[1]
			self.mesh.WheelBL  	= wheels[2]
			self.mesh.WheelBR  	= wheels[3]

			self.mesh.AxleL		= axles[0]
			self.mesh.AxleR		= axles[1]
			
			self:StartMotorSprings()

		end

		function this:StartMotorSprings()

			self.posSprings[0] = self.mesh.SpringFL:GetPosition(true)

			self.motorSprings[0] = Joint:Slider( self.posSprings[0].x,self.posSprings[0].y,self.posSprings[0].z, 0,1,0,self.mesh.SpringFL, self.mesh.chassis ) 
			self.motorSprings[0]:EnableLimits()
			self.motorSprings[0]:SetLimits( self.motorSprings.limits.Down, self.motorSprings.limits.Up)
			self.motorSprings[0]:SetSpring( this.motorSprings.force )
			
			self.posSprings[1] = self.mesh.SpringFR:GetPosition(true)

			self.motorSprings[1] = Joint:Slider( self.posSprings[1].x,self.posSprings[1].y,self.posSprings[1].z, 0,1,0,self.mesh.SpringFR, self.mesh.chassis ) 
			self.motorSprings[1]:EnableLimits()
			self.motorSprings[1]:SetLimits( self.motorSprings.limits.Down, self.motorSprings.limits.Up )
			self.motorSprings[1]:SetSpring( this.motorSprings.force )

			self.posSprings[2] = self.mesh.SpringBL:GetPosition(true)

			self.motorSprings[2] = Joint:Slider( self.posSprings[2].x,self.posSprings[2].y,self.posSprings[2].z, 0,1,0,self.mesh.SpringBL, self.mesh.chassis ) 
			self.motorSprings[2]:EnableLimits()
			self.motorSprings[2]:SetLimits( self.motorSprings.limits.Down, self.motorSprings.limits.Up )
			self.motorSprings[2]:SetSpring( this.motorSprings.force )
			
			self.posSprings[3] = self.mesh.SpringBR:GetPosition(true)

			self.motorSprings[3] = Joint:Slider( self.posSprings[3].x,self.posSprings[3].y,self.posSprings[3].z, 0,1,0,self.mesh.SpringBR, self.mesh.chassis ) 
			self.motorSprings[3]:EnableLimits()
			self.motorSprings[3]:SetLimits( self.motorSprings.limits.Down, self.motorSprings.limits.Up )
			self.motorSprings[3]:SetSpring( this.motorSprings.force )

		end


		function this:Update()


			if Window:GetCurrent():KeyDown(Key.J) then
				self.mesh.chassis:AddForce(0,150,0)
				
			end
				
		end
		
		
		
		

	



		return this 
	end

And there's still the question of whether this is well implemented, but I guess I've learned something new.