SyntaxBomb - Indie Coders

Quote from: Derron on February 07, 2025, 13:15:36I have some years of experience in Blender (in the last time not so much ... just no "project" for it - and lack of spare time for "more hobbies") but feel free to approach for "how would you" things.

..Thank you very much ..i will be bugging you very soon about this sort of things, so remember, you said i can do it..haha

@ Matty
In your last video there is audio stuttering (menu and when you zoom in). I know you will say this is "fraps" and the "old computer" - but ... are you updating the audio buffer in a separate thread (so independend from rendering and updating)? If not - give it a whirl. This should avoid audio stuttering in many cases.

The video also exposed that the "smoke effects" hide the enemy units (as they have not so vibrant colors ...) dunno if this on accident or desired.

And ... I mentioned it already: the fire explosions are "blocky" (you can see scaled up pixels ... (below image is taken from one of your last screenshots)

Maybe you can re-render the explosion with an a bit bitter resolution.  (you might even consider "faking" a bit more there by adding a small particle effect which emits particles in the 3rd dimension - to avoid the billboard look).


bye
Ron

@Derron - there's no audio stuttering when I don't use fraps. When I use fraps the frame rate basically halves.

Yeah the smoke is supposed to every now and then appear and block the view...it's a deliberate decision....I intend to turn it into clods of dirt being thrown into the air eventually.

I do have higher resolution explosion graphics, I'll have to get around to putting them in instead soon enough.

Thanks...

Quote from: Matty on February 10, 2025, 13:13:12@Derron - there's no audio stuttering when I don't use fraps. When I use fraps the frame rate basically halves.

This does not answer the question. If eg fraps needs to fetch stuff from the framebuffer / screen then the "render thread" (so most probably the main thread) will wait I guess. But if you audio playback is handled from a different thread then it can happily continue to feed in new stuff to the audio buffer.

Extracting audio playback to a second thread is something you will surely easily code together in a bunch of hours (or less) but it is worth the effort - even if you do not have much movement on a screen the frame rate could go low (for various reasons) and people will not recognize it ("no motion") but they might hear the "bob bobbob sound" (if buffer not refilled) or "silence" if you playback the samples "manually".

As said ... if you did not try to place the audio playback in a second thread, give it a whirl. Similar things you would do when loading assets "ingame" (might not be required in your game now though).


@ fog

Okey Dokey, all is fine.


@ explosions

Thanks :-)



bye
Ron

So I had a comment on my itch page by someone who played it - admittedly under WINE on Linux. It ran slow for them but they weren't sure if it wasn't just because it was running under wINE.

Do games run slower on Wine if they're designed for Windows?

Derron - according to what I've read online some aspects of raylib, including audio, are already multithreaded - so there's really no need for me to add a further intervening thread between the main thread and the audio threads that raylib already creates.

Re audio:
OK, yeah, seams they have a thread already. Was a bit blind guessing. Sorry.


Re wine:
many games simply run even faster on Linux. With wine you need to ensure to use a more recent one and maybe one with the vulkan patches and the likes. So maybe simply proton or playonlinux or so ... which either base on wine or provide a convenient way to multiple versions of wine etc.

The commenter of the game -- if they have a wooden PC then it does not matter if it is Windows or Linux. You might consider compiling for Linux (maybe set up a VM with some Ubuntu on it). The VM might not run your game smooth but you will get a native binary.  Use an older Ubuntu (18 or 20) if you want to ensure most people can use it (the version you use provides a glibc which then is the minimum version it will run with... so the "older the better" )


I downloaded it. CPU usage ingame is 40% (so about 8 times of what my TVTower uses :p) - this is on a some years old ryzen 5 and a gtx 1050ti.


After starting I saw there is a console log:


And this is the game: it starts "fullscreen windowed" with a "border" (so window decoration) but the game seems to not recognize (see cut off bottom)  - I moved the window up but it simply ends there. So maybe try to read the window size and adjust accordingly?



Direct feedback:
when scrolling the foliage on the ground "flickers" ... not in the sense of disappearing and appearing, but because of their "fine structures" (similar to moire effects etc). This is very distracting.

The units: Right on start I had a "anatialiased font in a cartoo book bubble" (not suiting to the "scifi ambiente") and while for a while I was not able to control my units, guess it was still in a "I am beginning now" mode.
For such things: change the mouse cursor to something telling you "wait a moment... you cannot do things now".

Once I was able to select units, I was able to select some individually (clicking on it) but for some this simply did not work (maybe because they were partly occupied by a building ... so maybe hit-rectangle/bounding box is not best there -- use it to find candidates and if there are more than one, use the real model/a polygon). I was able to select them with the "rectangle select".

Mouse wheel worked but was rather "harsh" in scaling ... so a tiny movement had already a big impact (maybe make it "start slow" ...similar to what you do with the the scrolling).

At the game begin I was close to the units and saw that the animation was not smooth ... I suggested some days earlier to try the GLTF stuff with blender, so that you can use the animations (dunno if that is faster or not ... give it a try). Once you have the models in Blender it should be fairly easy to bring in new animations ( @Qube for example used mixamo in his kungfu-fighting-game to bring in animations). These new tools allow to upload a model and they even rig it for you ... and then there are plenty of animations you can use (idling, attacking, ...)
Just a suggestion of course.


PS: I know, just bringing up "critics" now ... so maybe the good thing: for me it works, and did have too low fps (for me).


bye
Ron

Re: fullscreen windowed..I'll look into that...

Re: Vegetation flickering on scrolling due to fine detail - not 100% sure what the remedy for this is,
will have to do some research on how this is normally dealt with

Cartoon book bubble - yeah - I'm going to change that, it's a temporary measure just to give a kind of
'briefing' to the player, but yeah - it's going to change...temporary placeholder only. currently.

Re: individual select...yep...known issue, I'll be fixing that ... eventually..

Re:mouse wheel...I'll think about that one.

Re:animation....you're partially right...for the idle animation I didn't export all the frames when I did the
model so it only draws every 10th frame..hence it's missing 9 frames between each of the 100 idle
animation frames...this was just laziness on my part and in order to get the models into the game quickly.
I will smooth it out by exporting the missing 90 frames or so. I can't use GLTF for a simple reason: Animation
of bones is done on the CPU by raylib which means it's going to be a tonne slower than what I do now,
what I do now will look fine if I export all the missing frames of the idle animation, you don't notice them
missing except at close zooms.

Glad the game works and I think you meant the framerate was okay for you...

I have some other comments about gameplay mechanics that I've built into the game that I'll post in a
second reply just to keep it separate...

Oh yeah...and regarding the multithreaded nature of raylib....I didn't realise that when I was coding my debuginfo that measures how long various rendering bits take in the game but because of the way raylib renders, my time measurements for the rendering parts isn't really measuring the rendertime, just the time to process the various loops where I pass things off to be rendered...unfortunate...I was wondering why the times I was measuring didn't match up with the frametime the system returned...because all the calls to 'drawmesh/drawmodel' that you tell raylib get sent to a different queue in a thread to be processed by the render thread which runs separate...which means all my time calculations to see which rendering processes (vegetation/units/fx etc) is all wrong..it's just measuring the time of the various for loops..

A comment about some gameplay features that as far as I know weren't generally in the RTS games from the era I played (for all I know they might be in modern RTS games?)

1. Cover - obscuring vegetation, smoke and such reduces the amount of damage a target receives from direct fire.

2. Flanking fire - if you manage to get into a position where you're shooting at enemies from multiple angles greater than 90 degrees with multiple firers you'll do a tonne more damage.

3. Tanks can 'one shot' kill each other with an AP round sometimes, they can also be immobilised (tank treads damaged etc) when they're shot which means they're basically just gun emplacements until they're killed in such a situation.

4. As the landscape gets torn up by shells the resulting craters provide cover (foxholes) for the infantry that stand in them.

5. When a sergeant is killed in a squad the next highest ranking individual takes over as sergeant.

6. Ammunition is limited, and when a soldier runs out of ammunition they still do damage, just less per shot, but they can be resupplied by passing the mouse cursor over them (there's an indicator marking they're out of ammo)

7. Snow does have an effect (if you turn on the snow) which causes tracked tanks to be more likely to break down, and infantry to suffer worse from the battlefield "stuff" 

8. Infantry have a limited number of grenades that are not resupplied on running out, and when they're stuck in a firefight with other infantry who are in cover they'll often lob a grenade at the enemy which ignores cover and does splash damage to other infantry.

Ps...the other user just told me the framerate was fine.....it wasn't fine when they changed one of the 'experimental' settings in the config.txt file.....running it as default it ran perfectly. I kind of knew this would happen if someone activated that flag.

Quote3. Tanks can 'one shot' kill each other with an AP round sometimes, they can also be immobilised (tank treads damaged etc) when they're shot which means they're basically just gun emplacements until they're killed in such a situation.

Hmm... just a simple idea... a broken tank could be selected and "unmanned" ... means 2-3 light ground soldiers will spawn and the tank becomes pure decoration (yeah I know..could be manned again but keep it simple )


Regarding ammo resupply:
Just asking for "logic" ... why do you have to click for ammunition refill - but grenades are not refillable? If you can hand out a new box with bullets "magically", then you should do the same for grenades.
You could consider having "refills" for some cost ... either "pay" for it (if you had a currency / something to gather), or have some "inventory" which you can take the ammo from, and which gets refilled in specific intervals - means you might not be able to resupply for all at the same time.


Re animations:
Hmm ... can't you load the model, and export the animations then "on the fly" ... so like creating the "new models" on the fly on game start (or first game start)?

regarding cpu/gpu:
https://github.com/raysan5/raylib/issues/4587
links to
https://github.com/raysan5/raylib/blob/master/examples/models/models_gpu_skinning.c
(bone update is still CPU but skinning is GPU, implemented with Raylib 5.5)
Dunno if that would be feasible.

Anyways - yeah, I guess if you have hundred units which share 100 "models", then this might be more efficient than having to update the 100 units each separately (instead of just deciding what model to use currently).




Regarding experimental flag:
This means the user was intrigued trying out things! I think this is something good!



bye
Ron

Thanks Derron. 

I've made some changes, available at the game page on https://matty77.itch.io

Here's a video without music but with sound effects.

Re the grenades not refilling...it was an early design decision - I might change that however - I was concerned that grenades might be too powerful if the user can just keep replenishing them....and part of the purpose of the limited ammunition is to keep the player on their toes, having to move about the map and make sure all their fighters are still doing their job.

Something I'm proud of is how I do the snow.  Snow is not just a snow texture but is a snow texture applied on top of existing nature blended according to the y normal component of the objects rendered pixel.  So flat surfaces facing the sky get more snow texture.  You can notice it when you look carefully at the grasses.

A few changes, including "individual unit selection on clicking".

I wasn't sure the raycasting feature of raylib works exactly as I'd like....which left two methods open to me. One involved setting the colour of all the selectable units in a hidden render, rendering the scene, then reading the pixel colour of the screen at the mouse coordinates and matching it back to the unit that was coloured that way. Unfortunately in the C# binding for raylib there's no way of reading pixel data from the screen or a texture.

So...at load time I parse the vertices of the object's files, put them in an array and simply on 'click' of the mouse, when checking to select stuff I loop through the nearest units to the mouse's vertices, transform them into world space, then transform them into screen space and if any of the model's vertices are nearer than 'n' pixels and the nearest of them...then that's our unit to select. It works. And works well.

It wouldn't work if the models were large scaled cubes with massive space between the vertices, and it would be dead slow if they were high poly, but with low poly, vertex dense meshes, it works quite well.