TestPace X [ Developing]

[Yue]

I had to enlarge the terrain, this implies that the player can't reach the limit so quickly, a terrain of 10,000 x 10,000 units, however I have to think of something so that it doesn't reach the edge.

[Yue]

Almost everything is ready for a simple game, a mini-game, something small for a single mission.

[Yue]

Whenever I go to the laptop on Sundays, I find myself with a drastic blow to performance, and everything keeps pointing to the rocks, however this is the best optimized thing that gives me my head.

The summary is that on my laptop it's slow, since starting the graphics card is limited, starting with the fact that it only supports 4 textures per entity, unlike the computer of the house that supports 8 textures.

Undoubtedly the good thing about this is that I can guarantee that it will run in slower teams, but in the end everything points to the rocks, and I have to think of an option that changes the density of the rocks in the radius in which they are visible, this implies that the higher the density, the more rocks visible, the lower the density or no visible rock.

What really is a lifesaver in these cases in the tween technique, that the truth is not how it works, I only know that the smaller FPS, it seems to rearrange the speed of animated objects and movements in the world trying to compensate for the performance drop.

In addition to the above, it is necessary to implement another option to manipulate the detail of the terrain, I currently manage a value of 80,000 8000, and if I underestimate that this helps to improve performance.

That's all for today, from my job as a watchman in a building.

Code (blitzbasic) Select Expand


Repeat  :  elapsed = MilliSecs() - time  :  Until elapsed
ticks = elapsed / period
tween# = Float(elapsed Mod period) / Float(period)
For k=1 To ticks
time = time + period
If k = ticks Then CaptureWorld

WorldStep(0.00005)
UpdateParticulasRuedas(vehiculo.TVehiculo )
UpdateParticles()
MontarVehiclo(vehiculo.TVehiculo, jugador.TJugador)
UpdateJugador( jugador.TJugador, vehiculo\chassis\ente, camara.TCamara )
UpdateWheels( vehiculo.TVehiculo )
;ResetVehiculo( indicadores.TIndicadores, vehiculo.TVehiculo, jugador.TJugador, camara.TCamara )
; UpdateColRocas()

UpdateWorld

Next





RenderWorld()
RenderPostprocess FE_Blur + FE_Glow  ; + FE_Contrast
UpdateShadows ( camara\ente )
UpdateDist_Sombras( sombra1, sombra2 )


[RemiD]

I currently manage a value of 80,000

80000 triangles for an empty terrain ?

Good luck running your game on medium end / low end (=most) computers

[Yue]

No, I was wrong, the value is 8000, it is the value that is set with terrainDetail, by the way RemiD, for what is the Morph value of that command?

Code Select Expand

TerrainDetail ( self\ente, 8000, True)

[RemiD]

8000 is ok for a terrain of this size, i think.

The morph function is to make the heights (vertices or the ROAM terrain) go progressively from previous position to next position, rather than instantly, but it will probably be slower to activate it.

[Yue]

Thanis Yue RemiD.

Well, I've recovered some performance on my laptop. What was done was to implement a variable that has the density of rocks from 1 to 100, the highest value implies more rocks close to the player in a 360 degree radius at a distance of 250 units.

On the laptop with a density of 10, it goes to an average of 60 frames per second.

[Yue]

The bug of death.

When something happens and I have no idea what it could be.

I've spent the last 30 minutes trying to understand why I can't compile in Blitz3D, and inevitably the brain automatically starts to make assumptions that although they don't make sense, they are evaluated to solve the problem.    This has happened before, and it's one of the reasons why the project sucks, but I think I've developed a certain ability to solve these problems without losing my mind.

Well, the brain begins to make conjectures, it's a nightmare especially when I have to open the door, and close it, I'm in a trance trying to solve the problem, so at home can reach very late at night to solve that. But everything has turned out fine, after doing tests, keeping the sanity first of all, not moving anything or at least doing with a lot of beforetionn, I found the problem, The load thread decompresses the encrypted resource files and sends them to the windows temporary directory. If the application crashes during the load are left in this file in the temporary directory, so I had to go to that directory and delete that content and for my relief this was solved.

So looking at this from a positive point I corrected something that speeds up loading from the thread. This is sometimes really epic.

Translated with www.DeepL.com/Translator

[RemiD]

Is this because you use some hacking features of fastext ?

[Yue]

Especially use FastPointer to load resources in the background and process a load screen.  The error occurred because it had an erroneous parameter in the Bones library, which compresses the resources into img files.  Textures. img, Fonts. img etc.  These files are sent during the process of uploading to the windows temporary directory, and after being uploaded they are deleted from that location.

[Yue]

From my development studio.   

[Yue]

Oxygen

I already have the mechanism by which the oxygen descends, it does it very slowly in optimal conditions of the oxygen condenser. But it is expected that at the start of the game the oxygenator will be damaged, the air escapes and it is time to look for a viable solution to live a little more on the red planet.

Now, if the character runs, the consumption will be higher, so it may be more practical to slow down in certain circumstances.

[Derron]

You should couple/link the oxygen usage to the heart beat rate.
So the faster the heart beats, the more you breath and the more oxygen is used.

Now when Running you increase from "BEAT_RATE_IDLE" to "BEAT_RATE_RUNNING" in very big steps. So eg. "+30% per second". But when stopping running you wont decrease beat rate by 25 or 30% each time but just 5%/second.
This then means that "not running" will use less oxygen as you do not loose that much oxygen because of the "stopped running" phase.

Running phases are then needed if _external_ things happen: eg a dust storm is coming up and you need coverage, or a batter will get broken if you do not connect it fast enough to your "home" or "car".


Above in some kind of "code":

Code Select Expand


Const BEAT_RATE_RUNNING:int = 180
Const BEAT_RATE_IDLING:int = 70
local heartBeatRate:Float = BEAT_RATE_IDLING

[...]
'in your loop/player.update()
If state = STATE_RUNNING
  heartBeatRate = Min(BEAT_RATE_RUNNING, heartBeatRate * 1.2 * deltaTime) 'add 20%
ElseIf state = STATE_IDLING
  heartBeatRate = Max(BEAT_RATE_IDLING, heartBeatRate * 0.95 * deltaTime) 'subtract 5%
Else
  ...
EndIf

(deltatime = fraction of a second, if you have eg. 60 updates per second, this will be around 0.015)

Of course you could add more state - and their transitions. So eg. jumping could add some heart beat rate _on_top_.
In that case your function should be done "differently" and a bit more difficult (setting a maximum/target value which is affected by "jumping" or other actions. This value is to set when a specific state is set - so "start running" or "start idling" would set a target value while "jumping" would temporarily increase the target value).

For now I would go with something like what I "coded" above.

bye
Ron

[Yue]

Thanks You Derron.

[Rick Nasher]

Love the way the vehicle jumps on the rough terrain. It really adds realism to it.

Would be fun to see 2 cars racing carefully not to hit the gas full speed otherwise accidents happen, and on Mars ambulances are hard to come by.