ooooo it looks really cool!
2 Likes
Good job!
1 Like
Added blaster! 
There are now also sound effects and animations for weapon on shooting, moving and for enemies on hit and death (will share video tomorrow at screnshot saturday)
10 Likes
Add Half-Life laser gun and where is the link to test that?
1 Like
I hope that gun doesn’t have clipping issues against walls and boxes. 
1 Like
I made a simple trick for this - moving weapon up when close to a wall 
EDIT: Ok, here’s a teaser 
But perhaps also drawing the gun separately to avoid clipping might be a good idea to showcase
16 Likes
I have used this to avoid clipping and rendering weapons always on top:
--on init:
self.predicates = create_predicates("tile", "gui", "particle", "model", "weapon", "debug_text")
--on update
local draw_options_weapon = state.cameras.camera_world.options
draw_options_weapon.frustum = nil
render.enable_state(graphics.STATE_DEPTH_TEST)
render.enable_state(graphics.STATE_CULL_FACE)
render.set_depth_mask(true)
render.draw(predicates.weapon, draw_options_weapon)
render.disable_state(graphics.STATE_CULL_FACE)
render.disable_state(graphics.STATE_DEPTH_TEST)
render.set_depth_mask(false)
render.draw_debug3d(draw_options_weapon)
and was working well 
4 Likes
but this looks really cool 
1 Like
It’s far from shipping yet, but we wanted to share with you an experiment @vlaaad is working on:
Terminal inside the Defold Editor:
It’s powered by GhosttyFX project by Vlad: GitHub - vlaaad/ghosttyfx: JavaFX terminal that uses libghostty · GitHub
20 Likes
That’s amazing !
1 Like
Next teaser for the FPS template, now with more assets from the Prototype pack by Kay Lousberg, reloading animations and ammo GUI, and some billboarded particlefx for shooting and hits, or knocback on hit. It can also be controlled via gamepad 
17 Likes
21 Likes
Can’t wait! Could you share a few more details about them?
-
How many lights can be present in the scene? Will be there hard cap or just the performance is the limit?
-
Can the lights move or do they need to remain stationary?
-
Will these lights be included in the FPS example?
2 Likes
- I don’t know, maybe @jhonny.goransson - are there any limits?
- Yes, lights are attached to game objects like any other components, so you can animate game object’s position:
- Yes, that’s the plan, but first to the existing 3D playground
We’ll add basic versions of model materials (forward rendering, basic diffuse direct lighting) supporting light data from the components, so you can use multiple lights of different types, and preview will be visible in Editor and in runtime you can manipulate position of the lights as mentioned above:
But note this is only direct lighting, so this not adds any shadow mapping implementation and no indirect lighting (no global illumination). These can be still achieved with custom pipeline and shaders and we’ll be preparing examples to do so (especially the FPS example is planned to use cascaded shadow maps for directional lights).
9 Likes
Would really love to see a 2d example as well
6 Likes
Yeah a 2D example with normal maps on sprites and tilemaps would be awesome
1 Like
This would be so useful to me right now!
Currenty, we use a uniform buffer object to store the light data in. The size of a uniform buffer is dependant on your graphics card and the graphics API being used (opengl, vulkan, etc) so it’s a bit hard to say, but typically they are 65k-256k large. The current representation of a light aligns to 64 bytes, which means that you can fit roughly 1k lights in the buffer.
If the light buffer capacity is an issue we can add support for SSBOs (storage buffer objects) which are more or less limitless (guaranteed minimum 128mb on Vulkan), but until someone has a real use case we will stick to UBOs because of portability.
Now, the current shader(s) we will ship are intentionally barebones - there is no “many-light” implementations available yet that use this new data model, but this is something we will add as templates a bit later.
3 Likes
Cool, thanks for the detailed answer.
I don’t really see a practical use case for more than 20-30 lights in my projects, so I mainly wanted to make sure there isn’t some relatively low limit due to performance or implementation constraints (similar to collision groups). By the way, even if there would be hard limit for low amount lights, I also don’t perceive it as wrong if its benefits performance
From what you described, it sounds like I can safely not worry about it as long as I keep the number of lights reasonable, let’s say, well below 100.
2 Likes
Yes, but you might still need something like deferred rendering for 30 lights. It’s available in latest alpha so you can always try it out right now as well. It’s not going to change until next release
4 Likes