main.lua / loading progressing bar / default resolution

[Marcousik]

Hello

I would like to speak about what does exactly do the main.lua after publishing a game, especially this code:

local gfxmode = System:GetGraphicsMode(System:CountGraphicsModes()-1)
if System:GetProperty("devmode")=="1" then
    gfxmode.x = math.min(1280,gfxmode.x)
    gfxmode.y = Math:Round(gfxmode.x * 9 / 16)
    windowstyle = Window.Titlebar
else
    gfxmode.x = System:GetProperty("screenwidth",gfxmode.x)
    gfxmode.y = System:GetProperty("screenheight",gfxmode.y)
    windowstyle = Window.Fullscreen
end
window = Window:Create(title,0,0,gfxmode.x,gfxmode.y,windowstyle)

Because players of the published game become a default screen resolution in fullscreen that seems not to be always the same:

Sometimes the game starts with 1920*1280 or 2715*1527 or even 3840x2160 if supported.

But at the same time, windows(10 or 8.1) is still running at the own selected system resolution, so only a part of the game can be seen.

So I hope this is understandable (sorry my english may be bad) but what I would like to script is how to make the windows system (8.1 for example) selected user resolution  (for example 1920*1280), be the game starting default resolution, and not a bigger one that would let the published game not look professional at all.

 

And I wanted to ask if there is a chance to build a progress loading bar that would show a real loading progress ? thx for help

This may required a function or a loop in the main.lua that is running while the map is changing/loading... I don't know if something like this is possible /  ok thx

 

[gamecreator]

Regarding the progress bar, you have two options:

1.  Figure out how to use the hook in the Map:Load function (if it works).  It's supposed to call a script every time an entity is loaded and you can display a progress bar there.
2.  Preload everything yourself and display the progress bar as you do it.  Meaning, if you 12 different trees and 8 textures and whatnot in your map, load those first, before you load your map.  As pseudocode, it would look like this:

preload_model[0] = Model::Load("tree1.mdl")
update and show progress bar
preload_model[1] = Model::Load("tree2.mdl")
update and show progress bar
preload_model[2] = Model::Load("tree3.mdl")
update and show progress bar
etc.
That's pretty much how I do my loading screen.

[Rick]

The loading bar idea should be noted for the new engine. Make the map format json or something so the information about what should be loaded can be loaded first then it's easy to see how many models there are and then the engine could expose a callback after each resource is loaded from the map and let a full iteration of the engine happen after each one so we can display our own progress bar.

[Yue]

function this:LoadMap( map )
		
		function loading()
			System:Print("Load...")
		end


			self.map = Map:Load("Maps/"..map..".map", loading())
			return self.map
end

Testing with Load Map only returns when the map is fully loaded, not when an entity is loaded from the map.

[Marcousik]

Ok thx, great ideas.

What about the screen resolution, am I the only one having problem with this ?

I read a few thing about fullscreen modus bugs, but nothing really helpfull about this. it seems the engine switch to a random (or simply take as default the biggest?) resolution of the screen.

I remember now I had this "bug" too. I started the game and it ran at 2715*1527.

Result: You can't see the complete screen if your windows system uses a lower resolution. Is there a script function that allows Leadwerks to grab system information like the user screen resolution ?

[gamecreator]

I want to say that someone had a resolution issue with something I released as well but I couldn't find it just now.  If I remember right, it made me look into a non-Leadwerks, Windows-specific function that returns the current resolution, which would typically be the desktop resolution (but I'm using C++).

@Josh Is it possible to add a GetCurrentGraphicsMode function?

[Angelwolf]

On 7/5/2019 at 7:21 PM, Marcousik said:

 

But at the same time, windows(10 or 8.1) is still running at the own selected system resolution, so only a part of the game can be seen.

 

I'd like to ask what you mean by this?

When you say that only a part of the game can be seen, are you saying that a chunk of the viewport (ie player) is missing or something you're drawing over the top (like a hud or text)?

[Marcousik]

@ Angelwolf

No. I think I'm not precise enough with my (school) english to explain this.

It's not a really Leadwerks scripting problem, even if it could be solved with a script function like gamecreator is suggesting.

I try to explain one more time, with other words:

If your game runs at a resolution of 2715*1527 by default, and your windows system screen options is selected to run at 1920*1280 for example, so it will act like this:

So a solution for me could be to check with a script function at which resolution the windows system runs on the gamer screen and start the game at the same default value, so the gamer (I use "gamer" to not create a confusion with the ingame player controller) can see the entire game scene, and if he wants, change the resolution in the options. But I don't know how to catch a windows system value.

Another solution could be to make the Leadwerks game somehow "stronger" than windows so that the game resolution defines the actually used screen resolution, over the windows system itself.

I think this second solution is most popular used in games I know like I'm used to see modern games modifying the screen resolution as they "want."

 

 

[Angelwolf]

This is odd. I do not have issues like this - when my game is run then the game is just a larger version of the windowed mode.

Do you still have the same problem if you set 

System:GetProperty("devmode")=="1" 
to
System:GetProperty("devmode")=="0"

Also, do you have the same problem if you set

windowstyle = Window.Fullscreen
to
windowstyle = Window.Titlebar

[Marcousik]

I got this only appearing sometimes (odd yes, randomly ???) to me with System:GetProperty("devmode")=="0" (published game) and windowstyle = Window.Fullscreen. But it requires more tests and I'm not able to say why it occurs...

Maybe it is good enough to set the default settings to windowed game at 1600*900 and let the gamer change this as he wish.

 

 

[Yue]

I also had problems with the resolution in full screen mode and something about the scale in windows.

My point of view is that there are two types of resolution that my computer marks as in the panel of nvidia ultra, hd, sd, if I try to run leadwerks in screen mode I have rare problems, however the other resolution marked as "PC" does not present these problems. 

Now, on the progress bar I remember that I made a false object loading bar in Leadwerks using Lua Script, this I did using the curtains, where a progress bar goes up simulating resource loading, but stops for a moment when it is loading the map. 

Translated with www.DeepL.com/Translator

[Marcousik]

- For the loading bar, I thought maybe a loading animated shader in background could do it ?

 

- For the resolution, sorry, I discover the true problem and it's my mistake: I made a mistake by drawing the first loading image not depending on the resolution of the game but impose the size with those values, sure it could not run:

context:DrawImage(texture,0,0,1920,1280)

instead I should have use context:GetHeight() and GetWidth()

So this may be solved.

 

 

 

[Yue]

For a progress bar to be real, threads must be managed, one in charge of updating the status of the progress bar and another thread where those resources are loaded in the background, inevitably it seems that this must be done on the c++ side.

Otherwise when loading a complete map is evaluated when the map is loaded in its entirety, however if you create entities one by one you can update the status of the progress bar but it is not viable. In the case of maps, if the map is very large, the bar will undoubtedly pause for a long time, until it is completely loaded. 

Translated with www.DeepL.com/Translator

[gamecreator]

25 minutes ago, Yue said:

For a progress bar to be real, threads must be managed... this must be done on the c++ side... In the case of maps, if the map is very large, the bar will undoubtedly pause for a long time, until it is completely loaded.

Can I ask why you wouldn't use the method I suggested above?  You can load models one-by-one ahead of time to a model array (and hide them) and update a progress bar after each one.  Then, when you load the map, since every model is already loaded, the map itself will load pretty fast.  Maybe I should share a sample C++ code of this.

[Yue]

The loading process usually happens and takes time.

I understand the concept of loading a model one by one, and then update the drawing of the load bar, however this is not possible with a map, where everything is initially loaded and evaluated as a single entity and updated the load, ie with "Load" of the map I have its return value when loading the map, I have not managed to evaluate every time you load each entity of that map.

In c++ you can create threads, you need a thread to update the load bar while a second thread is loaded resources. This is rather an element of showing something to the user while that load happens, a progress bar, a continuous animation of loading etc.

In the case of a map, I don't see any sense to load the whole map, and then hide it, we would have a black screen initially and the idea is rather to show an animation when that map is loaded in the background.

The idea would be something like that in c++.

A thread is created, and through a main loop it is evaluated that while the map is not loaded an animation of an image is updated, a progress bar or whatever. 

When the map is loaded, the loading thread is killed and the level we need is passed.
Translated with www.DeepL.com/Translator

[Yue]

In the case of curtains, the false loading bar is implemented, a bar that changes its position from 1 to 100, but when it reaches 50, for example, the map loading starts, but at this point the loading bar stops at that percentage while loading the map, a way to create and simulate a loading bar, but in reality it is only visual. Depending on the computing power, how big the map is, in 50% of the bar can last longer, less time loading the map, then when it ends the loading bar continues to its highest value the number 100. With this gives step the level.

[Rick]

Yue, what gamecreator is saying is that the biggest time to load an entire map is loading all the models that are in the map. The LE map doesn't actually have the mdl files inside it. The map file just has information about what mdl files to load (mostly). In LE if a model is already loaded the next load call on it will just be creating another instance of the model (this means it doesn't have to go to disk to do this. it just looks at the already loaded model in memory and copies it.). Creating instances are fast. So if BEFORE you load your map you manually call load on all the mdl files you need then calling the map load will be faster. Since you're manually calling the mdl files to load you can loop over that process and make the progress bar, then at the end call your map load. Yes, there will be a slightly below still when you load the map but it'll be MUCH smaller and probably not noticeable by the user. So it sort of simulates map loading progress bar. This does have the side effect of needing to manually know which models to load for each map. Ideally one wouldn't load every model in the game if it's not used in a map. This is really why the map file should just be json so we can easily open and manipulate it ourselves. Even add fields to it.

[Yue]

7 minutes ago, Rick said:

Yue, what gamecreator is saying is that the biggest time to load an entire map is loading all the models that are in the map. The LE map doesn't actually have the mdl files inside it. The map file just has information about what mdl files to load (mostly). In LE if a model is already loaded the next load call on it will just be creating another instance of the model (this means it doesn't have to go to disk to do this. it just looks at the already loaded model in memory and copies it.). Creating instances are fast. So if BEFORE you load your map you manually call load on all the mdl files you need then calling the map load will be faster. Since you're manually calling the mdl files to load you can loop over that process and make the progress bar, then at the end call your map load. Yes, there will be a slightly below still when you load the map but it'll be MUCH smaller and probably not noticeable by the user. So it sort of simulates map loading progress bar. This does have the side effect of needing to manually know which models to load for each map. Ideally one wouldn't load every model in the game if it's not used in a map. This is really why the map file should just be json so we can easily open and manipulate it ourselves. Even add fields to it.

Okay, I always have to learn something new, and the translator isn't that helpful. 

I mean, I have a map file, which has a mesh, and a camera. 

The map file, I call it start.map. 

In that case, it would be something like that. 

Load Mesh.
Upgrade, progress bar to 50%.
Load Camera.
Update progress bar to 100%.
I load the map. 

Correct?

[Rick]

Close. You don't load cameras separately, just the models really. So let's say you have 10 different models in your game.

 

In a loop just for clarity:

LoadModel1

Update, Progress bar to 10%

LoadModel2

Update Progress bar to 20%

*repeat until you loaded all models

Load Map (this will be fast now because you already loaded the models and when this goes to load those models it'll use the instances in memory vs going to disk).

 

Note that you wouldn't manually set the % like this. You'd want to figure out how many models you need to load per map and calculate the % as you're looping over them all.

 

Note this is a "hack" though. We shouldn't have to do something like this and hopefully Turbo handles this better.

[Yue]

 

Okay thanks, it's really interesting, always something new to learn. 

By the way, the arrow disappeared. ?

[Yue]

 

Screen full, problem here.

 

 

 

[Gonan]

Start by creating a general map loading function, use it where ever you load a map, add logic to that function to detect if a uniquemodel file exists for that map. If it doesn't load the map, create a dummy progress bar, then create a file of the uniquemodels currently loaded. Animate the progress bar. Next time the function is called for that map a uniquemodels file will exist, get all the entities loaded, counts the number of unique models, use this when animating a progress bar during this loading stage. The model list file could use the name of the map + "uniquemodels" . Once written the whole process could be automatic for future projects.

[Yue]

@Rick 
 

I have done load tests before loading the map, however I have two repeated models, now the question is, what do I do with that model, The hidden?

And in the case of audio files, does the same apply?

[Marcousik]

10 hours ago, Yue said:

 

Screen full, problem here.

 

 Can you share the main script code you are using to get this ?

 

 

 

[Rick]

8 hours ago, Yue said:

@Rick 
 

I have done load tests before loading the map, however I have two repeated models, now the question is, what do I do with that model, The hidden?

And in the case of audio files, does the same apply?

You can just hide them.